Bug#974897: RFP: elpa-moody -- tabs and ribbons for the Emacs mode line

[intrigeri]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-moody
  Version : 0.5.4
  Upstream Author : Jonas Bernoulli
* URL or Web page : https://github.com/tarsius/moody
* License : GPL 3+
  Description : tabs and ribbons for the Emacs mode line

Bug#974896: RFP: elpa-company-quickhelp -- add documentation popups to company completion candidates

[intrigeri]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-company-quickhelp
  Version : 2.3.0 + Git master
  Upstream Author : Dmitry Gutov
* URL or Web page : https://github.com/company-mode/company-quickhelp
* License : GPL-3
  Description : add documentation popups to company completion candidates

Bug#964688: cherry-pick patch from upstream - fixes #964688

[Alois Schlögl]

Adrian is right. I want to make you aware of another patch set (see 
attachment) which I recommend to add.



The patch is fixing an issue when importing an event file, and the 
sample rate in the event file does not match the data file.



The patch set is currently maintained here

   https://git.ist.ac.at/alois.schloegl/sigviewer

and corresponds to the last three patches (currently this   'git diff 
7e26e4da 7303ba9d0' )


The changes have been sent to the maintainer (Clemens Brunner), but 
there is no release yet.



I can contact the maintainer, or submit another bug report. The easiest 
approach would be if you could just add the patch here.



   Alois



On 11/14/20 11:08 PM, Adrian Bunk wrote:

On Sat, Nov 14, 2020 at 09:28:53PM +0100, Andreas Tille wrote:

Control: tags -1 pending
Control: tags 922571 pending

Hi,

I have moved sigviewer to Debian Med team[1], fixed the other bug and
tried to build the new upstream version 0.6.4 but failed:

...
g++ -c -pipe -g -O2 -fdebug-prefix-map=/build/sigviewer-0.6.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -D_REENTRANT -Wall -  Wextra -fPIC 
-DVERSION_MAJOR=0 -DVERSION_MINOR=6 -DVERSION_BUILD=4 -DQT_NO_DEBUG_OUTPUT 
-DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -I. 
-I/build/sigviewer-0.6.4/ external/include -Isrc 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/  
QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtCore -Itmp/release 
-Itmp/release -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o 
tmp/release/undo_redo_gui_command.o src/gui_impl/commands/ 
undo_redo_gui_command.cpp
src/gui_impl/commands/open_file_gui_command.cpp: In member function 'void 
sigviewer::OpenFileGuiCommand::importEvents()':
src/gui_impl/commands/open_file_gui_command.cpp:200:23: error: redeclaration of 
'sigviewer::FileSignalReader* file_signal_reader'
   200 | FileSignalReader* file_signal_reader = 
FileSignalReaderFactory::getInstance()->getHandler (file_path);
   |   ^~
src/gui_impl/commands/open_file_gui_command.cpp:185:23: note: 
'sigviewer::FileSignalReader* file_signal_reader' previously declared here
   185 | FileSignalReader* file_signal_reader = 
FileSignalReaderFactory::getInstance()->getHandler (file_path);
   |   ^~
make[1]: *** [Makefile:2576: tmp/release/open_file_gui_command.o] Error 1


Any help would be welcome

This is from 0002-add-support-for-reading-GDF-formated-event-file.patch,
which seems to be upstream now - and adding the same code twice is what
failed.


Andreas.

cu
Adrian
diff --git a/src/file_handling_impl/biosig_reader.cpp b/src/file_handling_impl/biosig_reader.cpp
index 41fce69..42c12ae 100644
--- a/src/file_handling_impl/biosig_reader.cpp
+++ b/src/file_handling_impl/biosig_reader.cpp
@@ -121,10 +121,6 @@ QString BioSigReader::open (QString const& file_name)
 QString BioSigReader::loadFixedHeader(const QString& file_name)
 {
 QMutexLocker locker (_access_lock_);
-char *c_file_name = new char[file_name.length() + 1];
-strcpy (c_file_name, file_name.toLocal8Bit ().data());
-c_file_name[file_name.length()] = '\0';
-
 tzset();
 
 if(biosig_header_==NULL)
@@ -134,7 +130,7 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
 biosig_header_->FLAG.OVERFLOWDETECTION = 1;
 }
 
-biosig_header_ = sopen(c_file_name, "r", biosig_header_ );
+biosig_header_ = sopen(file_name.toStdString().c_str(), "r", biosig_header_ );
 
 basic_header_ = QSharedPointer
 (new BiosigBasicHeader (biosig_header_, file_name));
@@ -145,8 +141,6 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
 destructHDR(biosig_header_);
 biosig_header_ = NULL;
 
-delete[] c_file_name;
-
 qDebug() << "File doesn't exist.";
 QMessageBox msgBox;
 msgBox.setIcon(QMessageBox::Warning);
@@ -167,17 +161,11 @@ QString BioSigReader::loadFixedHeader(const QString& file_name)
 destructHDR(biosig_header_);
 biosig_header_ = NULL;
 
-delete[] c_file_name;
-
 return "file not supported";
 }
 
 convert2to4_eventtable(biosig_header_);
 
-delete[] c_file_name;
-
-c_file_name = NULL;
-
 basic_header_->setNumberEvents(biosig_header_->EVENT.N);
 
 if (biosig_header_->EVENT.SampleRate)
diff --git a/src/gui_impl/commands/open_file_gui_command.cpp b/src/gui_impl/commands/open_file_gui_command.cpp
index 094e1d9..d7ed693 100644
--- a/src/gui_impl/commands/open_file_gui_command.cpp
+++ b/src/gui_impl/commands/open_file_gui_command.cpp
@@ -2,7 +2,7 @@
 // Licensed under the GNU General Public License (GPL)
 // https://www.gnu.org/licenses/gpl
 
-
+#include 
 #include "open_file_gui_command.h"
 #include 

Bug#974792: beignet: Please upgrade to llvm-toolchain-11

[Sylvestre Ledru]

Hello,

Le 16/11/2020 à 01:44, Andreas Beckmann a écrit :

Control: tag -1 upstream

a trivial bump to llvm 10 or 11 results in a (non-trivial?) FTBFS


Could you please share the error and/or the upstream bug?


Thanks

S

Bug#974421: TexMaths does not start and show errors

[g.l. gragnani]

On 11/12/20 5:57 PM, Rene Engelhard wrote:

retitle 974421 TexMaths 0.48.2 not working in Debian unstable

tag  974421 + moreinfo

tag 974421 + unreproducible

thanks


Hi,

Am 11.11.20 um 17:27 schrieb g.l. gragnani:

Of course, title should read:
TexMaths 0.48.2 NOT working in Debian unstable


You could have retitled it yourself


Anyways, replying to this mail since the first one (apparently due to
the attachement, one could have written the error message as text, maybe
then it wouldn't have been caught by spam measures):


The last version of TexMaths (0.48.2) does not work with the packages provided 
by Debian.

Works fine here. sid VM. TexMaths 0.48.2 from the homepage.

clicked the "pi icon", entered \int_0^1 x^2 + \frac{1}{2} -> LaTeX. I do get 
the expected integral.

Maybe you should decribe what exactly does not work?
I can install TexMaths, but, as soon as I try to start it, it fails and 
the macro editor opens with the error shown

in the screenshot attached to my first report.
I'm not a specialist of Libreoffice, should there any action that I can 
do the get more info about this behavior, pleas let me know.



Instead, by using the deb packages provided by libreoffice.org all work as 
expected.

libreoffice.org has no "deb packages".
It has stuff put out of the build system into something which happens to be a container 
in "deb" format without following standards,
I won't call that packages.


Regards,

Rene



Regards,

Gian Luigi

Bug#974613: acme: wrong homepage + possible new version

[Gürkan Myczko]

Hi Davide,


I have see that the homepage
https://github.com/jan0sch/acme
is no more present


I confirm, I have also seen that.


I think the actual homepage for this project is
https://sourceforge.net/projects/acme-crossass/


You are absolutely correct.


I think also that there is a new version 0.97


Indeed, however were you able to download the source? I can only find a 
mac+windows release of that version.

I'll probably go with 0.97+ds to fix this bug...


Ciao
Davide

Bug#972813: xournal FTBFS: wrongly declared R³

[Niels Thykier]

Guillem Jover:
> Hi!
> 
> On Sat, 2020-10-24 at 11:54:54 +0200, Niels Thykier wrote:
>> Rather, I suspect the issue is that Rules-Requires-Root is set to "No"
>> rather than "no".  AFAICT, only "no" has been defined and it is
>> interpreted case sensitively.
> 
> Right, and even though this is described in the deb822(5) man page, it
> is not explicitly spelled out in the various specific file format man
> pages, so I've clarified that there. Also added more clear references
> to deb822(5) in the relevant man pages. Patches attached.
> 
>> @Guillem/Dpkg Maintainers: Should we provide stricter validation for
>> this to stop this at dpkg-source build time ?
> 
> Yeah, I think that make sense, as dpkg-buildpackage is already
> erroring out on unknown values for «dpkg/» namespaced keywords. So I
> prepared the attached patch to do this too.
> 
> Thanks,
> Guillem
> 

Thanks.

My pedantic nit would be to have dpkg-buildpackage be explicit in what
it expects if it already knows the right answer (which it does in this
case).  E.g.

"R³ field keyword No is uppercase.  Please use no instead"

Saves people a round-trip through the manual if they are unsure about
how to fix the error.

We should probably also add a special-case check for "yes" which I have
seen in the wild.

~Niels

Bug#867121: courier-maildrop removel crap

[PICCORO McKAY Lenz]

I have xpecting issues with the courier due this bug of maildrop.. cos we
cannot follow courier upstream recommendations..
I ask about that upstream..

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#966172: possible fix

[McIntyre, Vincent (CASS, Marsfield)]

Tags: patch

This (tested) patch works around the FTBFS in a sid amd64 schroot.


@@ -68,9 +68,9 @@ build-stamp: $(64-BIT_BUILD_STAMP)
  cd $(bdir); $(curdir)/makemake $(curdir)  linux g77_gcc
 #   changeperl no longer necessary - upstream uses /usr/bin/perl now
 # perl debian/changeperl
- cd $(bdir);make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU -O3" all;make 
clean;make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU -O3" cpg;make 
pgplot.html;make pgplot-routines.tex
+ cd $(bdir);make FFLAGC="-u -Wall -O2 -fallow-argument-mismatch" CFLAGC="-Wall 
-DPG_PPU -O3" all;make clean;make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU 
-O3" cpg;make pgplot.html;make pgplot-routines.tex
 # -cd $(bdir); rm *.o
- cd $(bdir) ; make clean; make  FFLAGC="-u -Wall  -O2 -fPIC" CFLAGC="-Wall 
-fPIC -D_REENTRANT -DPG_PPU -O3" VM="$(version_major)"  shared cpg-shared
+ cd $(bdir) ; make clean; make  FFLAGC="-u -Wall  -O2 -fPIC 
-fallow-argument-mismatch" CFLAGC="-Wall -fPIC -D_REENTRANT -DPG_PPU -O3" 
VM="$(version_major)"  shared cpg-shared
  touch build-stamp
 
 clean:


-- 

Bug#556448: Its not courier problem, at problem, please closed

[PICCORO McKAY Lenz]

hi confirmed this is not courier problem, at problem:

i try all the commands and always courier delivers the mail .. (including
the commands in #430166)

1. First of all, commands are wrong! cos sendmail provided by courier does
not take "-i" or "-t" or "-s" parameters.. just ignored and all parameters
that are not valid will be taken as addresses.. so in #430166 that's the
reason of vanished mails
2. last mail here confirmed was an at problem bug so please close this bug
! issue was solved at at (3.1.12-1)


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#974894: mozc: add fcitx5 binding

[Shengjing Zhu]

Source: mozc
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

Fcitx5 has released its stable version and I have uploaded it to
unstable.

Please consider add it to mozc. The fcitx5 patch is at
https://github.com/fcitx/mozc

https://github.com/google/mozc/compare/master...fcitx:fcitx#files_bucket

It looks like the modification is only in src/unix/fcitx and src/unix/fcitx5.

Bug#974704: [pcp] Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]

[Nathan Scott]

Hi Dom,

On Sun, Nov 15, 2020 at 7:01 AM Dominic Hargreaves  wrote:
>
> On Sat, Nov 14, 2020 at 12:35:04AM +, Dominic Hargreaves wrote:
> > This package FTBFS on the architectures which don't have bpftrace as a
> > dependency since:
>
> ...
>
> Also, if you do do another upload, please can you do a source-only
> upload or make sure that you build on an up-to-date sid (the upload
> on Wednesday was built against perl 5.30 on amd64).

We always do source-only uploads, except in this case where we
were explicitly requested by ftp-masters to do a binary upload as
it introduced a new sub-package.

Thanks for the NMU, please feel free to reduce it from 4 days to
less if that helps - I'll ensure a version of your patch gets included
in the next upstream release.

cheers.

--
Nathan

Bug#974893: RFS: rtl-433/20.11-1 -- Decode 433.9 Mhz data

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rtl-433":

 * Package name: rtl-433
   Version : 20.11-1
   Upstream Author : Christian W. Zuckschwerdt 
 * URL : https://github.com/merbanan/rtl_433
 * License : GPL-2+, BSL-1.0, LGPL-2.1+, Apache-2.0
 * Vcs : 
https://salsa.debian.org/debian-hamradio-team/rtl-433

   Section : hamradio

It builds those binary packages:

  rtl-433 - Decode 433.9 Mhz data

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


  https://mentors.debian.net/package/rtl-433/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rtl-433/rtl-433_20.11-1.dsc


Changes since the last upload:

 rtl-433 (20.11-1) unstable; urgency=medium
 .
   * New upstream version.
   * Bump debhelper version to 13, drop d/compat.
   * d/copyright:
 - update copyright years.
 - added Upstream-Contact.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.

Regards,
--
  Gürkan Myczko

Bug#964496: libjson-validator-perl: License known for cache files

[Andrius Merkys]

Hi,

On 2020-11-13 23:10, tuxayo wrote:
> The package openapi-specification [1] seems to be the one we need, do
> you confirm?
> 
> [1] https://packages.debian.org/bullseye/all/openapi-specification/filelist

Yes indeed. At least these two cache files seem matching:

36d1bd12eeed51e86c8695bd8876a9df ->
/usr/share/openapi-specification/schemas/v2.0/schema.json (diff in
description)
a516498b60c53096b2ce2cd83ebe0abc ->
/usr/share/openapi-specification/schemas/v3.0/schema.json (identical)

Thus they could be symlinked.

What I would like to understand before doing so, is how the cache files
are named. It would be great to automatically derive the cache file
names from the schema files instead of doing the symlinking manually.

Best,
Andrius

Bug#974892: golang-dbus does not expose package under new import path

[James Henstridge]

Source: golang-dbus
Version: 5.0.3-1

The 5.0.2 and 5.0.3 releases of godbus changed the import path to
"github.com/godbus/dbus/v5" via go.mod.

This is evident in golang-dbus-dev package, with the file
/usr/share/gocode/src/github.com/godbus/dbus/introspect/introspectable.go
including an import of "github.com/godbus/dbus/v5".

Perhaps it would make sense to include a symlink from
/usr/share/gocode/src/github.com/godbus/dbus to
/usr/share/gocode/src/github.com/godbus/dbus/v5 to satisfy code
importing the new path.

Eventually it might make sense to only provide the code at the new
import path, but that would break all current packages that
build-depend on this one.

James.

Bug#974891: win32-loader: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: win32-loader
Version: 0.10.1
Severity: wishlist
Tags: l10n patch

Russian debconf templates translation update is attached.

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


ru.po.gz
Description: application/gzip

Bug#974887: RFS: dh-runit/2.10.2 -- debhelper add-on to handle runit runscripts

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

I am looking for a sponsor for my package "dh-runit":

 * Package name: dh-runit
   Version : 2.10.2
   Upstream Author : [fill in name and email of upstream]
 * URL : https://salsa.debian.org/debian/dh-runit
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/dh-runit
   Section : admin

It builds those binary packages:

  runit-helper - dh-runit implementation detail
  dh-runit - debhelper add-on to handle runit runscripts

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

  https://mentors.debian.net/package/dh-runit/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.10.2.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/dh-runit/-/tree/2.10.2-release


Changes since the last upload:

 dh-runit (2.10.2) unstable; urgency=medium
 .
   * Don't run shake autopkgtest on armhf and armel (Closes: #973337)
   * Allow outptut to stderr for update-rc.d test

Regards,
--
  Lorenzo Puliti

Bug#974885: Unhandled Exception: System.ArgumentException: A null reference or invalid value was found [GDI+ status: InvalidParameter]

[debian-testing]

Package: repetier-host
Version: 0.85+dfsg-2

Fresh install of Debian 11 Bullseye with minimal LXDE. repetier-host crashes 
immediately on start, see error below.

apt search repetier-host
repetier-host/testing,now 0.85+dfsg-2

uname -a
Linux  5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

Unhandled Exception:
System.ArgumentException: A null reference or invalid value was found [GDI+ 
status: InvalidParameter]
at System.Drawing.GDIPlus.CheckStatus (System.Drawing.Status status) [0x0009b] 
in <728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Int32 width, System.Int32 height, 
System.Drawing.Imaging.PixelFormat format) [0x00017] in 
<728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Drawing.Image original, System.Int32 
width, System.Int32 height) [0x0] in <728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Drawing.Image original, 
System.Drawing.Size newSize) [0x00010] in <728fbd68fe594062895e1f819791e76a>:0
at (wrapper remoting-invoke-with-check) 
System.Drawing.Bitmap..ctor(System.Drawing.Image,System.Drawing.Size)
at System.Windows.Forms.XplatUIX11.DefineCursor (System.Drawing.Bitmap bitmap, 
System.Drawing.Bitmap mask, System.Drawing.Color cursor_pixel, 
System.Drawing.Color mask_pixel, System.Int32 xHotSpot, System.Int32 yHotSpot) 
[0x0004e] in :0
at System.Windows.Forms.XplatUI.DefineCursor (System.Drawing.Bitmap bitmap, 
System.Drawing.Bitmap mask, System.Drawing.Color cursor_pixel, 
System.Drawing.Color mask_pixel, System.Int32 xHotSpot, System.Int32 yHotSpot) 
[0x0] in :0
at System.Windows.Forms.Cursor.CreateCursor (System.IO.Stream stream) [0x00058] 
in :0
at System.Windows.Forms.Cursor..ctor (System.Type type, System.String resource) 
[0x00021] in :0
at System.Windows.Forms.Cursors.get_SizeNWSE () [0x0001a] in 
:0
at System.Windows.Forms.SizeGrip..ctor (System.Windows.Forms.Control 
CapturedControl) [0x6] in :0
at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.SizeGrip..ctor(System.Windows.Forms.Control)
at System.Windows.Forms.ScrollableControl.CreateScrollbars () [0x000c2] in 
:0
at System.Windows.Forms.ScrollableControl..ctor () [0x000b0] in 
:0
at System.Windows.Forms.ContainerControl..ctor () [0xe] in 
:0
at System.Windows.Forms.Form..ctor () [0x00012] in 
:0
at RepetierHost.Main..ctor () [0x0015b] in :0
at (wrapper remoting-invoke-with-check) RepetierHost.Main..ctor()
at RepetierHost.Program.Main () [0x00011] in 
:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: A null reference 
or invalid value was found [GDI+ status: InvalidParameter]
at System.Drawing.GDIPlus.CheckStatus (System.Drawing.Status status) [0x0009b] 
in <728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Int32 width, System.Int32 height, 
System.Drawing.Imaging.PixelFormat format) [0x00017] in 
<728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Drawing.Image original, System.Int32 
width, System.Int32 height) [0x0] in <728fbd68fe594062895e1f819791e76a>:0
at System.Drawing.Bitmap..ctor (System.Drawing.Image original, 
System.Drawing.Size newSize) [0x00010] in <728fbd68fe594062895e1f819791e76a>:0
at (wrapper remoting-invoke-with-check) 
System.Drawing.Bitmap..ctor(System.Drawing.Image,System.Drawing.Size)
at System.Windows.Forms.XplatUIX11.DefineCursor (System.Drawing.Bitmap bitmap, 
System.Drawing.Bitmap mask, System.Drawing.Color cursor_pixel, 
System.Drawing.Color mask_pixel, System.Int32 xHotSpot, System.Int32 yHotSpot) 
[0x0004e] in :0
at System.Windows.Forms.XplatUI.DefineCursor (System.Drawing.Bitmap bitmap, 
System.Drawing.Bitmap mask, System.Drawing.Color cursor_pixel, 
System.Drawing.Color mask_pixel, System.Int32 xHotSpot, System.Int32 yHotSpot) 
[0x0] in :0
at System.Windows.Forms.Cursor.CreateCursor (System.IO.Stream stream) [0x00058] 
in :0
at System.Windows.Forms.Cursor..ctor (System.Type type, System.String resource) 
[0x00021] in :0
at System.Windows.Forms.Cursors.get_SizeNWSE () [0x0001a] in 
:0
at System.Windows.Forms.SizeGrip..ctor (System.Windows.Forms.Control 
CapturedControl) [0x6] in :0
at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.SizeGrip..ctor(System.Windows.Forms.Control)
at System.Windows.Forms.ScrollableControl.CreateScrollbars () [0x000c2] in 
:0
at System.Windows.Forms.ScrollableControl..ctor () [0x000b0] in 
:0
at System.Windows.Forms.ContainerControl..ctor () [0xe] in 
:0
at System.Windows.Forms.Form..ctor () [0x00012] in 
:0
at RepetierHost.Main..ctor () [0x0015b] in :0
at (wrapper remoting-invoke-with-check) RepetierHost.Main..ctor()
at RepetierHost.Program.Main () [0x00011] in 
:0

Bug#974884: GLib-GObject-CRITICAL g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

[debian-testing]

Package: repsnapper
Version: 2.5a5-2+b1

Fresh install of Debian 11 Bullseye with minimal LXDE. repsnapper gives the 
following error:

(repsnapper:): GLib-GObject-WARNING **: : specified class size for type 
'PangoXFace' is smaller than the parent type's 'PangoFontFace' class size

(repsnapper:): GLib-GObject-CRITICAL **: : 
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
Segmentation fault

apt search repsnapper
repsnapper/testing,now 2.5a5-2+b1 amd64 [installed]

uname -a
Linux  5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux

Bug#886419: systray-mdstat: complains at startup, despite everything appears to be fine

[Axel Beckert]

Hi Francesco,

Francesco Poli wrote:
> > > Please ping me, when the new version is in Debian testing (or, at
> > > least, in unstable): I will give it a try.
> > 
> > Will do.
> 
> Thanks.

Just uploaded 1.2.0-1 to Debian Unstable. I closed this bug report as
I strongly suspect that your issues are gone with using different
backend libraries for notifications now.

Please try out and check if that's really the case. If not, please
reopen with details about how the issue manifests now with the new
release.

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

Bug#974890: mp3gain: dies on startup, complaining of missing ASan runtime

[Adam Borowski]

Package: mp3gain
Version: 1.6.2-1+b1
Severity: important

Trying to run mp3gain results in:
==23813==ASan runtime does not come first in initial library list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.

And indeed, invoking it as:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 mp3gain -p -a *mp3
does the trick.


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

Kernel: Linux 5.9.8-umbar-00018-g2ea74562d0b5 (SMP w/6 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mp3gain depends on:
ii  libasan6 10.2.0-17
ii  libc62.31-4
ii  libmpg123-0  1.26.3-1

mp3gain recommends no packages.

mp3gain suggests no packages.

-- no debconf information

Bug#961764: #961764: texi2html: texi2html embeds User and Date information in generated .html files

[Vagrant Cascadian]

On 2020-11-15, Vagrant Cascadian wrote:
> On 2020-05-28, Vagrant Cascadian wrote:
>> Files generated by texi2html often embed the build user and build date.
...
> I've tested the attached a simpler one-line patch that removes the
> default user value rather than the entire code handling user and date.
>
> I've read:
>
>   https://wiki.debian.org/qa.debian.org
>
> But did not see anything about what the process for a QA upload was...
>
> As this fixes reproducibility issues in several packages, it would be
> nice to see this included in time for bullseye!
>
> Thanks for your review, and please let me know if I should proceed with
> the upload, or any changes to make, or process to follow, etc.

Well, pabs pointed me to the devref and encouraged me to upload.

I made some additional relatively trivial fixes to the packages and
uploaded via dgit.

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#954794: New packages must not declare themselves Essential

[Guillem Jover]

On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:
> Could I ask you to explain your wanting to reduce the Essential set for
> the sake of small installation size in more detail, including some
> numbers, please?  It would be good to get to the bottom of Bill's worry
> about this change, but in addition, I would like to see a stronger
> positive case.

I'm not sure about Josh, but I think the main reasons for wanting to
reduce the essential set are:

  - Making chroots/containers slimmer, which can have a substantial
impact when needing lots of them, where even few MiB can make a
difference.
  - Making bootstrapping (build and installation) in general easier,
even though for the former these packages also need to then
be ideally removed from the build-essential set too.

Then there are these:

  - Making the packaging system less opaque, as the full implications
of Essential:yes do not seem generally clear to all maintainers?
  - Making it easier to use alternative implementations for some of
these packages, as then it's easier to know what depends on what,
instead of having to unconditionally provide the entire interface
surface for anything.
  - Making it easier to handle some multiarch problems, as then
dependencies can be explicitly marked as needed.

Thanks,
Guillem

Bug#954794: New packages must not declare themselves Essential

[Guillem Jover]

On Wed, 2020-09-30 at 18:34:06 -0700, Jonathan Nieder wrote:
> Josh Triplett wrote:
> > Jonathan Nieder wrote:
> > > Josh Triplett wrote:
> > > > This change does not propose eliminating the concept of Essential, nor
> > > > does it propose that any specific package become non-Essential.
> > >
> > > I think I'd be more supportive of this change if it did.  Freezing the
> > > current essential set in time feels oddly unpragmatic.  If we had a
> > > plan, even one that would take a while, to shrink the essential set,
> > > then it would be more likely to feel worth the cognitive load.

I'm in full support of trying to reduce the essential set, and this is
something we have already been trying to do for a while now:

  https://wiki.debian.org/Proposals/EssentialOnDiet
  https://wiki.debian.org/BusterPriorityRequalification

I also do not see the need to disallow adding new stuff to it if need
be. I think there's enough resistance in place that proposing that on
debian-devel would be met with quite some skepticism, *but* in case it
is needed, it would seem odd to do it anyway, even if policy disallows
it.

> > Long-term, I'd like to see that happen. But I'm a huge fan of
> > incremental steps; defining the problem as "eliminate Essential" makes
> > it both difficult enough and controversial enough to make it unlikely to
> > happen at all. Right now, the first step is "let's not let the problem
> > get any worse, and let's ensure that any new package that might have
> > otherwise used Essential must instead get packages to add a dependency".

> Even so, some *rough* consensus on the plan is very useful for helping
> people evaluate that first step.  It also gives people confidence that
> it can still move forward even if some people involved no longer have
> time to carry it forward themselves.  In this example, I think we
> agree about the ideal first (freeze the current Essential set) and
> last (eliminate Essential) steps but we don't have a clear picture of
> what happens in between.  That makes it hard to be comfortable with
> the first step because there's no reason to be confident that we'll
> get any further than that.

While the idea of completely getting rid of the Essential:yes concept
has been floated around in the bootstrapping and multiarch circles,
and seems like an interesting idea, I think it currently has too many
problems to be entertained.

Several of the Essential:yes properties [P] would need to be preserved
somehow for the packaging system to be able to operate as of now. Making
that marking implicit (some kind of lore) seems worse, than the current
explicit one, because the Essential field does not get involved much in
the package system operations anyway, it's more of a contract to be
honored by *maintainers*! Having to add Pre-Depends to tons of packages,
would probably substantially strain our dependency resolvers. Maintainer
scripts in at least the essential set are another problematic area,
so they would need to be reduced substantially, or eliminated
completely [B][D].

 [P] 
 [B] 
 [D] 

> If we don't have a rough plan, then the current state already seems
> okay: whenever someone proposes adding new Essential functionality, we
> can discuss it on debian-devel and the most likely outcome is that it
> gets rejected.

I think there are some rough plans for some of the problematic pieces,
but otherwise this seems rather premature, and I concur that the
current state seems fine.

> Some next steps that would make me more comfortable with an explicit
> freeze on Essential:
> 
> - document how to mark a package as "not safe in normal circumstances
>   to uninstall" (such as apt and systemd-sysv).  Is "Priority:
>   important" enough or should one use more?  As a package maintainer,
>   how do I mark a package as something that a user would never want to
>   deinstall in normal circumstances?

This is already supported with the Protected (old Important) fields,
and was implemented precisely to make it possible to split the
essential set into its different facets.

  

> - some rough idea about how to find undeclared dependencies.  Do we
>   do an NMU to add currently Essential packages as Pre-Depends on all
>   packages and then unmark them as Essential and let package
>   maintainers sort it out?  Is there some autodetection we can do
>   using autopkgtest?

Not all packages need Pre-Depends on currently Essential:yes packages,
but this would require careful consideration. But as mentioned above,
having to increase the amount of Pre-Depends relationships could make
our dependency resolvers and upgrades unhappy.

Trying to detect dependencies is going to be tricky, given that most
of the essential set are callable interfaces, which need to be checked

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Nick Black]

I actually seem to be seeing a variety of segfaults using this package
(1.2.18-3 atop libnotcurses1 2.0.4+dfsg.1-1),
problems that one normally certainly doesn't see. It's possible that
there's a deep rot in how I assembled this
binary package. Either way, I'll have things resolved by tomorrow's end.
I'm sorry for the negative first impression!

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Nick Black]

Thanks for the report and trying out Growlight! I've created
https://github.com/dankamongmen/growlight/issues/102
to track this issue, though I'll also report progress back here. I expect
that I can knock this out tonight (EST), and get
a new release out tomorrow or the next day. Look for a fix in 1.2.19.

How embarrassing!

Bug#954794: New packages must not declare themselves Essential

[Guillem Jover]

On Sun, 2020-10-18 at 11:43:18 +0200, Bill Allombert wrote:
> On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote:
> > More specifically, it's the right first three steps.
> > 
> > https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies
> > currently says
> > 
> > Packages are not required to declare any dependencies they
> > have on other packages which are marked Essential (see below),
> > and should not do so unless they depend on a particular
> > version of that package.[4]
> > 
> > [4] [...] If packages add unnecessary dependencies on packages
> > in this set, the chances that there will be an unresolvable
> > dependency loop caused by forcing these Essential packages to
> > be configured first before they need to be is greatly
> > increased.
> > 
> > I'd propose that as a first step we change that to
> > 
> > Packages are not required to declare any dependencies they
> > have on other packages which are marked Essential (see below),
> > but are permitted to do so even if they do not depend on a
> > particular version of that package.[4]
> 
> This is very dangerous with respect to upgrade between stable releases.
> The issue is at the time a package is made for a stable release, the
> state of Debian and Essential: yes packages is not known. It is
> unrealistic to expect Debian to plan so far in advance.
> Requiring changes to Essential packages to take into account spurious
> dependencies is too fragile.

This could refer to concerns with two opposite situations, I guess:

  - When adding new Essential:yes marks, with omitted dependencies (but
that is already a problem with the current text). In that case
the dependencies on the new Essential:yes should only be dropped
after the next stable release, or packages might assume the
presence of functionality that might not be there.
  - When removing old Essential:yes marks, with adding "excess"
dependencies, which could possibly introduce dependency loops,
that could break ordering assumptions in maintainer script
execution. This can be problematic if the requirements for the
behavior of an Essential:yes package for the affected package are
dropped before the next stable release (work even when unpacked,
Pre-Depends usage, etc), but otherwise it should be fine I guess.

Thanks,
Guillem

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Axel Beckert]

Package: growlight
Version: 1.2.18-3
Severity: important

Hi,

I was trying to figure out how to get into the menu. Neither the two
obvious variants of pressing either the highlighted character or holding
Alt pressed and pressing then the the highlighted character did work.

So I tried pressing F1 in the hope to get some help on the key bindings
(liek e.g. in aptitude or Midnight Commander).

But growlight deterministically segfaults on that keypress (at least as
root, didn't even get that with "growlight --notroot" as user — it
always just shows "Initializing..." forever (at least for minutes).

So far I unfortunately only got a not so helpful looking backtrace:

Thread 1 "growlight" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  0xc911 in handle_input (w=0x555f7880) at 
./src/notcurses/notcurses.c:5580
#1  main (argc=, argv=) at 
./src/notcurses/notcurses.c:6096
(gdb)

growlight was running in an uxterm at 105×89 which was running "ssh
root@localhost" inbetween.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages growlight depends on:
ii  libatasmart40.19-5
ii  libblkid1   2.36-3+b2
ii  libc6   2.31-4
ii  libcap2 1:2.44-1
ii  libcryptsetup12 2:2.3.4-1
ii  libdevmapper1.02.1  2:1.02.173-1
ii  libnettle8  3.6-2
ii  libnotcurses1   2.0.4+dfsg.1-1
ii  libpci3 1:3.7.0-4
ii  libpciaccess0   0.16-1
ii  libreadline88.1~rc2-2
ii  libudev1246.6-2
ii  zlib1g  1:1.2.11.dfsg-2

growlight recommends no packages.

growlight suggests no packages.

-- no debconf information

Bug#974889: digikam: missing b-d cause missing video support

[Norbert Preining]

Package: digikam
Version: 4:7.1.0-1
Severity: normal
X-Debbugs-Cc: norb...@preining.info

Hi,

the B-D are missing libavdevice-dev to get working video support.

THis is new in 7.1 AFAIR.

Best



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

Kernel: Linux 5.9.8+ (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.1.0-1
ii  digikam-private-libs  4:7.1.0-1
ii  libc6 2.31-4
ii  libgcc-s1 10.2.0-17
ii  libkf5configcore5 5.76.0-1~np1
ii  libkf5coreaddons5 5.76.0-1~np1
ii  libkf5i18n5   5.76.0-1~np1
ii  libmagick++-6.q16-8   8:6.9.11.24+dfsg-1+b2
ii  libqt5core5a  5.15.1+dfsg-2
ii  libqt5gui55.15.1+dfsg-2
ii  libqt5sql55.15.1+dfsg-2
ii  libqt5sql5-mysql  5.15.1+dfsg-2
ii  libqt5sql5-sqlite 5.15.1+dfsg-2
ii  libqt5widgets55.15.1+dfsg-2
ii  libstdc++610.2.0-17
ii  perl  5.32.0-5

Versions of packages digikam recommends:
ii  brave-browser-dev [www-browser] 1.18.52
ii  ffmpegthumbs4:20.08.3-1~np1
ii  firefox [www-browser]   82.0.3-1
ii  google-chrome-stable [www-browser]  86.0.4240.198-1
ii  konqueror [www-browser] 4:20.08.3-1
ii  links [www-browser] 2.21-1
ii  lynx [www-browser]  2.9.0dev.6-1
ii  w3m [www-browser]   0.5.3-38+b1

Versions of packages digikam suggests:
pn  digikam-doc 
ii  systemsettings  4:5.20.3-1~np1

-- no debconf information

Bug#974087: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Guillem Jover]

On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> On 2020-11-14, Sune Vuorela wrote:
> > Unfortunately, only like 10% of the relevant packages have test suites
> > enabled and run, because gettings things to work reliable is sometimes
> > hard.

> So, based on your estimate and the current packages known to be
> affected, Debian might have an additional 300 packages that might
> someday enable test suites. That is ~1% of the archive that would need
> to make a one-line change in debian/rules if the maintainers enable test
> suites for those packages.
> 
> Are there any templates or documentation used for such packages that
> might be able to facilitate the process?

It looks like if this cannot be fixed in the test suite themselves for
now, then refactoring this setting into a dh sequencer could cover it
automatically for all these cases?

> > Adding more hurdles does not help. 
> > I think this is a hurdle we do not need.
> 
> To me, a one-line change in packaging seems like a quite small hurdle in
> the short-term, but clearly you do not agree.

This being just a default change that can be overridden with a one
line modification, seems to me also to be quite unobtrusive. More so
when we have things like hardening that people are overriding all over
the place w/o much of an issue.

> So it really comes down to applying opt-in patches for hundreds (maybe
> thousands) of packages, or an opt-out change for somewhere in the
> ballpark of tens or hundreds of packages.

Yes, that's my view too. I had the patch queued in dpkg for my next
push, but I've pulled it out for now given the raised concern, but
I'm not seeing a very strong case here to not include it again TBH.

> Long-term, of course it would be more ideal to fix QFINDTESTDATA to be
> compatible with -ffile-prefix-map/-fmacro-prefix-map compiler flags
> being used to strip the build path from the compiled outputs; this would
> solve the issue for potentially hundreds of packages and would make the
> issue essentially moot.

Yes.

Thanks,
Guillem

Bug#950444: #950444: intltool: race condition with cache files

[Vagrant Cascadian]

On 2020-09-28, Vagrant Cascadian wrote:
> On 2020-02-01, Vagrant Cascadian wrote:
>> A fix for a race condition was submitted upstream. The effects result in
>> partial or completely missing translations. The Reproducible Builds
>> folks have identified over twenty packages which may be affected:
...
>   
> https://tests.reproducible-builds.org/debian/issues/unstable/translations_missing_due_to_intltool_merge_issue.html
>
>
>> The fix was submitted and merged upstream some years ago, but a new
>> release was never made:
>>
>>   https://bugs.launchpad.net/intltool/+bug/1687644
>>   https://bazaar.launchpad.net/~intltool/intltool/trunk/revision/748
>
> I've submitted a merge request to the gnome-team for the original patch,
> with some minor typos fixed in the commit message:
>
>   https://salsa.debian.org/gnome-team/intltool/-/merge_requests/2
>
>
> While there has been no upstream release of intltool in quite some
> years, this patch has been in upstream revision control since 2017 (as
> of now, it is the *only* patch that isn't already in the version in
> Debian).
>
> Please consider merging this patch and uploading, as it should fix
> reproducibility issues for several other packages. Or would you consider
> it acceptible to NMU?

I would like to proceed with an NMU in a few days, as this is a
non-deterministic race condition that affects reproducibility in several
other packages in Debian, and would be very nice to have resolved in
time for bullseye. Please let me know if I should hold off.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#973623:

[Michael Hudson-Doyle]

I concocted a test case that was independent from ghc, confirmed it still
reproduced with current binutils git and filed an upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=26902. I even made a little
patch that fixes the problem but I don't know if it's in any way correct.

Bug#961764: #961764: texi2html: texi2html embeds User and Date information in generated .html files

[Vagrant Cascadian]

On 2020-05-28, Vagrant Cascadian wrote:
> Files generated by texi2html often embed the build user and build date.

It turns out the build date used respects SOURCE_DATE_EPOCH, so the date
is not a big issue.


> The attached patch removes the code which embeds the build date and
> build user in order to achieve reproducible builds for the texi2html
> package itself, as well as several other packages identified by the
> reproducible builds project:
>
>   
> https://tests.reproducible-builds.org/debian/issues/unstable/texi2html_captures_users_gecos_issue.html
>
> Maybe additional packages would benefit from this patch as well.

I've tested the attached a simpler one-line patch that removes the
default user value rather than the entire code handling user and date.

I've read:

  https://wiki.debian.org/qa.debian.org

But did not see anything about what the process for a QA upload was...


As this fixes reproducibility issues in several packages, it would be
nice to see this included in time for bullseye!

Thanks for your review, and please let me know if I should proceed with
the upload, or any changes to make, or process to follow, etc.


live well,
  vagrant

diff -Nru texi2html-1.82+dfsg1/debian/changelog texi2html-1.82+dfsg1/debian/changelog
--- texi2html-1.82+dfsg1/debian/changelog	2015-12-23 10:06:38.0 -0800
+++ texi2html-1.82+dfsg1/debian/changelog	2020-11-15 16:42:38.0 -0800
@@ -1,3 +1,10 @@
+texi2html (1.82+dfsg1-6) unstable; urgency=medium
+
+  * QA upload.
+  * Do not embed the build user in html files (Closes: #961764).
+
+ -- Vagrant Cascadian   Sun, 15 Nov 2020 16:42:38 -0800
+
 texi2html (1.82+dfsg1-5) unstable; urgency=medium
 
   * QA upload.
diff -Nru texi2html-1.82+dfsg1/debian/patches/do-not-embed-the-build-user-in-html-file.patch texi2html-1.82+dfsg1/debian/patches/do-not-embed-the-build-user-in-html-file.patch
--- texi2html-1.82+dfsg1/debian/patches/do-not-embed-the-build-user-in-html-file.patch	1969-12-31 16:00:00.0 -0800
+++ texi2html-1.82+dfsg1/debian/patches/do-not-embed-the-build-user-in-html-file.patch	2020-11-15 16:42:38.0 -0800
@@ -0,0 +1,21 @@
+From: Vagrant Cascadian 
+Date: Sun, 15 Nov 2020 19:26:28 +
+X-Dgit-Generated: 1.82+dfsg1-6 914779331fe9fed1dfd59830fa18994884c00368
+Subject: Do not embed the build user in html files (Closes: #961764).
+
+Bug-Debian: https://bugs.debian.org/961764
+Forwarded: no
+Last-Update: 2020-11-15
+
+---
+
+--- texi2html-1.82+dfsg1.orig/texi2html.pl
 texi2html-1.82+dfsg1/texi2html.pl
+@@ -7164,7 +7164,6 @@ sub pass_text($$)
+ $Texi2HTML::THISDOC{'program'} = $THISPROG;
+ $Texi2HTML::THISDOC{'program_homepage'} = $T2H_HOMEPAGE;
+ $Texi2HTML::THISDOC{'program_authors'} = $T2H_AUTHORS;
+-$Texi2HTML::THISDOC{'user'} = $T2H_USER;
+ $Texi2HTML::THISDOC{'user'} = $Texi2HTML::Config::USER if (defined($Texi2HTML::Config::USER));
+ $Texi2HTML::THISDOC{'authors'} = [] if (!defined($Texi2HTML::THISDOC{'authors'}));
+ $Texi2HTML::THISDOC{'subtitles'} = [] if (!defined($Texi2HTML::THISDOC{'subtitles'}));
diff -Nru texi2html-1.82+dfsg1/debian/patches/series texi2html-1.82+dfsg1/debian/patches/series
--- texi2html-1.82+dfsg1/debian/patches/series	2015-12-23 09:33:22.0 -0800
+++ texi2html-1.82+dfsg1/debian/patches/series	2020-11-15 16:42:38.0 -0800
@@ -3,3 +3,4 @@
 03_add_build-date_param.patch
 04_sort-perl-hash
 05_reproducible-build
+do-not-embed-the-build-user-in-html-file.patch


signature.asc
Description: PGP signature

Bug#972813: xournal FTBFS: wrongly declared R³

[Guillem Jover]

Hi!

On Sat, 2020-10-24 at 11:54:54 +0200, Niels Thykier wrote:
> Rather, I suspect the issue is that Rules-Requires-Root is set to "No"
> rather than "no".  AFAICT, only "no" has been defined and it is
> interpreted case sensitively.

Right, and even though this is described in the deb822(5) man page, it
is not explicitly spelled out in the various specific file format man
pages, so I've clarified that there. Also added more clear references
to deb822(5) in the relevant man pages. Patches attached.

> @Guillem/Dpkg Maintainers: Should we provide stricter validation for
> this to stop this at dpkg-source build time ?

Yeah, I think that make sense, as dpkg-buildpackage is already
erroring out on unknown values for «dpkg/» namespaced keywords. So I
prepared the attached patch to do this too.

Thanks,
Guillem
From 4eb8dbf07cf77229db2413ad1cf6a424e6cbfb3d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 15 Nov 2020 19:32:08 +0100
Subject: [PATCH] =?UTF-8?q?doc,=20man:=20Clarify=20that=20R=C2=B3=20values?=
 =?UTF-8?q?=20are=20case=20sensitive?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is clear from the deb822(5) man page, but we can make this clear on
the brief format description for each of these file formats.

Prompted-by: Niels Thykier 
---
 doc/rootless-builds.txt | 2 +-
 man/deb-buildinfo.pod   | 3 ++-
 man/deb-changes.pod | 3 ++-
 man/deb-control.pod | 3 ++-
 man/deb-src-control.pod | 3 ++-
 man/dsc.pod | 3 ++-
 6 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/doc/rootless-builds.txt b/doc/rootless-builds.txt
index 3298768ec..af0a32836 100644
--- a/doc/rootless-builds.txt
+++ b/doc/rootless-builds.txt
@@ -25,7 +25,7 @@ We add a new field to the "Source" stanza of debian/control:
 
   Rules-Requires-Root: no | binary-targets | 
 
-The values are defined as:
+The case sensitive values are defined as:
 
  * If "no", then "debian/rules binary" will not require root at all (not even
fakeroot).
diff --git a/man/deb-buildinfo.pod b/man/deb-buildinfo.pod
index 79894bd8a..8b3e9ffd4 100644
--- a/man/deb-buildinfo.pod
+++ b/man/deb-buildinfo.pod
@@ -35,7 +35,8 @@ Each field begins with a tag, such as
 B
 or
 B
-(case insensitive), followed by a colon, and the body of the field.
+(case insensitive), followed by a colon, and the body of the field
+(case sensitive unless stated otherwise).
 Fields are delimited only by field tags.
 In other words, field text may be multiple lines in length, but the
 installation tools will generally join lines when processing the body
diff --git a/man/deb-changes.pod b/man/deb-changes.pod
index 5b7aad78d..797a4a56a 100644
--- a/man/deb-changes.pod
+++ b/man/deb-changes.pod
@@ -35,7 +35,8 @@ Each field begins with a tag, such as
 B
 or
 B
-(case insensitive), followed by a colon, and the body of the field.
+(case insensitive), followed by a colon, and the body of the field
+(case sensitive unless stated otherwise).
 Fields are delimited only by field tags.
 In other words, field text may be multiple lines in length, but the
 installation tools will generally join lines when processing the body
diff --git a/man/deb-control.pod b/man/deb-control.pod
index 645905920..216f1cd02 100644
--- a/man/deb-control.pod
+++ b/man/deb-control.pod
@@ -40,7 +40,8 @@ Each field begins with a tag, such as
 B
 or
 B
-(case insensitive), followed by a colon, and the body of the field.
+(case insensitive), followed by a colon, and the body of the field
+(case sensitive unless stated otherwise).
 Fields are delimited only by field tags. In other words, field text
 may be multiple lines in length, but the installation tools will
 generally join lines when processing the body of the field (except
diff --git a/man/deb-src-control.pod b/man/deb-src-control.pod
index 9f7b4121e..45130beee 100644
--- a/man/deb-src-control.pod
+++ b/man/deb-src-control.pod
@@ -41,7 +41,8 @@ least one field. A field starts with a fieldname, such as
 B
 or
 B
-(case insensitive), followed by a colon, the body of the field and a newline.
+(case insensitive), followed by a colon, the body of the field
+(case sensitive unless stated otherwise) and a newline.
 Multi-line fields are also allowed, but each supplementary line, without a
 fieldname, should start with at least one space. The content of the multi-line
 fields is generally joined to a single line by the tools (except in the case of
diff --git a/man/dsc.pod b/man/dsc.pod
index e78eff043..34428bbd5 100644
--- a/man/dsc.pod
+++ b/man/dsc.pod
@@ -34,7 +34,8 @@ Each field begins with a tag, such as
 B
 or
 B
-(case insensitive), followed by a colon, and the body of the field.
+(case insensitive), followed by a colon, and the body of the field
+(case sensitive unless stated otherwise).
 Fields are delimited only by field tags.
 In other words, field text may be multiple lines in length, but the
 installation tools will generally join lines when processing the body
-- 
2.29.2

From 

Bug#974797: [Pkg-opencl-devel] Bug#974797: pocl: Please upgrade to llvm-toolchain-11

[Andreas Beckmann]

Control: tag -1 upstream fixed-upstream

seems to be fixed upstream, but no new release yet

Andreas

Bug#974703: found pci_device_map_range returning EINVAL

[Michael Redman]

Hello All,

Inserting some logging statements into the code, I found:

I was getting "Not enough video memory" error in SMI_PreInit() because 
pSmi->FBReserved was 0.


pSmi->FBReserved was 0 because SMI_MapMem() (called earlier in 
SMI_PreInit()) was exiting at an early if-statement, because 
pSmi->MapBase was not already set and SMI_MapMmio() was returning FALSE.


SMI_MapMmio() was returning FALSE because its call to 
pci_device_map_range() was returning EINVAL (decimal 22).


Looking at the code for pci_device_map_range() in libpciaccess 
common_interface.c, it appears EINVAL is the return value for when the 
"struct pci_device" passed in already has an existing mapping with the 
same base and size.


However I do not find any "previous" call into pci_device_map_range 
successfully creating the mapping that supposedly already exists.


Situation remains unresolved, still cannot startx.

My modified smi_driver.c and Xorg.0.log output attached.

Kind regards,

Michael Redman


--
Michael Redman
https://www.michael-redman.name
IN GOD WE TRVST.

/* Header:   //Mercury/Projects/archives/XFree86/4.0/smi_driver.c-arc   1.42   03 Jan 2001 13:52:16   Frido  $ */

/*
Copyright (C) 1994-1999 The XFree86 Project, Inc.  All Rights Reserved.
Copyright (C) 2000 Silicon Motion, Inc.  All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FIT-
NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the names of The XFree86 Project and
Silicon Motion shall not be used in advertising or otherwise to promote the
sale, use or other dealings in this Software without prior written
authorization from The XFree86 Project or Silicon Motion.
*/

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include "xf86.h"
#include "xf86DDC.h"
#include "xf86int10.h"
#include "vbe.h"

#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6
#include "xf86Resources.h"
#include "xf86RAC.h"
#endif

#include "smi.h"
#include "smi_501.h"
#include "smilynx.h"
#include "smi_crtc.h"

#include "globals.h"
#ifdef HAVE_XEXTPROTO_71
#include 
#else
#define DPMS_SERVER
#include 
#endif

#include 

/*
 * Internals
 */
static Bool SMI_MapMmio(ScrnInfoPtr pScrn);
static Bool SMI_DetectMem(ScrnInfoPtr pScrn);
static void SMI_EnableMmio(ScrnInfoPtr pScrn);
static void SMI_DisableMmio(ScrnInfoPtr pScrn);
static Bool SMI_HWInit(ScrnInfoPtr pScrn);

/*
 * Forward definitions for the functions that make up the driver.
 */

static const OptionInfoRec * SMI_AvailableOptions(int chipid, int busid);
static void SMI_Identify(int flags);
static Bool SMI_Probe(DriverPtr drv, int flags);
static Bool SMI_PreInit(ScrnInfoPtr pScrn, int flags);
static Bool SMI_EnterVT(VT_FUNC_ARGS_DECL);
static void SMI_LeaveVT(VT_FUNC_ARGS_DECL);
static Bool SMI_ScreenInit(SCREEN_INIT_ARGS_DECL);
static void SMI_DisableVideo(ScrnInfoPtr pScrn);
static void SMI_EnableVideo(ScrnInfoPtr pScrn);
static Bool SMI_CloseScreen(CLOSE_SCREEN_ARGS_DECL);
static Bool SMI_SaveScreen(ScreenPtr pScreen, int mode);
static void SMI_FreeScreen(FREE_SCREEN_ARGS_DECL);
static void SMI_ProbeDDC(ScrnInfoPtr pScrn, int index);
static void SMI_DetectPanelSize(ScrnInfoPtr pScrn);
static void SMI_DetectMCLK(ScrnInfoPtr pScrn);

/*
 * xf86VDrvMsgVerb prints up to 14 characters prefix, where prefix has the
 * format "%s(%d): " so, use name "SMI" instead of "Silicon Motion"
 */
#define SILICONMOTION_NAME  "SMI"
#define SILICONMOTION_DRIVER_NAME   "siliconmotion"
#define SILICONMOTION_VERSION_NAME  PACKAGE_VERSION
#define SILICONMOTION_VERSION_MAJOR PACKAGE_VERSION_MAJOR
#define SILICONMOTION_VERSION_MINOR PACKAGE_VERSION_MINOR
#define SILICONMOTION_PATCHLEVELPACKAGE_VERSION_PATCHLEVEL
#define SILICONMOTION_DRIVER_VERSION ((SILICONMOTION_VERSION_MAJOR << 24) | \
  (SILICONMOTION_VERSION_MINOR << 16) | \
  (SILICONMOTION_PATCHLEVEL))

#if SMI_DEBUG
int smi_indent = 1;
#endif

/* for dualhead */
int gSMIEntityIndex = -1;

/*
 * This contains the functions needed by the server after loading the
 * driver module.  

Bug#974792: beignet: Please upgrade to llvm-toolchain-11

[Andreas Beckmann]

Control: tag -1 upstream

a trivial bump to llvm 10 or 11 results in a (non-trivial?) FTBFS


Andreas

Bug#974793: [Pkg-opencl-devel] Bug#974793: Bug#974793: oclgrind: Please upgrade to llvm-toolchain-11

[James Price]

I've started adding LLVM 11 support upstream today. I will try and get this
finished soon and then push out a new upstream release that we can package
here.

James


On Sun., Nov. 15, 2020, 19:27 Andreas Beckmann,  wrote:

> Control: tag -1 upstream
>
> oclgrind FTBFS with both LLVM 10 and LLVM 11.
>
> First errors:
>
> In file included from /usr/lib/llvm-10/include/llvm/ADT/StringRef.h:12,
>  from
> /usr/lib/llvm-10/include/llvm/IR/DiagnosticHandler.h:15,
>  from /usr/lib/llvm-10/include/llvm/IR/LLVMContext.h:18,
>  from /build/oclgrind-19.10/src/core/Context.cpp:21:
> /usr/lib/llvm-10/include/llvm/ADT/STLExtras.h:559:49: error:
> 'std::index_sequence' has not been declared
>   559 |   template  value_type
> deref(std::index_sequence) const {
>   | ^~
>
> In file included from /usr/lib/llvm-11/include/llvm/ADT/Hashing.h:49,
>  from /usr/lib/llvm-11/include/llvm/ADT/ArrayRef.h:12,
>  from /usr/lib/llvm-11/include/llvm/IR/Instructions.h:18,
>  from /build/oclgrind-19.10/src/core/common.cpp:18:
> /usr/lib/llvm-11/include/llvm/Support/SwapByteOrder.h:152:13: error:
> 'enable_if_t' in namespace 'std' does not name a template type
>   152 | inline std::enable_if_t::value, T>
> getSwappedBytes(T C) {
>   | ^~~
> /usr/lib/llvm-11/include/llvm/Support/SwapByteOrder.h:152:8: note:
> 'std::enable_if_t' is only available from C++14 onwards
>   152 | inline std::enable_if_t::value, T>
> getSwappedBytes(T C) {
>   |^~~
>
>
> Andreas
>
> ___
> Pkg-opencl-devel mailing list
> pkg-opencl-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-opencl-devel

Bug#974886: pari: rnfinit hangs (regression)

[Tobias Hansen]

Package: pari-gp
Version: 2.13.0-2
Severity: normal

Hi,

with pari 2.13.0-2 the following code (which is a sagemath test and worked with 
pari 2.11.4) hangs indefinitely in gp when calling rnfinit.

? default(parisizemax, 6400)
  ***   Warning: new maximum stack size = 6400 (61.035 Mbytes).
? addprimes([31438243, 238576291, 18775387483, 24217212463267, 
1427657500359111961, 135564809928627323997297867381959])
%1 = [31438243, 238576291, 18775387483, 24217212463267, 1427657500359111961, 
135564809928627323997297867381959]
? K = bnfinit(y^4-52*y^2+26,1); pol = rnfkummer(bnrinit(K,3,1),Mat(5))
  *** rnfkummer: Warning: increasing stack size to 1600.
  *** rnfkummer: Warning: increasing stack size to 3200.
%2 = x^5 + Mod(110204030699148446242240727411928*y^3 + 
78307112557844012237261751372042*y^2 - 5674967313235540791169353111603168*y - 
4032432401431710468830825285246862, y^4 - 52*y^2 + 26)*x^3 + 
Mod(3584385289728983153736626109782883812630266327074*y^3 + 
2546938261266850926623105095261199201469991786986*y^2 - 
184578270215768626033547266289676107590835240929344*y - 
131154834263516880788254706677043629282657949113896, y^4 - 52*y^2 + 26)*x^2 + 
Mod(-15945740003655332675782861358818654840188899544932019410080320228*y^3 - 
11330482645350308816127897029643884908098414170467295139095028642*y^2 + 
821127437281616776660676358742832568035279253518770614693405673368*y + 
583464309314436137234694332457180466091106061530271825134872723487, y^4 - 
52*y^2 + 26)*x + 
Mod(-2525952539668323241105877810188736226631914278044174736728608642554334711529032666/5*y^3
 - 
1794853133635045389913501675559728057300960191252635296432148581791471098749677474/5*y^2
 + 
130074172482266569775137436374287366020035438450870128721868069952858489111087504396/5*y
 + 
92426137236702454005536614663867953386157003978148965339540012644512376720064080964/5,
 y^4 - 52*y^2 + 26)
? L = rnfinit(K, pol); polredabs(polredbest(L.polabs))


Best,
Tobias

Bug#974793: [Pkg-opencl-devel] Bug#974793: oclgrind: Please upgrade to llvm-toolchain-11

[Andreas Beckmann]

Control: tag -1 upstream

oclgrind FTBFS with both LLVM 10 and LLVM 11.

First errors:

In file included from /usr/lib/llvm-10/include/llvm/ADT/StringRef.h:12,
 from /usr/lib/llvm-10/include/llvm/IR/DiagnosticHandler.h:15,
 from /usr/lib/llvm-10/include/llvm/IR/LLVMContext.h:18,
 from /build/oclgrind-19.10/src/core/Context.cpp:21:
/usr/lib/llvm-10/include/llvm/ADT/STLExtras.h:559:49: error: 
'std::index_sequence' has not been declared
  559 |   template  value_type deref(std::index_sequence) 
const {
  | ^~

In file included from /usr/lib/llvm-11/include/llvm/ADT/Hashing.h:49,
 from /usr/lib/llvm-11/include/llvm/ADT/ArrayRef.h:12,
 from /usr/lib/llvm-11/include/llvm/IR/Instructions.h:18,
 from /build/oclgrind-19.10/src/core/common.cpp:18:
/usr/lib/llvm-11/include/llvm/Support/SwapByteOrder.h:152:13: error: 
'enable_if_t' in namespace 'std' does not name a template type
  152 | inline std::enable_if_t::value, T> getSwappedBytes(T C) 
{
  | ^~~
/usr/lib/llvm-11/include/llvm/Support/SwapByteOrder.h:152:8: note: 
'std::enable_if_t' is only available from C++14 onwards
  152 | inline std::enable_if_t::value, T> getSwappedBytes(T C) 
{
  |^~~


Andreas

Bug#972739: mmdebstrap: bullseye: /updates -> -security

[Paul Wise]

On Sun, 2020-11-15 at 16:40 +0100, Johannes Schauer wrote:

> yes, it is pointless to attempt making the coverage.sh and make_mirror.sh
> (those are the test suite) work across multiple releases such that I would
> *not* have to make changes later.
> ...

I see, makes sense.

> The reason is, that I want to minimize the required dependencies of mmdebstrap
> as much as possible, because mmdebstrap is supposed to run inside very minimal
> environments.

I wasn't aware of this design constraint, thanks for the info.

The problem with the current setup is that it is hardcoding and in my
experience, the hardcoding is forgotten about and doesn't get updated
or it generates work for users, QA or other folks to detect the
hardcoding and get it updated.

Some alternatives to hardcoding in git to mitigate this:

Hardcode at build time; build-depend on distro-info bits, extract the
needed info and stash them in a (Perl?) file in the .deb package. After
updates of distro-info in stable/oldstable, mmdebstrap can be binNMUed.

Hardcode at release time; add a check to your release scripts to ensure
that the hardcoded suite information is up-to-date with the latest
version of distro-info available.

Hardcode in a separate file; move the list of suite names that use the
-security suffix instead of /updates out of the guts of the code into a
separate file with a defined format, perhaps with a config file in /etc
so the user can override it when it is outdated. The separate file
should be more easily noticed than in the guts of the code. This option
is best combined with the release-time checks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#974870: libgdk-pixbuf2.0-dev: Plans for Xlib API deprecation

[Simon McVittie]

On Sun, 15 Nov 2020 at 21:25:56 +0100, Eduard Bloch wrote:
> it looks like upstream support for Xlib API adapters is officially
> declared deprecated now. For details, see
> https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Thanks for raising this. I think this is *mostly* relevant for Debian
12, because:

* gdk-pixbuf follows the GNOME 6-month release cycle
* gdk-pixbuf 2.40.x, released as part of GNOME 3.38, still has the -xlib
  sub-library along with the high-level library
* the first stable gdk-pixbuf that doesn't have the -xlib sub-library
  will be 2.42.x, in GNOME 40, which won't be released until long after
  Debian 11 has frozen

so we'll still be using the old combined source package for Debian 11.

Because libgdk-pixbuf2.0-dev and libgdk-pixbuf2.0-0 contain both the
base library and the -xlib part, we will eventually have to do something
like this in Debian 12 (reminiscent of what happened when the monolithic
library and -dev packages for Pango were split up):

* source: gdk-pixbuf
  - binary: libgdk-pixbuf-2.0-0
  - binary: libgdk-pixbuf-2.0-dev
* source: gdk-pixbuf-xlib
  - binary: libgdk-pixbuf-xlib-2.0-0
  - binary: libgdk-pixbuf-xlib-2.0-dev
  - transitional binary: libgdk-pixbuf2.0-0
+ Depends: libgdk-pixbuf-2.0-0, libgdk-pixbuf-xlib-2.0-0
  - transitional binary: libgdk-pixbuf2.0-dev
+ Depends: libgdk-pixbuf-2.0-dev, libgdk-pixbuf-xlib-2.0-dev

The shlibs/.symbols would generate dependencies on libgdk-pixbuf-2.0-0 and
libgdk-pixbuf-xlib-2.0-0, or perhaps on
"libgdk-pixbuf-2.0-0 #MINVER# | libgdk-pixbuf2.0-0 #MINVER" and
"libgdk-pixbuf-xlib-2.0-0 #MINVER# | libgdk-pixbuf2.0-0 #MINVER" if we
want the transition to allow downgrades.

However, it might be good to get the framework for this in place before
the Debian 11 freeze, which would look like this:

* source: gdk-pixbuf
  - binary: libgdk-pixbuf-2.0-0
  - binary: libgdk-pixbuf-2.0-dev
  - binary: libgdk-pixbuf-xlib-2.0-0
  - binary: libgdk-pixbuf-xlib-2.0-dev
  - transitional binary: libgdk-pixbuf2.0-0
+ Depends: libgdk-pixbuf-2.0-0, libgdk-pixbuf-xlib-2.0-0
  - transitional binary: libgdk-pixbuf2.0-dev
+ Depends: libgdk-pixbuf-2.0-dev, libgdk-pixbuf-xlib-2.0-dev

(That'll require a trip through NEW, of course.)

Then we can do a mass-bug-filing for packages that actively use the -xlib
sub-library, and (perhaps later) a lower-severity mass-bug-filing for
packages that build-depend on libgdk-pixbuf2.0-dev but should ideally
only B-D on libgdk-pixbuf-2.0-dev.

> maybe there should be even a warning of some kind printed
> through pkg-config or GCC warnings (although this is bad, of course,
> would break -Werror using packages).

I don't *think* we can issue warnings from pkg-config, although there
might be a mechanism available that I'm not aware of. Do you know of such
a mechanism?

We can't issue compiler warnings and simultaneously not issue compiler
warnings, we have to choose whichever is the lesser evil.

If packages in Debian are using -Werror for release builds, I personally
think that's a packaging bug, because any new gcc release with better
(or just different!) optimizations or diagnostics can start issuing new
warnings that would break those packages; so I don't think it would be
terrible to break them. It would probably be better to break them after
the Debian 11 release so that people get an entire release cycle to fix
them, though.

smcv

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-11-16 00:05:08)
> On Sun, 15 Nov 2020 23:09:27 +0100 Johannes Schauer wrote:
> > Quoting Francesco Poli (2020-11-15 22:57:38)
> As I have previously said, I am worried by security implications of
> setting "kernel.unprivileged_userns_clone=1" with sysctl.
> Bug #898446 is still being discussed...

I agree. Similarly I am worried about the security implications of running the
whole thing as root. It would be great if fakechroot would work. In the
meantime, I managed to track down the problem a bit. I put this shell snippet:

case "`FAKECHROOT_DETECT=1 /bin/echo`" in fakechroot*) echo LOADED;;*) echo NOT 
LOADED;;esac

Into various places like /etc/kernel/postinst.d/initramfs-tools,
/etc/kernel/postinst.d/initramfs-tools, /usr/sbin/update-initramfs,
/usr/sbin/mkinitramfs and /usr/share/initramfs-tools/hooks/klibc-utils and
found out that fakechroot still remains active all the way down to the deepest
level where the error is then produced by this line:

cp -pnL /usr/lib/klibc/bin/* "${DESTDIR}/bin"

The files in question *do* exist, what seems to be the problem are the
wildcards. For example this works:

mmdebstrap --mode=fakechroot --variant=apt --customize-hook='chroot "$1" sh 
-c "ls *"' unstable /dev/null

and so does this:

mmdebstrap --mode=fakechroot --variant=apt --customize-hook='chroot "$1" sh 
-c "ls ./*"' unstable /dev/null

But this fails:

mmdebstrap --mode=fakechroot --variant=apt --customize-hook='chroot "$1" sh 
-c "ls /*"' unstable /dev/null

So as soon as the wildcard is part of an absolute path, things start breaking.

Do you have the time to investigate further on this issue? This does not seem
to be a problem of initramfs-tools or a problem of fakechroot not being enabled
but a weird problem with fakechroot.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#926945: Bug#973663: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI

[Simon McVittie]

On Sun, 15 Nov 2020 at 18:49:36 +, Simon McVittie wrote:
> * An autopkgtest maintainer (most likely to be me) should convert
>   autopkgtest-build-qemu from a shell script into a Python script

Work in progress:
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/95

smcv

Bug#974883: installation-reports: Successful install on AMD Ryzen

[Laura Dove]

Package: installation-reports
Severity: minor

Hi,

No problem to report, this is a success report.

-- Package-specific info:

Boot method: USB key
Image version: Debian GNU/Linux 10.4.0 "Buster" - Unofficial amd64 NETINST with 
firmware 20200509-10:25 (torrent from 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/bt-cd/firmware-10.4.0-amd64-netinst.iso.torrent)
Date: 2020-05-21 21:43:13 +0200

Machine: Compact Fanless AMD Ryzen Mini PC
Partitions: (df -Tl)

Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   79076600   7907660   0% /dev
tmpfs  tmpfs  1589244  740   1588504   1% /run
/dev/sda3  ext4  14352840  3815856   9788184  29% /
tmpfs  tmpfs 51204  5116   1% /run/lock
tmpfs  tmpfs  33738600   3373860   0% /dev/shm
/dev/sda2  ext427538742828213820  17% /boot
/dev/sda1  vfat 47371 5288 42083  12% /boot/efi
/dev/sda7  ext4 466841176 96470864 346586376  22% /donnees
/dev/sda6  ext4   4740224   138528   4341192   4% /home
/dev/sda5  ext4   3779640   468668   3099260  14% /var
tmpfs  tmpfs   20480041284163516  21% /tmp

(fdisk -l /dev/sda)

Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: TS512GMTS430S   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B31FF558-4100-4170-9B4A-C0B4A5409C78

DeviceStartEnd   Sectors   Size Type
/dev/sda1  2048  98303 9625647M EFI System
/dev/sda2 98304 684031585728   286M Linux filesystem
/dev/sda3684032   29980671  2929664014G Linux filesystem
/dev/sda4  29980672   31934463   1953792   954M Linux swap
/dev/sda5  31934464   39747583   7813120   3,7G Linux filesystem
/dev/sda6  39747584   49512447   9764864   4,7G Linux filesystem
/dev/sda7  49512448 1000214527 950702080 453,3G Linux filesystem


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [ ]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I disabled secure boot in the BIOS for the install; now I can't seem able to
make it work: I get a message on boot about invalid keys. (I don't know
whether installing with secure boot from the start would've worked.)

I had no CD to detect; the install USB key was detected fine.

I like to control things and messed up partitions a few times (the defaults
didn't suit me) but encountered no actual problem with the installer. The
rest of the installation was rather straightforward.

I created my user and installed packages by hand afterwards (not via tasks),
including switching from SystemD to SysV init.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u4"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux caramel 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15d0]
lspci -knn: Subsystem: ASRock Incorporation Device [1849:15d0]
lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:15d1]
lspci -knn: Subsystem: ASRock Incorporation Device [1849:15d1]
lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:01.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:01.5 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:1452]
lspci -knn: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device [1022:15db]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Device 

Bug#974882: RFS: pentobi/18.3-1 -- clone of the strategy board game Blokus

[Juhani Numminen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pentobi
   Version : 18.3-1
   Upstream Contact: https://github.com/enz/pentobi/issues
 * URL : https://pentobi.sourceforge.io
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/games-team/pentobi
   Section : games

It builds those binary packages:

  pentobi - clone of the strategy board game Blokus
  pentobi-kde-thumbnailer - clone of the strategy board game Blokus - KDE 
thumbnailer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pentobi/pentobi_18.3-1.dsc

Changes since the last upload:

 pentobi (18.3-1) unstable; urgency=medium
 .
   * New upstream release.
   * d/control:
 - Use debhelper compatibility level v13.
 - Remove Dean Evans from uploaders because of long inactivity.
   Thank you for your contribution as the initial maintainer!
 - Bump Standards-Version to 4.5.0. No changes needed.
 - Depend on qml-module-qtqml just to avoid issues with Qt 5.14 and earlier
   (Closes: #973855).
   * d/copyright:
 - Update years.
 - Change Upstream-Contact from the recently closed mailing list to
   GitHub issue tracker.
   * d/rules: Drop the custom linker flag -Wl,--as-needed which is not
 necessary anymore after becoming the default.

Other things:

Reproducible Builds are getting an FTBFS on bullseye. I'll be monitoring it
in hopes that it is going to go away soon because unstable is not affected.
See 
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/pentobi.html

Regards,
Juhani Numminen

Bug#974881: node-debbundle-es-to-primitive has circular Depends on node-es-abstract

[Bill Allombert]

Package: node-debbundle-es-to-primitive
Version: 1.2.1+~cs9.7.15-1
Severity: important

Dear Debian Javascript Maintainers,

There is a circular dependency between node-debbundle-es-to-primitive and 
node-es-abstract:

node-debbundle-es-to-primitive  :Depends: node-es-abstract
node-es-abstract:Depends: node-debbundle-es-to-primitive

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should try to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sun, 15 Nov 2020 23:09:27 +0100 Johannes Schauer wrote:

[...]
> Quoting Francesco Poli (2020-11-15 22:57:38)
[...]
> >   $ mmdebstrap-autopkgtest-qemu 8GiB
> >   I: automatically chosen mode: fakechroot
> >   [...]
> 
> that's the culprit. Try using --mode=unshare. With fakechroot I see the errors
> that you see. It works with unshare mode.

As I have previously said, I am worried by security implications of
setting "kernel.unprivileged_userns_clone=1" with sysctl.
Bug #898446 is still being discussed...

[...]
> One suggestion would be to throw in a "set -e" at the beginning

Done, thanks for the suggestion!
It definitely makes sense for such a script.



-- 
 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


pgp7PzbTY8TiY.pgp
Description: PGP signature

Bug#973489: libvirt-daemon-system: upgrade overwrites generated file /etc/libvirt/qemu/networks/default.xml

[Thorsten Glaser]

Andrea Bolognani dixit:

>I've taken a stab at addressing this:

Thanks!

>  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/78
>
>Thorsten, I would appreciate if you could take a look, especially
>since you seem to have some familiarity with this sort of situation
>already.

I’ve not yet been involved in doing the same thing correctly
manually, but this looks (as far as I know) good.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#916951:

[JENNY DESMOND]

how are you

Bug#973489: libvirt-daemon-system: upgrade overwrites generated file /etc/libvirt/qemu/networks/default.xml

[Andrea Bolognani]

On Tue, Nov 10, 2020 at 12:20:13AM +0100, Andrea Bolognani wrote:
> I agree that it should probably not be in /etc; in fact, the upstream
> spec file deals with it pretty much how Thorsten suggested above:
> 
>   %install
> 
>   install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/
>   cp $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml \
>  $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml
>   chmod 0600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/default.xml
> 
>   %post daemon-config-network
> 
>   if test $1 -eq 1 && test ! -f 
> %{_sysconfdir}/libvirt/qemu/networks/default.xml; then
> UUID=`/usr/bin/uuidgen`
> sed -e "s/${orig_sub}/${sub}/g" \
> -e "s,,\n  $UUID," \
>  < %{_datadir}/libvirt/networks/default.xml \
>  > %{_sysconfdir}/libvirt/qemu/networks/default.xml
> ln -s ../default.xml 
> %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml
> chmod 0600 %{_sysconfdir}/libvirt/qemu/networks/default.xml
>   fi
> 
> We should do something similar in Debian as well, possibly including
> shipping the default network configuration in a separate binary
> package. I'll look into it over the next few days :)

I've taken a stab at addressing this:

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/78

Thorsten, I would appreciate if you could take a look, especially
since you seem to have some familiarity with this sort of situation
already.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#803988:

[JENNY DESMOND]

  how are you

Bug#907240:

[JENNY DESMOND]

  how are you

Bug#974880: RM: polyphone [s390x hppa m68k ppc64 sparc64] -- ANAIS; package is little-endian only

[Thorsten Glaser]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Dear ftpmasters,

I had to change the package to little-endian only because it
would not work right on big-endian platforms due to hardcoded
assumptions too large to quickly fix. Upstream is informed.

In the meantime, please remove the outdated binary packages
from sid so that the new version can migrate in a few days.

Thanks in advance!

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-11-15 22:57:38)
> On Sun, 15 Nov 2020 21:05:08 +0100 Johannes Schauer wrote:
> > Which mode was mmdebstrap run in?
> 
>   $ mmdebstrap-autopkgtest-qemu 8GiB
>   I: automatically chosen mode: fakechroot
>   [...]

that's the culprit. Try using --mode=unshare. With fakechroot I see the errors
that you see. It works with unshare mode.

> > Maybe this is something similar to this initramfs-tools bug that popped up
> > with fakechroot:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944929
> 
> Isn't that fixed in unstable and in testing?

Yes, but the reason might be a similar one. Fakechroot works by preloading
libfakechroot.so and if any maintainer script messes with the environment
variables, then fakechroot gets disabled for that process.

> > Can you share the whole script that you used for these results?
> 
> Sure, the modified script is attached.
> 
> As I said before, the script is what I am trying to develop, based on
> your suggestions.
> It is still experimental, needs to be improved in many aspects, and has
> not yet produced any working QEMU image (!). I wanted to send it to you
> as a contribution to mmdebstrap, once it was mature enough.
> I am sending it to you as a preview (not to be included in the official
> package, yet!).

One suggestion would be to throw in a "set -e" at the beginning because
otherwise you'd have to check the exit status of each program execution
manually.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#974879: ITP: intervalstorej -- Java implementation of the Nested Containment List data structure

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian Java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: intervalstorej
  Version : 1.2
  Upstream Author : Mungo Carstairs, Barton Group
* URL : https://github.com/bartongroup/IntervalStoreJ/
* License : BSD-3-clause
  Programming Lang: Java
  Description : Java implementation of the Nested Containment List data 
structure

NCList provides efficient lookup of intervals overlapping a given range in
time O(M log N) where N is the number of intervals stored, and M the number
of overlaps found.

IntervalStore:
- is parameterised by ;
- so can store any Java type that implements IntervalI, that is, has methods
 getBegin() and getEnd() (where begin <= end);
- extends java.util.AbstractCollection;
- may be referred to as Collection in code;
- exposes methods for add, contains, remove, iterator, size etc;
- has a 'bulk load' constructor, and methods to add or remove entries, while
 retaining lookup efficiency;
- optimises storage and search of sparsely nested intervals by storing
 non-nested intervals separately;
- incorporates NCList to store any properly nested intervals.

This package is needed as a dependency of jalview, which is currently updated
as we have a quite old version of it in Debian. jalview now relies on it.

It will be maintained inside the Debian Java team.

Bug#974755: smartd: Problematic memory activity (triggers oom-killer)

[Christian Franke]

smartd.conf file ?
If DEVICESCAN is used: How many devices are detected ?

Triggering self-tests should not require any additional memory as the 
actual tests are handled by drive firmware.


Regards,
Christian
smartmontools.org

Bug#974846: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework

[Daniele E. Domenichelli]

Hi Stuart,

On 15/11/2020 15:13, Stuart Prescott wrote:

Now is not the time to be introducing things that depend on Python 2, given
that Python 2 is almost completely removed from the next release of Debian.


Unfortunately python3 is not supported by the framework.
I just uploaded a new version of the package, without the python2 library.

Cheers,
 Daniele

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sun, 15 Nov 2020 21:05:08 +0100 Johannes Schauer wrote:

[...]
> Which mode was mmdebstrap run in?

  $ mmdebstrap-autopkgtest-qemu 8GiB
  I: automatically chosen mode: fakechroot
  [...]

> Maybe this is something similar to this
> initramfs-tools bug that popped up with fakechroot:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944929

Isn't that fixed in unstable and in testing?

> 
> Can you share the whole script that you used for these results?

Sure, the modified script is attached.

As I said before, the script is what I am trying to develop, based on
your suggestions.
It is still experimental, needs to be improved in many aspects, and has
not yet produced any working QEMU image (!). I wanted to send it to you
as a contribution to mmdebstrap, once it was mature enough.
I am sending it to you as a preview (not to be included in the
official package, yet!).

Please note that I am running it on an amd64 box. Hence:

  $ dpkg --print-architecture
  amd64


-- 
 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


mmdebstrap-autopkgtest-qemu
Description: Binary data


pgp8NMDVxsfYc.pgp
Description: PGP signature

Bug#954433: radvd: PIDFile in /lib/systemd/system/radvd.service must be moved from /var/run/ to /run/

[Geert Stappers]

On Sun, Nov 15, 2020 at 10:01:21PM +0100, Geert Stappers wrote:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -117,9 +117,9 @@ AC_MSG_RESULT($PATH_RADVD_LOG)
>  dnl Check where to put the pidfile
>  AC_MSG_CHECKING(where to put pidfile)
>  AC_ARG_WITH(pidfile,
> -[  --with-pidfile  Path to the radvd pidfile [/var/run/radvd.pid]],
> +[  --with-pidfile  Path to the radvd pidfile [/run/radvd.pid]],
> PATH_RADVD_PID=$withval,
> -   PATH_RADVD_PID=/var/run/radvd.pid)
> +   PATH_RADVD_PID=/run/radvd.pid)
>  AC_MSG_RESULT($PATH_RADVD_PID)
>  
>  dnl Check where to put the configfile
> 

Upstream has a simular fix.



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#974838: grub: GRUB as of 2020-November.15: Failure to boot multiple systems - seemingly random

[waxhead]

Colin Watson wrote:

Control: reassign -1 grub-pc

On Sun, Nov 15, 2020 at 12:47:34PM +0100, waxhead wrote:

First I hope I am reporitng this on the correct package. Apologize if not.


grub is GRUB Legacy; grub-pc is GRUB 2.  (Though I'm guessing that
you're using BIOS, rather than UEFI; on a UEFI system it would be
grub-efi-amd64 instead.)

We definitely need to know what version of GRUB you're using.


Correct, I am using GRUB2 and a classic BIOS boot. On this system the 
mainboard is a ASUS P5B Deluxe from about 2007-2008 without UEFI.


Currently on this system the package version is grub-pc 2.04-10



I have various systems all running BTRFS as the rootfs. BTRFS is installed on 
partitions that are offset of the first sector=2048
The systems I use range from 8 to 20 drives. BTRFS is set up with data=raid1 , 
and metadata =raid1c4
After updates which update the grub package GRUB fails very often on my systems.
I can't remember all the error codes I have had,  which makes this a rather 
poor bug report, but the latest one (today) was:


Every distinct error is potentially a distinct bug.  I'm going to refuse
to deal with more than one distinct error in a single bug report,
because that's entirely unmanageable, so I'll focus on this one:

Understood. I do however think it is important to know the background 
story to emphasize that there *may* be more than a lone bug.


It might be that I am restarting a server tomorrow. If I do I assume 
that I get the same boot problems that have prevented us from remote 
restarting this successfully the last couple of months - I'll try to 
gather all relevant info and post individual bugreports on each differnt 
prompt I get.



error: symbol 'grub_calloc' not found.
grub rescue>


This sounds like #966575, so it's vital for us to know what version of
grub-pc you have installed.  We'll also need the output of "debconf-show
grub-pc" and information about the disk setup of your system.



#debconf-show grub-pc
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/chainload_from_menu.lst: true
* grub-pc/install_devices: 
/dev/disk/by-id/ata-SanDisk_SDSSDXP120G_[CENCORED]

  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/timeout: 5
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/disk_description:
  grub-pc/partition_description:
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_failed: false
  grub2/force_efi_extra_removable: false
* grub2/linux_cmdline:
  grub2/kfreebsd_cmdline:
* grub2/linux_cmdline_default:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_empty: false
  grub-pc/install_devices_disks_changed:
  grub2/update_nvram: true
  grub-pc/hidden_timeout: false

Not sure what info you're after - but this is from this machine.
All SSD's grub-install done on sda,sdb,sdc,sdd,sde,sdf and sdg

#lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 238.5G  0 disk
├─sda1   8:10 107.8G  0 part
├─sda2   8:20 4G  0 part [SWAP]
└─sda3   8:30  55.9G  0 part /VMs
sdb  8:16   0 238.5G  0 disk
├─sdb1   8:17   0 107.8G  0 part
├─sdb2   8:18   0 4G  0 part [SWAP]
└─sdb3   8:19   0  55.9G  0 part
sdc  8:32   0 111.8G  0 disk
├─sdc1   8:33   0 107.8G  0 part /
├─sdc2   8:34   0 1K  0 part
└─sdc5   8:37   0 4G  0 part [SWAP]
sdd  8:48   0 238.5G  0 disk
├─sdd1   8:49   0 107.8G  0 part
├─sdd2   8:50   0 4G  0 part [SWAP]
└─sdd3   8:51   0  55.9G  0 part
sde  8:64   0 167.7G  0 disk
├─sde1   8:65   0 107.8G  0 part
├─sde2   8:66   0 4G  0 part [SWAP]
└─sde3   8:67   0  55.9G  0 part
sdf  8:80   0 111.8G  0 disk
├─sdf1   8:81   0 107.8G  0 part
└─sdf2   8:82   0 4G  0 part [SWAP]
sdg  8:96   0 111.8G  0 disk
├─sdg1   8:97   0 107.8G  0 part
└─sdg2   8:98   0 4G  0 part [SWAP]
sr0 11:01  1024M  0 rom

all partition #1 are BTRFS and all partition#3 are a separate BTRFS 
filesystem as well.


#lsscsi
[2:0:0:0]diskATA  OCZ-VECTOR   3.0   /dev/sda
[3:0:0:0]diskATA  OCZ-VECTOR   3.0   /dev/sdb
[5:0:0:0]diskATA  SanDisk SDSSDXP1 1 /dev/sdc
[6:0:0:0]diskATA  OCZ-VECTOR   3.0   /dev/sdd
[7:0:0:0]diskATA  INTEL SSDSC2BF18 LSTi  /dev/sde
[12:0:0:0]   diskATA  OCZ-VERTEX3  2.25  /dev/sdf
[13:0:0:0]   diskATA  OCZ-VERTEX3  2.25  /dev/sdg
[17:0:0:0]   cd/dvd  TSSTcorp CDDVDW SH-224DB  SB01  /dev/sr0

Disk controllers on this system are:
* Intel 82801HR/HD/HH (ICH8R/DO/DH) 6 port. - AHCI mode
* JMicron JMB363 SATA/IDE ctornller - AHCI mode
* ASMedia ASM1062 SATA controller - AHCI mode

All these use the ahci kernel driver and disks show up as JBOD


It might be easier to close this bug and use "reportbug grub-pc" from
the relevant system, which should automatically attach some useful
information.

Ok, whatever helps. If you want to do that let me know and I'll repost 
the bugreport.


I will regardless to that for the other bugreports I plan to post 
perhaps tomorrow.


Thanks.

Bug#973132:

[Thomas Koch]

I've disabled the failing test in version 17.2-2

Bug#964955: The upstream has moved the modules to libexec

[KOLANICH]

The upstream has moved the modules to libexec. Now it is Debian turn. 
https://github.com/brailcom/speechd/pull/370

Bug#974878: libio-pty-perl: Patch Add-termios-data-structures-for-alpha.patch can be dropped

[John Paul Adrian Glaubitz]

Source: libio-pty-perl
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org

Hi!

The patch Add-termios-data-structures-for-alpha.patch that was introduced in
#82627 [1] in 2001 is no longer necessary and can safely be dropped, the package
builds fine without the patch - although the testsuite sometimes struggles
on the buildds which are SMP machines. That's unreleated to the patch
though.

Can you drop the patch Add-termios-data-structures-for-alpha.patch for the
next upload?

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=82627

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

Bug#974877: ftp.debian.org: attempt to upload rclone to stretch-security failed

[Brian May]

Package: ftp.debian.org
Severity: important

=== cut ===
golang-github-ncw-rclone-dev_1.35-1+deb8u1_all.deb: Built-Using refers to 
non-existing source package go-md2man (= 1.0.6+ds-1)

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
=== cut ===

As instructed I responded to the email:

=== cut ===
Brian May  (Tue. 16:52) (lts watch)
 Subject: Re: rclone_1.35-1+deb8u1_amd64.changes REJECTED
 To: Debian FTP Masters , 
d...@security.debian.org
 Date: Tue, 10 Nov 2020 16:52:11 +1100

 Hello,

 I have been told I need you to inject the required sources packages onto
 stretch-security for this to work. Can you please help?

 Thanks
=== cut ===

I have not received any response yet. Just in case the email got lost,
creating a formal bug report.

I imagine I will have similar packages uploading other packages that
need to be rebuilt thanks to several security issues that have been
fixed in golang-go.crypto.

Bug#974737: transition: botan

[Sebastian Ramacher]

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

On 2020-11-14 13:37:03 +0100, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> Last botan 2.x release (botan version 3 is a new upstream project) is
> in experimental. It would be good to have it for Bullseye. The only
> one reverse dependency is Thunderbird which builds fine with this
> version as well.

Please go ahead

Cheers

> 
> Thanks,
> Laszlo/GCS
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected

[Gerardo Esteban Malazdrewicz]

Package: wesnoth
Version: 1:1.14.13-1
Followup-For: Bug #970520
X-Debbugs-Cc: gera...@malazdrewicz.com.ar

Dear Maintainer,

Patch 99wolfssl-options attached adding

#include 

to affected files:

src/build_info.cpp
src/hash.cpp
src/preferences/credentials.cpp
src/server/user_handler.cpp

This causes a FTBFS, as MD5_DIGEST_SIZE is not defined.
Patch 99wolfssl-digest_size attached to fix that.
I chose to change the definitions to use WC_ (WolfCrypt) names,

#undef NO_OLD_WC_NAMES
#include 

may be an alternative to define MD5_DIGEST_SIZE.

This works for wesnoth-1.15 too, changing

src/server/user_handler.cpp

with

src/server/common/user_handler.cpp

Order of application:
99wolfssl-options
99wolfssl-digest_size

Regards,
 Gerardo



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

Kernel: Linux 5.9.0-2-amd64 (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wesnoth depends on:
pn  wesnoth-1.14   
pn  wesnoth-1.14-data  

wesnoth recommends no packages.

wesnoth suggests no packages.
--- a/src/build_info.cpp2020-11-15 11:28:28.184004892 -0400
+++ b/src/build_info.cpp2020-11-15 11:28:15.393204807 -0400
@@ -37,6 +37,7 @@
 #include 
 
 #ifndef __APPLE__
+#include 
 #include 
 #include 
 #endif
--- a/src/hash.cpp  2020-11-15 11:07:42.0 -0400
+++ b/src/hash.cpp  2020-11-15 11:46:12.599349726 -0400
@@ -24,6 +24,7 @@
 
 #ifndef __APPLE__
 
+#include 
 #include 
 #include 
 
--- a/src/preferences/credentials.cpp   2020-10-17 01:40:02.0 -0300
+++ b/src/preferences/credentials.cpp   2020-11-15 11:25:23.984187330 -0400
@@ -25,6 +25,7 @@
 #include 
 
 #ifndef __APPLE__
+#include 
 #include 
 #else
 #include 
--- a/src/server/user_handler.cpp   2020-10-17 01:40:02.0 -0300
+++ b/src/server/user_handler.cpp   2020-11-15 11:31:42.292524853 -0400
@@ -18,6 +18,7 @@
 #include "serialization/base64.hpp"
 
 #ifndef __APPLE__
+#include 
 #include 
 #else
 #include 
--- a/src/hash.cpp  2020-11-15 12:19:19.0 -0400
+++ b/src/hash.cpp  2020-11-15 12:20:20.604391108 -0400
@@ -28,8 +28,8 @@
 #include 
 #include 
 
-static_assert(utils::md5::DIGEST_SIZE == MD5_DIGEST_LENGTH, "Constants 
mismatch");
-static_assert(utils::sha1::DIGEST_SIZE == SHA_DIGEST_LENGTH, "Constants 
mismatch");
+static_assert(utils::md5::DIGEST_SIZE == WC_MD5_DIGEST_SIZE, "Constants 
mismatch");
+static_assert(utils::sha1::DIGEST_SIZE == WC_SHA_DIGEST_SIZE, "Constants 
mismatch");
 
 #else
 

Bug#954433: radvd: PIDFile in /lib/systemd/system/radvd.service must be moved from /var/run/ to /run/

[Geert Stappers]

Control: tags + confirmed  pending

On Sat, Mar 21, 2020 at 03:16:07PM +, Michael Berg wrote:
> Package: radvd
> Version: 1:2.17-2+b1
> 
> As part of the migration away from /var/run/ to /run/, systemd produces
> log events containing the following. These log events are generated
> every 5 minutes (cluttering the logs and consuming log space).
> 
> "/lib/systemd/system/radvd.service:13: PIDFile= references a path below 
> legacy directory /var/run/, updating /var/run/radvd.pid → /run/radvd.pid; 
> please update the unit file accordingly."
> 
> Attached is a patch for /lib/systemd/system/radvd.service that moves the
> PIDFile from /var/run/radvd.pid to /run/radvd.pid
> 
> 
> --- radvd.service.old 2020-03-21 14:46:14.507449211 +
> +++ radvd.service.new 2020-03-21 14:47:30.668715976 +
> @@ -13,7 +13,7 @@
>  ExecStart=/usr/sbin/radvd --logmethod stderr_clean
>  ExecReload=/usr/sbin/radvd --logmethod stderr_clean --configtest
>  ExecReload=/bin/kill -HUP $MAINPID
> -PIDFile=/var/run/radvd.pid
> +PIDFile=/run/radvd.pid
>  
>  # Set the CPU scheduling policy to idle which is for running very low 
> priority background jobs
>  CPUSchedulingPolicy=idle


--- a/configure.ac
+++ b/configure.ac
@@ -117,9 +117,9 @@ AC_MSG_RESULT($PATH_RADVD_LOG)
 dnl Check where to put the pidfile
 AC_MSG_CHECKING(where to put pidfile)
 AC_ARG_WITH(pidfile,
-[  --with-pidfile  Path to the radvd pidfile [/var/run/radvd.pid]],
+[  --with-pidfile  Path to the radvd pidfile [/run/radvd.pid]],
PATH_RADVD_PID=$withval,
-   PATH_RADVD_PID=/var/run/radvd.pid)
+   PATH_RADVD_PID=/run/radvd.pid)
 AC_MSG_RESULT($PATH_RADVD_PID)
 
 dnl Check where to put the configfile


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#974875: src:gcc-9-cross: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: gcc-9-cross
Version: 22
Severity: serious
Control: close -1 23
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:gcc-9-cross
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=gcc-9-cross




signature.asc
Description: OpenPGP digital signature

Bug#974874: src:geary: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: geary
Version: 3.36.2-1
Severity: serious
Control: close -1 3.38.0.1-3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 970933

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:geary 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=geary




signature.asc
Description: OpenPGP digital signature

Bug#974873: postgresql-rum: autopkgtest failure

[Sebastian Ramacher]

Source: postgresql-rum
Version: 1.3.7-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

postgresql-rum is currently unable to migrate due to autopkgtest
regressions on arm64 and ppc64el:
| --- Test multicolumn index
| -RESET enable_indexscan;
| -RESET enable_indexonlyscan;
| -RESET enable_bitmapscan;
| -SET enable_seqscan = off;
| -DROP INDEX tstsh_idx;
| -CREATE INDEX tstsh_id_idx ON tsts USING rum (t rum_tsvector_addon_ops, id, d)
| - WITH (attach = 'd', to = 't');
| -EXPLAIN (costs off)
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND id = 1::int ORDER BY d <=> 
'2016-05-16 14:21:25' LIMIT 5;
| -QUERY PLAN   
  
| 

| - Limit
| -   ->  Index Scan using tstsh_id_idx on tsts
| - Index Cond: ((t @@ '''wr'' & ''qh'''::tsquery) AND (id = 1))
| - Order By: (d <=> 'Mon May 16 14:21:25 2016'::timestamp without time 
zone)
| -(4 rows)
| -
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND id = 1::int ORDER BY d <=> 
'2016-05-16 14:21:25' LIMIT 5;
| -ERROR:  doesn't support order by over pass-by-reference column
| -EXPLAIN (costs off)
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND id = 355::int ORDER BY d <=> 
'2016-05-16 14:21:25' LIMIT 5;
| -QUERY PLAN   
  
| 

| - Limit
| -   ->  Index Scan using tstsh_id_idx on tsts
| - Index Cond: ((t @@ '''wr'' & ''qh'''::tsquery) AND (id = 355))
| - Order By: (d <=> 'Mon May 16 14:21:25 2016'::timestamp without time 
zone)
| -(4 rows)
| -
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND id = 355::int ORDER BY d <=> 
'2016-05-16 14:21:25' LIMIT 5;
| -ERROR:  doesn't support order by over pass-by-reference column
| -EXPLAIN (costs off)
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND d = '2016-05-11 
11:21:22.326724'::timestamp ORDER BY d <=> '2016-05-16 14:21:25' LIMIT 5;
| -QUERY PLAN   
 
| 
---
| - Limit
| -   ->  Index Scan using tstsh_id_idx on tsts
| - Index Cond: ((t @@ '''wr'' & ''qh'''::tsquery) AND (d = 'Wed May 11 
11:21:22.326724 2016'::timestamp without time zone))
| - Order By: (d <=> 'Mon May 16 14:21:25 2016'::timestamp without time 
zone)
| -(4 rows)
| -
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND d = '2016-05-11 
11:21:22.326724'::timestamp ORDER BY d <=> '2016-05-16 14:21:25' LIMIT 5;
| -ERROR:  doesn't support order by over pass-by-reference column
| -EXPLAIN (costs off)
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND d = '2000-05-01'::timestamp 
ORDER BY d <=> '2016-05-16 14:21:25' LIMIT 5;
| -QUERY PLAN   
  
| 

| - Limit
| -   ->  Index Scan using tstsh_id_idx on tsts
| - Index Cond: ((t @@ '''wr'' & ''qh'''::tsquery) AND (d = 'Mon May 01 
00:00:00 2000'::timestamp without time zone))
| - Order By: (d <=> 'Mon May 16 14:21:25 2016'::timestamp without time 
zone)
| -(4 rows)
| -
| -SELECT id, d FROM tsts WHERE t @@ 'wr' AND d = '2000-05-01'::timestamp 
ORDER BY d <=> '2016-05-16 14:21:25' LIMIT 5;
| -ERROR:  doesn't support order by over pass-by-reference column
| +FATAL:  failed to load summary 
"/usr/lib/postgresql/13/lib/bitcode/rum.index.bc": Invalid summary version 9. 
Version should be in the range [1-8].
| +server closed the connection unexpectedly
| + This probably means the server terminated abnormally
| + before or while processing the request.
| +connection to server was lost

https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-rum/8183353/log.gz

And also on i386 and armhf:
| -EXPLAIN (costs off)
| -SELECT id FROM test_int8_h_a WHERE  t @@ 'wr' AND id >= 400::int8 ORDER 
BY id;
| -  QUERY PLAN 
  
| 

| - Sort
| -   Sort Key: id
| -   ->  Seq Scan on test_int8_h_a
| - Filter: ((t @@ '''wr'' & ''qh'''::tsquery) AND (id >= 
'400'::bigint))
| -(4 rows)
| -
| -SELECT id FROM test_int8_h_a WHERE  t @@ 'wr' AND id >= 400::int8 ORDER 
BY id;
| - id  
| --
| - 406
| - 415
| - 428
| - 457
| - 458
| - 484
| - 496
| -(7 rows)
| -
| -CREATE TABLE test_int8_id_t AS SELECT id::int8, t FROM tsts;
| -CREATE INDEX test_int8_id_t_idx ON test_int8_o USING rum
| - (t rum_tsvector_ops, id);
| -EXPLAIN (costs off)
| -SELECT id FROM test_int8_h_a WHERE  t @@ 

Bug#974872: src:splint: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: splint
Version: 1:3.1.2+dfsg-1
Severity: serious
Control: close -1 1:3.1.2+dfsg-2
X-Debbugs-CC: la...@debian.org
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:splint 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.

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#974870: libgdk-pixbuf2.0-dev: Plans for Xlib API deprecation

[Eduard Bloch]

Package: libgdk-pixbuf2.0-dev
Version: 2.40.0+dfsg-5
Severity: minor

Dear Maintainer,

it looks like upstream support for Xlib API adapters is officially
declared deprecated now. For details, see
https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib . Since this affects
some application packages in Debian, please prepare documentation of
this issue, maybe there should be even a warning of some kind printed
through pkg-config or GCC warnings (although this is bad, of course,
would break -Werror using packages).

Best regards,
Eduard.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgdk-pixbuf2.0-dev depends on:
ii  gir1.2-gdkpixbuf-2.0  2.40.0+dfsg-5
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libgdk-pixbuf2.0-bin  2.40.0+dfsg-5
ii  libglib2.0-dev2.66.2-1
ii  libpng-dev1.6.37-3
ii  libx11-dev2:1.6.12-1
ii  shared-mime-info  2.0-1

libgdk-pixbuf2.0-dev recommends no packages.

libgdk-pixbuf2.0-dev suggests no packages.

-- no debconf information

Bug#974871: src:xserver-xorg-video-amdgpu: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: xserver-xorg-video-amdgpu
Version: 19.1.0-1
Severity: serious
Control: close -1 19.1.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:xserver-xorg-video-amdgpu 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=xserver-xorg-video-amdgpu




signature.asc
Description: OpenPGP digital signature

Bug#948575: About removing overrides with deprecated "extra" priority

[s3v]

Dear Maintainers,

please find attached a simple Python script to parse an override .gz file [1]
and create a text file containing only lines with 'extra' priority replaced by
'optional' one.
Example of usage:

  python3 overrides.py --filein override.sid.main.gz --fileout override.sid.main
 
If I understand correctly the code [2], this file needs to be passed to
'|dak control-overrides -C file'| for changing the priority for specified 
packages.
I'm not entirely sure about this procedure (I'm not sure at all, sincerely),
if I'm wrong, my apologizes for the noise. I've tried :(

Kind Regards

[1] http://ftp.debian.org/debian/indices/
[2] https://salsa.debian.org/ftp-team/dak/-/blob/master/dak/control_overrides.py



overrides.py.xz
Description: application/xz

Bug#974869: pgpointcloud: autopkgtest failure on armhf

[Sebastian Ramacher]

Source: pgpointcloud
Version: 1.2.1-5
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

pgpointcloud is currently unable to migrate to testing due to an
autopkgtest failure on armhf:
| *** pgsql/regression.diffs ***
| diff -U3 
/tmp/autopkgtest-lxc.eufbisbr/downtmp/build.sZ5/src/pgsql/expected/pointcloud.out
 
/tmp/autopkgtest-lxc.eufbisbr/downtmp/build.sZ5/src/pgsql/results/pointcloud.out
| --- 
/tmp/autopkgtest-lxc.eufbisbr/downtmp/build.sZ5/src/pgsql/expected/pointcloud.out
 2020-01-07 20:42:28.0 +
| +++ 
/tmp/autopkgtest-lxc.eufbisbr/downtmp/build.sZ5/src/pgsql/results/pointcloud.out
  2020-11-13 20:46:20.689453152 +
| @@ -535,176 +535,7 @@
|('dimensional','auto')
|  ) dimcompr(compr,sc)
|  ORDER BY compr,sc,v;
| - test  | v  |compr|   sc| ok 
| ++-+-+
| - compr | -7 | dimensional | auto| t
| - compr | -6 | dimensional | auto| t
| - compr | -5 | dimensional | auto| t
| - compr | -4 | dimensional | auto| t
| - compr | -3 | dimensional | auto| t
| - compr | -2 | dimensional | auto| t
| - compr | -1 | dimensional | auto| t
| - compr |  0 | dimensional | auto| t
| - compr |  1 | dimensional | auto| t
| - compr |  2 | dimensional | auto| t
| - compr |  3 | dimensional | auto| t
| - compr |  4 | dimensional | auto| t
| - compr |  5 | dimensional | auto| t
| - compr |  6 | dimensional | auto| t
| - compr |  7 | dimensional | auto| t
| - compr | -7 | dimensional | rle | t
| - compr | -6 | dimensional | rle | t
| - compr | -5 | dimensional | rle | t
| - compr | -4 | dimensional | rle | t
| - compr | -3 | dimensional | rle | t
| - compr | -2 | dimensional | rle | t
| - compr | -1 | dimensional | rle | t
| - compr |  0 | dimensional | rle | t
| - compr |  1 | dimensional | rle | t
| - compr |  2 | dimensional | rle | t
| - compr |  3 | dimensional | rle | t
| - compr |  4 | dimensional | rle | t
| - compr |  5 | dimensional | rle | t
| - compr |  6 | dimensional | rle | t
| - compr |  7 | dimensional | rle | t
| - compr | -7 | dimensional | sigbits | t
| - compr | -6 | dimensional | sigbits | t
| - compr | -5 | dimensional | sigbits | t
| - compr | -4 | dimensional | sigbits | t
| - compr | -3 | dimensional | sigbits | t
| - compr | -2 | dimensional | sigbits | t
| - compr | -1 | dimensional | sigbits | t
| - compr |  0 | dimensional | sigbits | t
| - compr |  1 | dimensional | sigbits | t
| - compr |  2 | dimensional | sigbits | t
| - compr |  3 | dimensional | sigbits | t
| - compr |  4 | dimensional | sigbits | t
| - compr |  5 | dimensional | sigbits | t
| - compr |  6 | dimensional | sigbits | t
| - compr |  7 | dimensional | sigbits | t
| - compr | -7 | dimensional | zlib| t
| - compr | -6 | dimensional | zlib| t
| - compr | -5 | dimensional | zlib| t
| - compr | -4 | dimensional | zlib| t
| - compr | -3 | dimensional | zlib| t
| - compr | -2 | dimensional | zlib| t
| - compr | -1 | dimensional | zlib| t
| - compr |  0 | dimensional | zlib| t
| - compr |  1 | dimensional | zlib| t
| - compr |  2 | dimensional | zlib| t
| - compr |  3 | dimensional | zlib| t
| - compr |  4 | dimensional | zlib| t
| - compr |  5 | dimensional | zlib| t
| - compr |  6 | dimensional | zlib| t
| - compr |  7 | dimensional | zlib| t
| -(60 rows)
| -
| -SELECT 
PC_Summary(PC_Compress(PC_Patch(PC_MakePoint(10,ARRAY[1,1,1,1,1,1,1])),
| -  'dimensional'))::json->'compr';
| -   ?column?
| 
| - "dimensional"
| -(1 row)
| -
| --- https://github.com/pgpointcloud/pointcloud/issues/79
| -SELECT '#79' issue,
| -  PC_PatchMin(p,'x') x_min, PC_PatchMax(p,'x') x_max,
| -  PC_PatchMin(p,'y') y_min, PC_PatchMax(p,'y') y_max,
| -  PC_PatchMin(p,'z') z_min, PC_PatchMax(p,'z') z_max
| -FROM ( SELECT
| -  PC_FilterEquals(
| -PC_Patch( PC_MakePoint(20,ARRAY[-1,0,1]) ),
| -'y',0) p
| -) foo;
| - issue | x_min | x_max | y_min | y_max | z_min | z_max 
| +---+---+---+---+---+---
| - #79   |-1 |-1 | 0 | 0 | 1 | 1
| -(1 row)
| -
| --- https://github.com/pgpointcloud/pointcloud/issues/78
| -SELECT '#78' issue,
| -  PC_PatchMin(p,'x') x_min, PC_PatchMax(p,'x') x_max,
| -  PC_PatchMin(p,'y') y_min, PC_PatchMax(p,'y') y_max,
| -  PC_PatchMin(p,'z') z_min, PC_PatchMax(p,'z') z_max,
| -  PC_PatchMin(p,'intensity') i_min, PC_PatchMax(p,'intensity') i_max
| -FROM ( SELECT
| -  PC_FilterEquals(
| -PC_Patch( PC_MakePoint(3,ARRAY[-1,0,4862413,1]) ),
| -'y',0) p
| -) foo;
| - issue | x_min | x_max | y_min | y_max |  z_min  |  z_max  | i_min | i_max 
| +---+---+---+---+-+-+---+---
| - #78   |-1 |-1 | 0 | 0 | 4862413 | 4862413 | 1 | 1
| -(1 row)
| -
| --- test for PC_BoundingDiagonalAsBinary
| -SELECT PC_BoundingDiagonalAsBinary(
| - PC_Patch(ARRAY[
| - 

Bug#957074: cdrkit: ftbfs with GCC-10

[Joerg Jaspert]

On 15953 March 1977, John Paul Adrian Glaubitz wrote:
I agree. I'm trying to help Thomas to add HFS support to 
libburnia/xorriso

so we can finally get rid of cdrkit but I would like to keep cdrkit in
Debian until that has happened.
I'll file an O:/ITA: bug.


Go go go.

--
bye, Joerg

Bug#974868: samba: can't serve size-limited Time Machine shares on i386

[Reid Priedhorsky]

Package: samba
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: important
Tags: patch

Hi,

With the following line on a share in smb.conf:

  fruit:time machine max size = 640G

authentication fails on my Mac when attempting to mount the share. This
appears in the log:

  fruit_tmsize_do_dirent: tmsize overflow

I'm pretty sure the problem is an instance of this upstream bug:

  https://bugzilla.samba.org/show_bug.cgi?id=13622

which was fixed with this patch:

  https://bugzilla.samba.org/attachment.cgi?id=15850

The share mounts and Time Machine is happy with it if I remove the
configuration line noted.

I believe the bug is fixed in the testing and unstable versions of the
package, but I haven't verified this. The testing package has unmet
dependencies on stable and there seems to be no backport. I am running
multi-arch but the amd64 package had dependency problems I couldn't figure
out. So the request is to apply the (quite short) patch to the stable version.

I tagged it important because serving Time Machine shares is a common use of
Samba and without this option, I can't put the share on a common filesystem
without the backups growing unbounded. In my case, I have one Time Machine
backup that's excessively large already and I want to keep it from getting
worse.

Please let me know what additional information I can provide to help.

Thanks for your hard work on Debian! This particular box was originally
installed around 1998 and upgraded smoothly since then, which speaks very well
for the project IMO.

Reid


-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf present, and attached

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

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

Versions of packages samba depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libbsd0   0.9.1-2
ii  libc6 2.28-10
ii  libldb1   2:1.5.1+really1.4.6-3
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpopt0  1.16-12
ii  libpython2.7  2.7.16-2+deb10u1
ii  libtalloc22.1.14-2
ii  libtdb1   1.3.16-2+b1
ii  libtevent00.9.37-1
ii  lsb-base  10.2019051400
ii  procps2:3.3.15-2
ii  python2.7.16-1
ii  python-dnspython  1.16.0-1
ii  python-samba  2:4.9.5+dfsg-5+deb10u1
ii  python2.7 2.7.16-2+deb10u1
ii  samba-common  2:4.9.5+dfsg-5+deb10u1
ii  samba-common-bin  2:4.9.5+dfsg-5+deb10u1
ii  samba-libs2:4.9.5+dfsg-5+deb10u1
ii  tdb-tools 1.3.16-2+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-4
ii  logrotate   3.14.0-4
ii  samba-dsdb-modules  2:4.9.5+dfsg-5+deb10u1
ii  samba-vfs-modules   2:4.9.5+dfsg-5+deb10u1

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which 
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic 
# errors. 

#=== Global Settings ===

[global]

# Time Machine stuff
  min protocol = SMB2
  fruit:time machine = yes
  fruit:aapl = yes
  fruit:delete_empty_adfiles = yes

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = JESSNET

 Networking 

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
;   interfaces = 127.0.0.0/8 eth0

# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself.  However, this
# option cannot handle 

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2020-11-15 20:59:18 [+0100], Paul Gevers wrote:
> Hi Sebastian,
Hi Paul,

> I don't fully understand what you say here. We *do* run autopkgtests in
> stable to check for issues. 

Yes, but the package does not use it in stable.

Sebastian

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-11-15 20:43:49)
> I re-tried with the modified guestfish command, the modified
> extlinux.conf file and requesting an 8 GiB size.
> 
> Unfortunately, the new test results in the following errors:
> 
> 
> [...]
> Setting up initramfs-tools-core (0.139) ...
> Setting up initramfs-tools (0.139) ...
> update-initramfs: deferring update (trigger activated)
> Setting up linux-image-5.9.0-2-amd64 (5.9.6-1) ...
> I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.9.0-2-amd64
> I: /initrd.img.old is now a symlink to boot/initrd.img-5.9.0-2-amd64
> I: /vmlinuz is now a symlink to boot/vmlinuz-5.9.0-2-amd64
> I: /initrd.img is now a symlink to boot/initrd.img-5.9.0-2-amd64
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-5.9.0-2-amd64
> W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for module 
> r8169
> [...]
> find: ‘/var/tmp/mkinitramfs_KOh7yF/lib/modules/5.9.0-2-amd64/kernel’: No such 
> file or directory
> cp: cannot stat '/usr/lib/klibc/bin/*': No such file or directory
> cp: cannot stat '/lib/klibc-*.so': No such file or directory
> E: /usr/share/initramfs-tools/hooks/klibc-utils failed with return 1.
> update-initramfs: failed for /boot/initrd.img-5.9.0-2-amd64 with 1.
> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
> dpkg: error processing package linux-image-5.9.0-2-amd64 (--configure):
>  installed linux-image-5.9.0-2-amd64 package post-installation script 
> subprocess returned error exit status 1
> Setting up iptables (1.8.6-1) ...
> [...]
> dpkg: dependency problems prevent configuration of linux-image-amd64:
>  linux-image-amd64 depends on linux-image-5.9.0-2-amd64 (= 5.9.6-1); however:
>   Package linux-image-5.9.0-2-amd64 is not configured yet.
> 
> dpkg: error processing package linux-image-amd64 (--configure):
>  dependency problems - leaving unconfigured
> [...]
> Processing triggers for initramfs-tools (0.139) ...
> Errors were encountered while processing:
>  linux-image-5.9.0-2-amd64
>  linux-image-amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> E: run_chroot failed: E: env --unset=APT_CONFIG --unset=TMPDIR 
> /usr/sbin/chroot ${HOME}/Downloads/TEMP/mmdebstrap.HHRQ7rNuyL env 
> --unset=APT_CONFIG --unset=TMPDIR apt-get --yes install 
> -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false linux-image-amd64 adduser apt 
> apt-utils bsdmainutils cpio cron debconf debconf-i18n debian-archive-keyring 
> dmidecode e2fsprogs gcc-10-base gcc-9-base gpgv ifupdown init iproute2 
> iptables iputils-ping isc-dhcp-client isc-dhcp-common kmod less logrotate 
> mawk nano netbase whiptail libpam-modules libpam-modules-bin libpam-runtime 
> procps libreadline8 readline-common rsyslog sensible-utils passwd systemd 
> systemd-sysv udev tasksel-data tzdata fdisk mount vim-common vim-tiny failed
> W: listening on child socket failed: 
> I: removing tempdir ${HOME}/Downloads/TEMP/mmdebstrap.HHRQ7rNuyL...
> libguestfs: error: /usr/bin/supermin exited with error status 1.
> To see full error messages you may need to enable debugging.
> Do:
>   export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
> and run the command again.  For further information, read:
>   http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> You can also run 'libguestfs-test-tool' and post the *complete* output
> into a bug report or message to the libguestfs mailing list.
> 
> 
> 
> And the directory now includes the following files:
> 
> $ ls -altrF --si
> total 218k
> drwxrwx--- 3 $USER $USER 4.1k Nov 15 20:28 ../
> -rw-r--r-- 1 $USER $USER0 Nov 15 20:30 debian-unstable.tar
> -rw-rw 1 $USER $USER  125 Nov 15 20:30 extlinux.conf
> drwxr-xr-x 2 $USER $USER 4.1k Nov 15 20:30 .guestfs-1000/
> -rw-rw 1 $USER $USER 8.6G Nov 15 20:30 debian-unstable.img
> drwxrwx--- 3 $USER $USER 4.1k Nov 15 20:30 ./
> -rw-r- 1 $USER $USER 197k Nov 15 20:30 debian-unstable.qcow2
> 
> 
> Any idea why initramfs-tools hooks are failing?

Which mode was mmdebstrap run in? Maybe this is something similar to this
initramfs-tools bug that popped up with fakechroot:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944929

Can you share the whole script that you used for these results?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#974867: ITP: golang-github-minio-md5-simd -- Accelerate aggregated MD5 hashing performance up to 8x for AVX512 and 4x for AVX2. Useful for server applications that need to compute many MD5 sums in

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: Félix Sipma 

* Package name: golang-github-minio-md5-simd
  Version : 1.1.0-1
  Upstream Author : High Performance, Kubernetes Native Object Storage
* URL : https://github.com/minio/md5-simd
* License : Apache-2.0
  Programming Lang: Go
  Description : Accelerate aggregated MD5 hashing performance up to 8x for 
AVX512 and 4x for AVX2. Useful for server applications that need to compute 
many MD5 sums in parallel.

 md5-simd This is a SIMD accelerated MD5 package, allowing up to either 8
 (AVX2) or 16 (AVX512) independent MD5 sums to be calculated on a single
 CPU core.

This package is needed to update golang-github-minio-minio-go to v7, that is
needed to update restic.

-- 
Félix


signature.asc
Description: PGP signature

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Paul Gevers]

Hi Sebastian,

On 15-11-2020 11:29, Sebastian Andrzej Siewior wrote:
> The same error is also present in the stable version of swi-prolog.
> However, this is not the only failure in the test suite (it also
> complains about too small keys) and there is no debci for stable which
> would cause a regression so I don't think that it is worth to address
> this in stable.

I don't fully understand what you say here. We *do* run autopkgtests in
stable to check for issues. The results (if negative) show up here:
https://release.debian.org/proposed-updates/stable.html You can
currently see one REJECTED_PERMANENTLY there. So yes, if this breaks the
test (and only the test) that's valuable information.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#974865: Upload problem

[Emmanuel Bourg]

On 15/11/2020 20:26, Alejandro Sánchez wrote:

> Tomcat 9.0.31 has an upload bug 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202

Thank you for the information but there is need to forward the upstream
bugs to the Debian BTS. This will be fixed when the new version is uploaded.

Emmanuel Bourg

Bug#974676: debug-on-error

["Kamil Jońca"]

Seems that it is related to debug-on-error variable.
When it is set to non-nil - emacs exists with error.
When it is set to nil - emacs survives lost connection.
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Bug#974866: golang-github-xenolf-lego: please update to at least v3.4.0

[Félix Sipma]

Source: golang-github-xenolf-lego
Version: please update to at least v3.4.0
Severity: wishlist


It would help updating restic if golang-github-xenolf-lego was updated 
to (at least) v3.4.0. It is needed to be able to update 
golang-github-cenkalti-backoff to v4: golang-github-xenolf-lego is the 
only package that is failing to build with this version.

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

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

-- 
Félix


signature.asc
Description: PGP signature

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Wed, 11 Nov 2020 23:27:21 +0100 Johannes Schauer wrote:

> Hi Francesco,

Hello Johannes, thanks for the updated followup!

[...]
>So a better guestfish command is this one:
> 
> guestfish -N debian-unstable.img=disk:8G -- \
[...]
> Just to make sure, here is my
> extlinux.conf:
[...]
> Also, you reported that the guestfish call fails
[...]
> maybe your
> disk size is not large enough for your tarball and that's why it fails?

I re-tried with the modified guestfish command, the modified
extlinux.conf file and requesting an 8 GiB size.

Unfortunately, the new test results in the following errors:


[...]
Setting up initramfs-tools-core (0.139) ...
Setting up initramfs-tools (0.139) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-5.9.0-2-amd64 (5.9.6-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.9.0-2-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.9.0-2-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.9.0-2-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.9.0-2-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.9.0-2-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125b-2.fw for module 
r8169
[...]
find: ‘/var/tmp/mkinitramfs_KOh7yF/lib/modules/5.9.0-2-amd64/kernel’: No such 
file or directory
cp: cannot stat '/usr/lib/klibc/bin/*': No such file or directory
cp: cannot stat '/lib/klibc-*.so': No such file or directory
E: /usr/share/initramfs-tools/hooks/klibc-utils failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.9.0-2-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-5.9.0-2-amd64 (--configure):
 installed linux-image-5.9.0-2-amd64 package post-installation script 
subprocess returned error exit status 1
Setting up iptables (1.8.6-1) ...
[...]
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-5.9.0-2-amd64 (= 5.9.6-1); however:
  Package linux-image-5.9.0-2-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
[...]
Processing triggers for initramfs-tools (0.139) ...
Errors were encountered while processing:
 linux-image-5.9.0-2-amd64
 linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: run_chroot failed: E: env --unset=APT_CONFIG --unset=TMPDIR /usr/sbin/chroot 
${HOME}/Downloads/TEMP/mmdebstrap.HHRQ7rNuyL env --unset=APT_CONFIG 
--unset=TMPDIR apt-get --yes install -oAPT::Status-Fd=<$fd> 
-oDpkg::Use-Pty=false linux-image-amd64 adduser apt apt-utils bsdmainutils cpio 
cron debconf debconf-i18n debian-archive-keyring dmidecode e2fsprogs 
gcc-10-base gcc-9-base gpgv ifupdown init iproute2 iptables iputils-ping 
isc-dhcp-client isc-dhcp-common kmod less logrotate mawk nano netbase whiptail 
libpam-modules libpam-modules-bin libpam-runtime procps libreadline8 
readline-common rsyslog sensible-utils passwd systemd systemd-sysv udev 
tasksel-data tzdata fdisk mount vim-common vim-tiny failed
W: listening on child socket failed: 
I: removing tempdir ${HOME}/Downloads/TEMP/mmdebstrap.HHRQ7rNuyL...
libguestfs: error: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
  export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again.  For further information, read:
  http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
You can also run 'libguestfs-test-tool' and post the *complete* output
into a bug report or message to the libguestfs mailing list.



And the directory now includes the following files:

$ ls -altrF --si
total 218k
drwxrwx--- 3 $USER $USER 4.1k Nov 15 20:28 ../
-rw-r--r-- 1 $USER $USER0 Nov 15 20:30 debian-unstable.tar
-rw-rw 1 $USER $USER  125 Nov 15 20:30 extlinux.conf
drwxr-xr-x 2 $USER $USER 4.1k Nov 15 20:30 .guestfs-1000/
-rw-rw 1 $USER $USER 8.6G Nov 15 20:30 debian-unstable.img
drwxrwx--- 3 $USER $USER 4.1k Nov 15 20:30 ./
-rw-r- 1 $USER $USER 197k Nov 15 20:30 debian-unstable.qcow2


Any idea why initramfs-tools hooks are failing?


-- 
 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


pgp1jXakrZd_d.pgp
Description: PGP signature

Bug#973326: double-conversion: Misbuild with -O3: DoubleToStringConverter::DoubleToStringConverter() constructor dropped from exported symbols

[Christoph Berg]

Control: severity -1 important

Re: Steve Langasek
> The latest upload of double-conversion is failing to build from source on
> ppc64el in Ubuntu, because Ubuntu builds ppc64el with -O3 by default instead
> of -O2, and this additional optimization level somehow causes a public
> constructor to be lost from the exported symbols:
> 
> [...]
> - 
> (c++)"double_conversion::DoubleToStringConverter::DoubleToStringConverter(int,
>  char const*, char const*, char, int, int, int, int)@Base" 3.1.5
> +#MISSING: 3.1.5-6# 
> (c++)"double_conversion::DoubleToStringConverter::DoubleToSt
> ringConverter(int, char const*, char const*, char, int, int, int, int)@Base" 
> 3.1
> .5

Hi,

the same diff is showing up in the kfreebsd-* build logs now. The
build there is done with -O2 though, so the provided patch is likely
not enough for fixing this.

I'm raising the severity to important because the package built
successfully there in the past, and this failure is now holding back
cmake, which in turn holds back a lot of other packages from being
built there.

Christoph

Bug#974865: Upload problem

[Alejandro Sánchez]

Package: tomcat9
Version: 9.0.31-1~deb10u2
Severity: important
Tags: upstream

Tomcat 9.0.31 has an upload bug 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64202

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

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

Versions of packages tomcat9 depends on:
ii  lsb-base10.2019051400
ii  systemd 241-7~deb10u4
ii  tomcat9-common  9.0.31-1~deb10u2
ii  ucf 3.0038+nmu1

Versions of packages tomcat9 recommends:
ii  libtcnative-1  1.2.21-1

Versions of packages tomcat9 suggests:
pn  tomcat9-admin 
pn  tomcat9-docs  
pn  tomcat9-examples  
pn  tomcat9-user  

-- no debconf information

Bug#974845: chrony: Add leapsecond info

[Kurt Roeckx]

On Sun, Nov 15, 2020 at 07:25:59PM +0100, Vincent Blut wrote:
> Hi Kurt,
> 
> On 2020-11-15T14:29+0100, Kurt Roeckx wrote:
> > Package: chrony
> > Version: 4.0-2
> > Severity: wishlist
> > 
> > Hi,
> > 
> > Could you please add the following line to the default chrony.conf
> > file:
> > leapsectz right/UTC
> 
> Funnily enough, I am working to make the fragmentation of the chronyd
> configuration easier. To make sure it works as it should, I wrote an
> autopkgtest [1] that adds (you guessed it!) "leapsectz right/UTC" to the
> chronyd configuration using a fragment in /etc/chrony/conf.d.
> 
> As to set "leapsectz right/UTC" by default, it's something I've been
> planning to do for some time, but I always step back knowing that this will
> cause problems for users of leap smearing servers [2] and those who

By default, we use servers from the pool. As far as I know,
servers from the pool should not be smearing. The default of
chrony itself is also to use a step (leapsecmode system).

> don't update their systems and find themselves with an obsolete version of
> tzdata (nothing I can do here though).

An obsolete version of tzdata is actually not a problem. From the
manpage:
| The specified timezone is not used as an exclusive source of
| information about leap seconds. If a majority of time sources
| announce on the last day of June or December that a leap second
| should be inserted or deleted, it will be accepted even if it is
| not included in the timezone.

Having the settings just makes sure that you get leap second
announcement and hopefully propagate it to your clients.

> [1] 
> https://salsa.debian.org/debian/chrony/-/commit/3124fb4c8ec547b5a1e606ccb8d02906166960e3
> [2] Notably the Debian Cloud Team that configured chrony (used by default)
> to use the Amazon Time Sync Service for EC2 and the internal NTP server
> provided by Google (metadata.google.internal) for the GCE images. Both serve
> leap-smeared time.

So they already changed the default to use different servers. If
those servers are smearing servers, it just means they need to
change something else in their config file.


Kurt

Bug#957074: cdrkit: ftbfs with GCC-10

[John Paul Adrian Glaubitz]

Hi Steve!

On 11/15/20 7:58 PM, Steve McIntyre wrote:
>> Is anyone taking care of this package at the moment?
>>
>> I'm happy to adopt cdrkit for the time being until libisofs from libburnia
>> has gained support for creating legacy HFS filesystems which is required
>> for older Macintosh systems.
>>
>> For this reason, I'm currently using genisoimage when creating Debian CD
>> images for m68k.
> 
> ACK. If you're happy to take ove cdrkit for now, I'd be very happy.  I
> don't have the time to care for it any more. Thomas has been doing a
> great job with xorriso and friends, so it would be lovely to see us no
> longer need to keep the old code around any more...

I agree. I'm trying to help Thomas to add HFS support to libburnia/xorriso
so we can finally get rid of cdrkit but I would like to keep cdrkit in
Debian until that has happened.

I'll file an O:/ITA: bug.

Adrian

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

Bug#957074: cdrkit: ftbfs with GCC-10

[Steve McIntyre]

Hey Adrian,

On Sat, Nov 14, 2020 at 12:13:02PM +0100, John Paul Adrian Glaubitz wrote:
>
>> Fedora has a patch for gcc-10
>> 
>> https://src.fedoraproject.org/rpms/cdrkit/blob/master/f/cdrkit-1.1.11-gcc10.patch
>
>Is anyone taking care of this package at the moment?
>
>I'm happy to adopt cdrkit for the time being until libisofs from libburnia
>has gained support for creating legacy HFS filesystems which is required
>for older Macintosh systems.
>
>For this reason, I'm currently using genisoimage when creating Debian CD
>images for m68k.

ACK. If you're happy to take ove cdrkit for now, I'd be very happy.  I
don't have the time to care for it any more. Thomas has been doing a
great job with xorriso and friends, so it would be lovely to see us no
longer need to keep the old code around any more...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Bug#974863: vboot-utils: uses uname to determine architecture

[Vagrant Cascadian]

Source: vboot-utils
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When building for i386 and running an amd64 kernel, the Makefile uses
"uname -m" to determine the architecture, but this introduces variations
depending on the kernel used to perform the build:

  44277 ./host/arch/x86/lib/crossystem_arch.c:161   44277   
./host/arch/x86_64/lib/crossystem_arch.c:161

See also:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/diffoscope-results/vboot-utils.html
  
https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html

While this is often worked around in chroots by running with a "linux32"
personality, using the running kernel is not the correct way to
determine the architecture.

The attached patch fixes this by passing the debian architecture via
debian/rules, and patching the Makefile to treat i386 as x86.

An alternate fix might be to determine the architecture from the
compiler or other userspace utility that is independent from the kernel,
which might be more appropriate to submit upstream.

Thanks for maintaining vboot-utils!

live well,
  vagrant
From 1ab1bb1754501761cbe89196f55a7c557ab6c937 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 15 Nov 2020 18:32:37 +
Subject: [PATCH] debian/rules: Pass the Debian architecture as _machname from
 debian rules, and patch the Makefile to treat i386 as x86.

This is needed to ensure reproducible builds when the running kernel
and Debian architecture do not match, as uname may be misleading:

  https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html
---
 debian/patches/series|  1 +
 debian/patches/treat-i386-as-x86 | 14 ++
 debian/rules |  1 +
 3 files changed, 16 insertions(+)
 create mode 100644 debian/patches/treat-i386-as-x86

diff --git a/debian/patches/series b/debian/patches/series
index c24a3d3..a5035b4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 dont-build-with-werror.patch
 add-missing-flags-pie.patch
 do-not-embed-user-and-time-in-version.patch
+treat-i386-as-x86
diff --git a/debian/patches/treat-i386-as-x86 b/debian/patches/treat-i386-as-x86
new file mode 100644
index 000..84c5c7f
--- /dev/null
+++ b/debian/patches/treat-i386-as-x86
@@ -0,0 +1,14 @@
+Index: vboot-utils/Makefile
+===
+--- vboot-utils.orig/Makefile
 vboot-utils/Makefile
+@@ -93,6 +93,9 @@ endif
+ ifneq (,$(findstring i686,${_machname}))
+ 	override _machname := x86
+ endif
++ifneq (,$(findstring i386,${_machname}))
++	override _machname := x86
++endif
+ HOST_ARCH ?= ${_machname}
+ 
+ # ARCH and/or FIRMWARE_ARCH are defined by the Chromium OS ebuild.
diff --git a/debian/rules b/debian/rules
index dce9471..0e92bd6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export CC = clang-10
+export _machname = $(DEB_HOST_ARCH)
 
 override_dh_auto_build:
 	dh_auto_build -- V=1
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#972246: numba, python3.9, dolfinx

[Drew Parsons]

On 2020-11-16 01:27, Adrian Bunk wrote:

On Mon, Nov 16, 2020 at 12:54:53AM +0800, Drew Parsons wrote:

On 2020-11-16 00:07, Adrian Bunk wrote:
>
> It seems numba might get fixed in time for bullseye:
> https://github.com/numba/numba/issues/6345#issuecomment-721738251

Yes, they're already sitting on rc3.  We might as well pull that in, 
in case

there's unexpected delay with final release.


If I understand it correctly the rc is for 0.52.0,
and 3.9 support will be in 0.52.1



Oh yeah, looks like you're right.  I had assumed they were converging to 
the py3.9 version since the timing nearly lines up.  They must be 
thinking to release 0.52.1 very soon after 0.52.0, if they're aiming 
0.52.1 before mid-December.


Drew

Bug#965557: gmp: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Niels Thykier]

Control: reopen -1

Steven Robbins:
> On Mon, 20 Jul 2020 19:35:26 + Niels Thykier  
> wrote:
>> Source: gmp
>> Version: 2:6.2.0+dfsg-6
>> Severity: normal
>> Usertags: compat-5-6-removal
>>
>> Hi,
>>
>> The package gmp uses debhelper with a compat level of 5 or 6,
> 
> My sources show compat level 9.  How did you determine it was 5 or 6?
> 
> -Steve
> 

The debian/rules is using "DH_COMPAT=6" to redefine the compat level in
debian/rules:

"""
# User lower compatibility to avoid installing [...]
DH_COMPAT=6 dh_installchangelogs
"""

https://salsa.debian.org/science-team/gmp/-/blob/master/debian/rules#L142

That bit will fail once debhelper stops supporting compat 6.

~Niels

Bug#926945: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI

[Simon McVittie]

Thanks for proposing these patches, but when considering the various
patches that have been proposed for architecture support, I don't think
we can do them in a maintainable way while autopkgtest-build-qemu is
still a shell script. We have the following bugs with patches, all of
which propose switching boot from BIOS to EFI for all architectures,
and some of which propose switching the partition table from DOS to GPT
for all architectures:

* #973522 (i386 UEFI)

* #973038 (arm64 UEFI)

* #973663 (armel UEFI)
  - needs support for having a secondary architecture

* #926945 (ppc64el UEFI)
  - needs a small PReP partition for the firmware
  - needs a special flag on that partition, with a vmdb2 patch that hasn't
been reviewed or merged yet

All of these seem like a useful proof-of-concept if the only thing you
need is the single architecture you are working on at the time, but none
of them seems like something we can merge, partly because they all touch
the same parts of the code and partly because they will cause important
regressions on architectures that already work.

In particular, qemu on x86 defaults to providing BIOS rather than EFI
firmware, which means that if we applied any of these, the ability to
build and boot x86 qemu images would regress. Features that already
work need to continue to work, and that's more important than having
new features.

I think there is also a danger that if we try to add too many things to
autopkgtest-build-qemu, it will end up with the same problems that led
to vmdebootstrap version 1 being discontinued - too many special cases,
too many code paths, and not possible to test for regressions in a
reasonable time - so we should be a bit careful about what we're willing
to merge into that script.

I think the best route for all these architectures goes something like
this:

* Make sure that if you have prepared an image by hand,
  autopkgtest-virt-qemu can boot it. This might mean adding new code
  paths for the --efi and/or --secure-boot options, or even turning on
  EFI by default for certain architectures. It is going to be quicker to
  review and test these if you can provide patches against the autopkgtest
  source code ( or
  `apt-get source autopkgtest`) instead of the installed files in /usr,
  and especially if you can send patches as a merge request at
  .

* Make sure that there is a way to get a bootable Debian and/or Ubuntu
  cloud image for that architecture: as discussed on #944386, I'd
  like to use cloud images as the primary way to get a bootable image
  for new architectures, because those are something that we're going
  to want for new architectures *anyway*. Have a way to convert these
  cloud images into something that autopkgtest-virt-qemu can use. At the
  moment autopkgtest-buildvm-ubuntu-cloud only works for Ubuntu images,
  but I want to make that or a similar script work similarly for Debian
  cloud images as discussed on #944386.

* An autopkgtest maintainer (most likely to be me) should convert
  autopkgtest-build-qemu from a shell script into a Python script,
  so that instead of using simple string substitutions, it can build
  the vmdb2 recipe using python3-yaml, preserving its structure.

* After autopkgtest-build-qemu is a Python script, we can consider giving
  it an option that creates and populates the EFI system partition. That
  option can perhaps be on by default for ARM and ppc64el, but it should
  not be the default for x86, unless we can build x86 images that are
  bootable in BIOS *and* UEFI mode.

* As we get new architecture support in OVMF and vmdb2, we can consider
  setting up those architectures in autopkgtest-build-qemu.

smcv

Bug#974845: chrony: Add leapsecond info

[Vincent Blut]

Hi Kurt,

On 2020-11-15T14:29+0100, Kurt Roeckx wrote:

Package: chrony
Version: 4.0-2
Severity: wishlist

Hi,

Could you please add the following line to the default chrony.conf
file:
leapsectz right/UTC


Funnily enough, I am working to make the fragmentation of the chronyd 
configuration easier. To make sure it works as it should, I wrote an 
autopkgtest [1] that adds (you guessed it!) "leapsectz right/UTC" to the 
chronyd configuration using a fragment in /etc/chrony/conf.d.


As to set "leapsectz right/UTC" by default, it's something I've been 
planning to do for some time, but I always step back knowing that this 
will cause problems for users of leap smearing servers [2] and those who
don't update their systems and find themselves with an obsolete version 
of tzdata (nothing I can do here though).



And add a Depends on tzdata, so that the timezone info is
available.


[…]


Kurt


Cheers,
Vincent

[1] 
https://salsa.debian.org/debian/chrony/-/commit/3124fb4c8ec547b5a1e606ccb8d02906166960e3
[2] Notably the Debian Cloud Team that configured chrony (used by 
default) to use the Amazon Time Sync Service for EC2 and the internal 
NTP server provided by Google (metadata.google.internal) for the GCE 
images. Both serve leap-smeared time.


signature.asc
Description: PGP signature

Bug#974762: apt-listbugs: [INTL:pt] Portuguese translation for debconf messages

[Francesco Poli]

On Sun, 15 Nov 2020 15:54:44 +0100 Francesco Poli wrote:

[...]
> The word "pin" has been translated as "fixar" elsewhere: can we improve
> consistency and use the same translation here, as well?
> Would something like the following be OK?
> 
> " -F   : Fixar automaticamente a todos os pacotes com bugs.\n"
> 
> " -N   : Nunca fixar automaticamente a pacotes.\n"

Or maybe better:

" -F   : Fixar automaticamente todos os pacotes com bugs.\n"

" -N   : Nunca fixar automaticamente pacotes.\n"



-- 
 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


pgpgKLOIy57qJ.pgp
Description: PGP signature

Bug#944386: autopkgtest: can autopkgtest-build-qemu create a QEMU/KVM image without requiring superuser privileges?

[Simon McVittie]

On Wed, 20 Nov 2019 at 17:36:39 +0100, Martin Pitt wrote:
> Francesco Poli (wintermute) [2019-11-08 23:59 +0100]:
> > Is there any hope to improve vmdb2 or to use another tool, in order
> > to create a KVM testbed without requiring superuser privileges?
> 
> A much better approach to this would be what autopkgtest-buildvm-ubuntu-cloud
> does, and use a cloud image.

I think there's a place for both options. Starting from a cloud image
definitely seems better for a lowest-common-denominator, "I just want some
sort of testing" requirement set, and I would certainly prefer support
for new architectures to start from "first, make the cloud image work"
rather than always having to know how to build an autopkgtest-specific
bootable image from first principles.

One approach to this is to take a generic cloud image and modify it to
provide the serial ports that autopkgtest-virt-qemu currently needs,
like autopkgtest-buildvm-ubuntu-cloud does.

Another approach that I've been experimenting with is to make use of
the fact that cloud images already include cloud-init and a ssh server,
and use cloud-init to bring up the ssh server with a known public key
accepted. This seems less fragile than injecting commands on serial ports.

What building our own images *does* give us is total control. This is
partly bad, because we have to know all the tricks for making images
bootable on assorted architectures, but also partly good, because it lets
us test the different sorts of image that we want to support (EFI vs BIOS
boot, GPT vs MBR, systemd vs sysv-rc, merged-/usr vs unmerged-/usr).
This is particularly important when there are irreversible conversions
involved (you can go from unmerged /usr to merged /usr, but you can't
go from merged /usr to unmerged /usr).

I think the future I'd prefer to live in is that we *mostly* test on
cloud-derived images, but we also have the ability to build our own
autopkgtest-specific images for at least x86_64, and we can use those
to test the configurations that are not used on cloud images.

If that's how things work, then having autopkgtest-build-qemu be runnable
as non-root becomes a lot less important, because casual users with no
particularly special requirements will be using the cloud images anyway.

Another thing that has occurred to me when working on autopkgtest is
that it seems wasteful that we have so many wrappers around debootstrap,
which requires root (or playing with namespaces like mmdebstrap does,
or some other special action) and is not very fast. I would prefer to
be able to debootstrap a minbase tarball *once*, and then use that same
tarball as a basis for a bootable qemu image, lxc, lxd and Docker root
filesystems, and so on.

smcv

Bug#973870: linux: Please consider enabling CONFIG_DEBUG_INFO_BTF

[Simon Ruderich]

Hello,

it would be great if this makes it into Bullseye. BTF is not only
relevant for tracing but for all BPF-related tasks, including for
example XDP.

According to [1], most other distributions (Fedora 31+, RHEL
8.2+, Arch Linux, Ubuntu 20.10+) already enable BTF. Having this
in the next Debian release would be very useful.

I installed the dwarves package and tested building the linux
source package with CONFIG_DEBUG_INFO_BTF and it worked fine.

Regards
Simon

[1] https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#964955: [Tts-project] Bug#964955: The upstream has moved the modules to libexec

[Samuel Thibault]

KOLANICH via Tts-project, le dim. 15 nov. 2020 20:45:22 +0300, a ecrit:
> The upstream has moved the modules to libexec. Now it is Debian turn. 
> https://github.com/brailcom/speechd/pull/370

It's moved in version 0.11 only.

Again, I don't want to deviate from upstream behavior, to avoid
confusions. Some people are shipping speech-dispatcher modules, they
need to reliable way to know where they are supposed to put them.

So it will have to wait for speech dispatcher 0.11.

Samuel