Bug#941407: tmperamental makes ls(1) segfault

[Jakub Wilk]

Package: tmperamental
Version: 1.1
Severity: grave

tmperamental makes ls(1) crash:

   $ tmperamental ls
   Segmentation fault

Backtrace:

#0  0x in ?? ()
#1  0xf7f2850e in selinuxfs_exists_internal () at init.c:64
#2  0xf7f1fee0 in init_selinuxmnt () at init.c:99
#3  init_lib () at init.c:154
#4  0xf7f7f0ec in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xff923a34, env=0xff923a3c) at dl-init.c:72
#5  0xf7f7f1f2 in call_init (env=0xff923a3c, argv=0xff923a34, argc=1, l=) at dl-init.c:30
#6  _dl_init (main_map=, argc=1, argv=0xff923a34, 
env=0xff923a3c) at dl-init.c:119
#7  0xf7f700fa in _dl_start_user () from /lib/ld-linux.so.2


AFAICS, libselinux has a constructor which uses fopen(), and that 
constructor runs earlier than tmperamental's one, leading to null 
pointer dereference.


-- System Information:
Architecture: i386

Versions of packages tmperamental depends on:
ii  libc6  2.29-2

--
Jakub Wilk

Bug#908670: Any chance to get libbiod compiling again?

[Scott Kitterman]

On Thu, 19 Sep 2019 17:23:23 +0200 Andreas Tille  wrote:
> Control: reassign -1 ftp.debian.org
> Control: retitle -1 ROM: libundead: Please remove this package from Debian
> 
> Hi ftpmasters,
> 
> libundead is not used any more and should be removed.

Actually, it is:

Checking reverse dependencies...
# Broken Depends:
libbiod: libbiod0 [amd64 i386]
sambamba: sambamba [amd64]

# Broken Build-Depends:
libbiod: libundead-dev
sambamba: libundead-dev (>= 1.0.9-2)

Dependency problem found.

If you still want this removed, please remove the moreinfo tag once these have 
been resolved.  If you don't, please close the bug.

Scott K

Bug#941405: ITP: ruby-tty-screen -- Ruby library that detects terminal screen size for many platforms

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-tty-screen
  Version : 0.7.0
  Upstream Author : Piotr Murach 
* URL : https://ttytoolkit.org/
* License : expat
  Programming Lang: Ruby
  Description : Ruby library that detects terminal screen size for many 
platforms

tty-screen implements terminal screen size detection which works on Linux, OS
X and Windows/Cygwin platforms and supports MRI, JRuby and Rubinius
interpreters.

It is a component of the TTY Toolkit.


This library is required by ruby-tty-reader, which in the end is needed for
packaging puppet-development-kit.

I plan on maintaining this package with the ruby team. I will ask for
sponsorship from within the team to ensure that I follow the team's policies.

Bug#941404: ITP: ruby-tty-cursor -- Ruby library to help move the terminal cursor around and manipulate text by using intuitive method calls

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-tty-cursor
  Version : 0.7.0
  Upstream Author : Piotr Murach 
* URL : https://ttytoolkit.org/
* License : expat
  Programming Lang: Ruby
  Description : Ruby library to help move the terminal cursor around and 
manipulate text by using intuitive method calls

tty-cursor makes it easy to programatically move the cursor in a terminal
without needing to know terminal control codes. It is a component of the TTY
Toolkit.


This library is required by ruby-tty-reader, which in the end is needed for
packaging puppet-development-kit.

I plan on maintaining this package with the ruby team. I will ask for
sponsorship from within the team to ensure that I follow the team's policies
properly.

Bug#941403: ITP: ruby-tty-reader -- A set of methods for processing keyboard input in character, line and multiline modes

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-tty-reader
  Version : 0.6.0
  Upstream Author : Piotr Murach 
* URL : https://ttytoolkit.org/
* License : expat
  Programming Lang: Ruby
  Description : A set of methods for processing keyboard input in 
character, line and multiline modes

tty-reader is a pure Ruby library that is part of the TTY Toolkit that
provides a set of methods for processing keyboard input in character, line and
multiline modes. It maintains history of entered input with an ability to
recall and re-edit those inputs. It lets you register to listen for keystroke
events and trigger custom key events yourself.


This library is required by ruby-tty-prompt, which in turn is necessary for
packaging puppet-development-kit.

I plan on maintining this package with the ruby team. I will ask for
sponsorship within the team so that I can ensure that I'll respect the team's
policies.

Bug#941402: memtailor FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: memtailor
Version: 1.0~git20160311-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

memtailor fails to cross build from source, because it abuses
AC_CHECK_FILE. The macro is meant to check for files on the host system,
but memtailor uses it to check for files expected on the build system.
Please use a simple test -e for the latter. Please consider applying the
attached patch.

Helmut
--- memtailor-1.0~git20160311.orig/configure.ac
+++ memtailor-1.0~git20160311/configure.ac
@@ -32,7 +32,7 @@
 AS_IF([test "x$with_gtest" == "x"], [with_gtest="download"])
 
 AS_IF([test "x$with_gtest" == "xdownload"],
-  [with_gtest="yes"; AC_CHECK_FILE([$GTEST_PATH/src/gtest-all.cc], [], [
+  [with_gtest="yes"; AS_IF([test -e "$GTEST_PATH/src/gtest-all.cc"], [], [
 echo "downloading of gtest disabled" >&2; exit 1
 mkdir -p "$GTEST_PATH";
 (
@@ -52,7 +52,7 @@
 fi
   ])],
   [test "x$with_gtest" == "xyes"], [
-AC_CHECK_FILE([$GTEST_PATH/src/gtest-all.cc], [], [
+AS_IF([test -e "$GTEST_PATH/src/gtest-all.cc"], [], [
   AC_MSG_ERROR([could not find gtest source at path $GTEST_PATH.])
 ])
   ],

Bug#941401: ITP: ruby-tty-color -- Ruby library that provides terminal color capabilities detection

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-tty-color
  Version : 0.5.0
  Upstream Author : Piotr Murach 
* URL : http://piotrmurach.github.io/tty
* License : expat
  Programming Lang: Ruby
  Description : Ruby library that provides terminal color capabilities 
detection

tty-color is a simple library that provides independent color support
detection. It is a component for TTY toolkit.


This is a requirement to ruby-pastel, which is needed to create the package
puppet-development-kit.

I plan on maintaining this package with the ruby team. I will ask for
sponsorship within that team so that I can ensure that I respect the team's
policies.

Bug#941398: ITP: ruby-equatable -- Ruby module that adds explicit indications of whether objects can be compared in equality checks

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-equatable
  Version : 0.6.1
  Upstream Author : Piotr Murach 
* URL : https://github.com/piotrmurach/equatable
* License : expat
  Programming Lang: Ruby
  Description : Ruby module that adds explicit indications of whether 
objects can be compared in equality checks

Equatable extends Ruby objects with equality comparison and inspection
methods. By including this module, a class indicates that its instances have
explicit general contracts for `hash`, `==` and `eql?` methods.

Specifically eql? contract requires that it implements an equivalence
relation. By default each instance of the class is equal only to itself. This
is a right behaviour when you have distinct objects. However, it is the
responsibility of any class to clearly define their equality. Failure to do so
may prevent instances to behave as expected when for instance Array#uniq is
invoked or when they are used as Hash keys.


This package is a requirement of ruby-pastel, which if we move further up the
requirements tree, is needed in order to be able to package
puppet-development-kit.

I plan to maintain this package with the ruby team. I will ask for sponsorship
from within this team so that I'm sure that my package will respect the team's
policies.

Bug#941399: dino-im FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: dino-im
Version: 0.0.git20190916.f746ce7-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dino-im has a strange build system. It actually uses cmake with ninja
but wraps it inside configure and make. Doing so prevents debhelper from
passing the relevant cross compilation flags to cmake and thus
configures for the build architecture. The attached patch makes it use
cmake and ninja directly. However it doesn't make dino-im cross
buildable yet due to #889925. Please consider applying this patch anyway
as an incremental improvement and close this bug when doing so.

Helmut
diff --minimal -Nru dino-im-0.0.git20190916.f746ce7/debian/changelog 
dino-im-0.0.git20190916.f746ce7/debian/changelog
--- dino-im-0.0.git20190916.f746ce7/debian/changelog2019-09-17 
22:57:20.0 +0200
+++ dino-im-0.0.git20190916.f746ce7/debian/changelog2019-09-30 
06:00:18.0 +0200
@@ -1,3 +1,10 @@
+dino-im (0.0.git20190916.f746ce7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Imrpove cross building: Use cmake+ninja directly. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 30 Sep 2019 06:00:18 +0200
+
 dino-im (0.0.git20190916.f746ce7-1) unstable; urgency=medium
 
   * New upstream git snapshot
diff --minimal -Nru dino-im-0.0.git20190916.f746ce7/debian/rules 
dino-im-0.0.git20190916.f746ce7/debian/rules
--- dino-im-0.0.git20190916.f746ce7/debian/rules2019-09-17 
22:56:37.0 +0200
+++ dino-im-0.0.git20190916.f746ce7/debian/rules2019-09-30 
06:00:18.0 +0200
@@ -3,10 +3,9 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-   dh $@
+   dh $@ --buildsystem=cmake+ninja
 
 override_dh_auto_configure:
-   SHARED_SIGNAL_PROTOCOL=1 ./configure --prefix=/usr 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/dino-im --bindir=/usr/bin 
--enable-plugin=notification-sound
+   SHARED_SIGNAL_PROTOCOL=1 dh_auto_configure -- 
-DENABLED_PLUGINS=notification-sound -DBIN_INSTALL_DIR=/usr/bin 
-DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/dino-im
 
-override_dh_auto_clean:
-   rm -rf build/ Makefile
+override_dh_auto_test:

Bug#941400: rbootd FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: rbootd
Version: 2.0-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rbootd fails to cross build from source, because does not use the host
architecture in any way. The attached patch uses dpkg's buildtools.mk to
supply the relevant tools. Please consider applying it. Alternatively
consider switching the package to using debhelper and dh_auto_build.

Helmut
diff -u rbootd-2.0/debian/changelog rbootd-2.0/debian/changelog
--- rbootd-2.0/debian/changelog
+++ rbootd-2.0/debian/changelog
@@ -1,3 +1,10 @@
+rbootd (2.0-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 30 Sep 2019 06:01:52 +0200
+
 rbootd (2.0-10) unstable; urgency=low
 
   * New-Maintainer upload (closes: Bug#465907)
diff -u rbootd-2.0/debian/rules rbootd-2.0/debian/rules
--- rbootd-2.0/debian/rules
+++ rbootd-2.0/debian/rules
@@ -12,15 +12,14 @@
 
 package=rbootd
 
-ARCH  := $(shell dpkg --print-architecture)
-
+include /usr/share/dpkg/buildtools.mk
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 CFLAGS = -g -O2 -Wall $(shell getconf LFS_CFLAGS)
 else
 CFLAGS = -O2 -Wall $(shell getconf LFS_CFLAGS)
 endif
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-STRIP = -s
+STRIP_OPT = -s --strip-program=$(STRIP)
 endif
 
 export BASEDIR=$(shell pwd)/debian/tmp
@@ -29,7 +28,7 @@
 
 build:
$(checkdir)
-   $(MAKE) -f Makefile.linux CFLAGS="$(CFLAGS)" rbootd
+   $(MAKE) -f Makefile.linux CC="$(CC)" CFLAGS="$(CFLAGS)" rbootd
touch build
 
 clean:
@@ -52,7 +51,7 @@
install -d debian/tmp
cd debian/tmp;install -d `cat ../dirs`
install -d ${BASEDIR}/DEBIAN
-   install -o root -g root -m 0755 $(STRIP) rbootd ${BASEDIR}/usr/sbin
+   install -o root -g root -m 0755 $(STRIP_OPT) rbootd ${BASEDIR}/usr/sbin
install -o root -g root -m 0644 debian/default 
${BASEDIR}/etc/default/rbootd
install -o root -g root -m 0755 debian/rbootd.init.d 
${BASEDIR}/etc/init.d/rbootd
install -o root -g root -m 0644 etc-rbootd/rbootd.conf ${BASEDIR}/etc

Bug#941397: RM: libsoc -- RoQA; popcon literally 0; python2-only; only a single MU followed by 1 QA upload; orphaned since ~2 years

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941396: ITP: ruby-pastel -- Terminal strings styling with intuitive and clean API

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: ruby-pastel
  Version : 0.7.3
  Upstream Author : Piotr Murach 
* URL : https://piotrmurach.github.io/tty/
* License : expat
  Programming Lang: Ruby
  Description : Terminal strings styling with intuitive and clean API

Pastel is a ruby library that helps to colorize output on the terminal. It is
minimal and focused to work in all terminal emulators. It provides provides
independent coloring component for TTY toolkit.


This package is required as a dependency to puppet-development-kit.

I plan to maintain this package as part of the ruby team, and will request
sponsoring from within the team to ensure that I respect their policies.

Bug#827051: check if dep5 license texts are GFDL or GFDL-NIV

[Nicholas D Steeves]

Hi Chris,

On Wed, Oct 25, 2017 at 03:13:18PM +0100, Chris Lamb wrote:
> Hi,
> 
> > lintian should check that license blocks with short name GFDL-X.Y
> > are actually GFDL-X.Y (in which case they would be non-DFSG), or
> > if they should instead have short name GFDL-NIV-X.Y
> 
> How can Lintian tell the difference? Could you provide an example? :)
> 

I've encountered a related issue while packaging
emacs-ivy-doc-non-dfsg.  It has "Section: non-free/editors" and the
org file source used to generate its documentation is "License:
GFDL-1.3+", with invariant front-cover and back-cover texts.

Lintian errors with:

E: emacs-ivy-doc-non-dfsg source: license-problem-gfdl-invariants
debian/copyright invariant part is: with no invariant sections,
with the front-cover texts being a gnu manual, and with the
back-cover texts as in (a) below…

I would like to propose the following solution for Ryan's issue, which
also solves the error I'm experiencing:

Keep the existing parsing.  Definitely document that a lintian
override is not appropriate for the initial upload (such an override
feels like it should be an NEW AUTOREJECT).  Then add the following cases:

If a stanza has License: GFDL (no qualifiers), or GFDL-x.y[+|-only]
and the declared section isn't non-free/foo, then error. 

If a stanza has License: GFDL-x.y[+|-only], and invariants are found,
and the section is correctly declared as non-free/foo, then warn but
do not error.  That warning is an extra hint to ftpmasters imho.

If a stanza has License: GFDL-NIV.* then warn.

I've probably left out a number of possible cases, but I'll leave
those to someone more capable.  What I'm not sure about is what to do
on subsequent uploads...  It would be nice to have the liberty to
override the warning and hide it if a maintainer is 100% certain that
upstream won't budge on their choice of license.  On the other hand, I
see the benefit of a nagging lintian output to remind the maintainer
to contact upstream about their choice of license.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#941115: Fwd: Bug#941115 closed by Ben Hutchings (Re: Bug#941115: linux-image-4.19.0-6-686: cat /proc/acpi/ibm/video ,computer dead !thinkpad_acpi bug?)

[Faris Xiao]

Thank you feedback!

在 2019/9/29 上午1:39, Henrique de Moraes Holschuh 写道:
> On Thu, 26 Sep 2019, Faris Xiao wrote:
>> please help see this question:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941115
> That report is very light on the details AND it is written in extremely
> imprecise language.
>
> You did not even say if it is a new issue, or if it is a bug that has
> always been there...
It's a bug always been there.It take place very time,it's reproduceable.
>
> It is no wonder the Debian kernel maintainer closed it.
>
>> Bug#941115: linux-image-4.19.0-6-686: cat /proc/acpi/ibm/video ,computer
>> dead !thinkpad_acpi bug?)
> Please describe exactly what you mean with "computer dead".
>
> For all I know, it could either just hang, or it could be with the
> screen off but still running, or it could have been stuck into a
> firmware state where it doesn't want to work again, even if you power it
> off and on.
>
> Use precise language and do NOT skip the details when reporting issues,
> or we won't understand what you mean.
Please see the following describe info:

1.screen off, no any display,It's whole dark.

2.network down, ping has not respond

3.Fn + Home,Fn + End, they can work.The  background light of screen can
been tuned.

4.need to press power button to shutdown computer, after power on it
again,computer can normal boot ,but bug is still exist.


>
>> These commands also cause my computer dead.
>>
>> Is there i915 driver problem ? I has these error info in dmesg:
>>
>> [    4.847462] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
>> CPU pipe A FIFO underrun
>> [    4.847559] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
>> *ERROR* pipe B underrun
>> [    4.847640] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
>> CPU pipe B FIFO underrun

It's another bug,I had reported on:

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

https://bugs.freedesktop.org/show_bug.cgi?id=111838

This bug need Intel to trouble analysis.

> The ACPI video control exposed by /proc/acpi/ibm/video is an old
> interface, it has been mostly superseded by other APIs since i915 came
> around, some of which are also now gone too.
>
-- 
肖盛文  Faris Xiao




signature.asc
Description: OpenPGP digital signature

Bug#929825: Version 7 available upstream

[Vincent Lefevre]

On 2019-06-01 13:47:15 +0800, 積丹尼 Dan Jacobson wrote:
> https://imagemagick.org/script/download.php has a new version.

It would be really nice to have it in Debian as version 6.9 has bugs.
And before one can report bugs upstream, one needs the latest version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#941393: My bad

[submitbug]

This is the first time I post a report.
Please close #941393 and use #941394

Bug#639086: jhbuild: Missing moduleset DTD and schemas

[Guillem Jover]

Hi!

On Sun, 2019-09-29 at 17:53:44 -0400, Jeremy Bicha wrote:
> The general opinion is that people should download the moduleset
> they want from
> https://gitlab.gnome.org/GNOME/jhbuild/tree/master/modulesets/
> 
> jhbuild upstream used to keep old versioned modulesets around. Now
> they don't which means that the provided modulesets which target git
> master for each project will gradually deteriorate as upstream
> projects add new dependencies and local copies aren't updated.
> 
> I mean someone could update jhbuild in Debian stable releases; it's
> just not really been done so far and isn't a high priority for us.

Sure, that's fine. My request was for the moduleset DTD files though,
I guess the wording in the initial bug might have been confusing, even
though I see at least the Subject and the followup proposed debhelper
fragment files were somewhat clear. :D

The problem is that I have X.Org's moduleset definitions coming from
X.Org's git, and I'm converting those into another format via XML tools,
but for that I need the moduleset DTD.

Just adding the proposed debhelper install fragment would do.

Thanks,
Guillem

Bug#940271: display: selecting the area for crop is very slow on a big image (regression)

[Vincent Lefevre]

Control: retitle -1 display: selecting the area for crop is very slow on a big 
image with the nouveau and radeon drivers

On 2019-09-17 13:43:10 +0200, Vincent Lefevre wrote:
> And with a different remote machine (same network as on the above
> remote machine), this is very slow, like with the local machine.
> The machine where this is fast uses the nvidia driver, while the
> other two machines uses the nouveau driver.

I've received a mail from someone saying that he has the same problem
with the radeon driver.

BTW, several years ago, I was using only the nouveau driver, and
AFAIK, I did not notice this issue. So, there seems to be a regression
somewhere.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#941395: lintian: tries to do math on package version strings: Argument "1exp1" isn't numeric in addition (+)

[Thorsten Glaser]

found 941395 2.24.0
thanks

On Mon, 30 Sep 2019, Thorsten Glaser wrote:

> Package: lintian
> Version: 2.23.0

Oops sorry, I forgot to make the version match the one used
in the chroot during build; here, the host version bled through.

That being said, running…

$ lintian -vIiE --pedantic musescore_3.2.3+dfsg1-2.dsc

… with 2.23.0 also shows the message.

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

Bug#941395: lintian: tries to do math on package version strings: Argument "1exp1" isn't numeric in addition (+)

[Thorsten Glaser]

Package: lintian
Version: 2.23.0
Severity: normal

[…]
N: Processing source package musescore (version 3.2.3+dfsg1-2, arch source) ...
Argument "1exp1" isn't numeric in addition (+) at 
/usr/share/lintian/checks/debian/changelog.pm line 211.
[…]

This is from the presence of…

musescore (3.2.3+dfsg1-1exp1) experimental; urgency=low

… as second entry in d/changelog. The “exp” clearly is a string part.


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

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

Versions of packages lintian depends on:
ii  binutils 2.32.51.20190909-1
ii  bzip21.0.8-2
ii  diffstat 1.62-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36
ii  libarchive-zip-perl  1.66-2
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdigest-sha-perl   6.02-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.32.51.20190909-1
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

Bug#941393: Padlock icon indicates a secure TLS connection established w MitM-ed

[submitbug]

Package: firefox
Version: 68.0
Severity: grave

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

The same thing applies to Mozilla Firefox. This is still ongoing issue.

https://trac.torproject.org/projects/tor/ticket/24351
https://github.com/mozilla-mobile/focus-android/issues/1743
https://codeberg.org/crimeflare/cloudflare-tor/


-- System Information:
Debian Release: 10
APT prefers stable-updates

Bug#941394: Padlock icon indicates secure TLS connection established w MitM-ed

[submitbug]

Package: firefox
Version: 69.0.1-1
Severity: grave

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

The same thing applies to Mozilla Firefox. This is still ongoing issue.

How to reproduce
1. Install Tor.
2. Set proxy.
3. Browse the internet.

Actual behavior
Padlock is green.

Expected behavior
Padlock is not green but a gray with exclamation mark.

Read
https://trac.torproject.org/projects/tor/ticket/24351
https://github.com/mozilla-mobile/focus-android/issues/1743
https://codeberg.org/crimeflare/cloudflare-tor/


-- System Information:
Debian Release: 10
APT prefers stable-updates

Bug#941392: firefox-esr: No TLS 1.2

[Douglas A. Tutty]

Package: firefox-esr
Version: 60.9.0esr-1~deb10u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I don't know when they started to, but northwestel (my internet
provider), and pcfinancial (my credit card) now check that the browser
supports TLS 1.2 and if it does not, will not allow acess to the secure
part of their website.  This means I can't check my internet usage
(going over the monthly limit is very expensive here in the Yukon) nor
check or pay my credit-card on-line.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I can't find any TLS options in preferences; upstream says it supports
TLS 1.2.  The sites that check say I'm running an out-of-date brower.

   * What was the outcome of this action?

Denied access to the sites.
   * What outcome did you expect instead?

Proper TLS 1.2 support.

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


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libgtk-3-03.24.5-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1+deb10u1
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec57  10:3.3.9-dmo1+deb9u1
ii  libavcodec58  10:4.1.4-dmo1+deb10u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-3
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4+deb10u1

-- debconf-show failed


Thanks.

Bug#940678: Please import pools by stable device label

[Antonio Russo]

On 9/29/19 2:30 PM, Alberto Berti wrote:
> Hi Antonio,
> 
> thanks for answering.

No problem! :-)

> 
>> "Antonio" == Antonio Russo  writes:
> 
> Antonio> Could you please clarify: did you experience any data loss,
> Antonio> or were you simply unable to import your pool at one point?
> 
> The pool systematically fails to mount after the upgrade, at each boot,
> even if I manually mounted it.. 

The terminology with ZFS is a little different: pools are "imported"
and the datasets (that are filesystems rather than, say, zvols) are then
"mounted".  It sounds like you cannot import the pool, and therefore you
cannot mount the datasets.

Is your problem reproducible? By that I mean, on reboot, does the pool
import or not?

And what do you mean by "manually mounted it"? Are you talking about

# zpool import -d /dev -aN

If it's not mounting on reboot, just use -d /dev/disk/by-id next time,
and the problem should go away.

> this leads to data loss from a user pow, because the data that's not> there 
> may get re-written and generate conflicts.
If another application does not gracefully handle missing data, by all
means that is a bug for that application. That's not, however, a ZFS
bug.

I would encourage you to open a separate bug, unrelated to this, for
that issue.

> 
> Antonio> As a second note, you should have done something like
> 
> Antonio> zpool import -d /dev/disks/by-id -a
> 
> Antonio> so that your import is done by labels that are stable
> Antonio> across boots (names like /dev/sdX are not necessarily
> Antonio> stable). This is a "well-known" best practice with ZFS [1]
> Antonio> (you should always create pools using these symlinks as
> Antonio> well).
> 
> good to know, thanks. Although I think that if the hardware
> configuration nor the kernel version changes between the boots, we can
> assume that each block device will get the same id... anyway I'll try it.

First off, there's typo. Use /dev/disk/by-id . Not with an extra s.

You can check this---note which device nodes are being linked by the
stable identifiers in /dev/disk/by-id. Do they change on reboot?

If you find that your device nodes are to exactly the same drives, and
yet the pool is not importing as you have found, that's definitely a bug,
and we'll have to file it upstream. You will need verbatim dmesg logs,
the zpool status $poolname output, and the output of ls -l /dev/disk/by-id
on subsequent boots.

Upstream will want to see exactly what is going on with the device nodes,
since that's the most likely cause of this problem.

> 
> Antonio> If you have only experienced an inability to import your
> Antonio> pool at boot, my guess is that you had (and continue to
> Antonio> have) the inappropriate import by device node setup. This
> Antonio> configuration error will lead to you continuing to have
> Antonio> problems importing your pool at later times, and is not a
> Antonio> bug. To fix that problem you should zpool export all your
> Antonio> pools (this might be tricky, especially if you are zfs on
> Antonio> root), and then run the above command. As always, double
> Antonio> check all this!
> 
> uhumm, Yes, that is tricky, as I read that the export operation unmounts
> every exported fs before the operation.

Yes, to export a pool, none of its datasets can be in use (e.g., mounted).
Be careful with the terminology here---exporting a filesystem (or dataset)
means something totally different than exporting a pool.

> 
> So you say that if I do that the start of the zfs-import-cache in the
> next boot will succeed?

Barring a new bug, yes.

> 
> thank you
> 
> Alberto
> 

Best,
Antonio

Bug#941372: texlive-extra-utils: A new version of pythontex is available

[Norbert Preining]

Hi Emmanual,

On Sun, 29 Sep 2019, Emmanuel Charpentier wrote:
> An update of the Debian TeXLive packaging should include this new version. Any
> (gues)stimate of the time such an update could be available ?

Usual time scale, about once a month - I am already preparing an upload
;-)

Norbert

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

Bug#941391: rdate: New upstream release and homepage

[Joao Eriberto Mota Filho]

Package: rdate
Severity: wishlist

Dear maintainer,

The OpenRdate Project has a new homepage[1] and version (1.10). Please,
consider packaging it.

[1] https://github.com/resurrecting-open-source-projects/openrdate

Thanks!

Regards,

Eriberto

Bug#941390: lix: New upstream release available

[Andreas Ronnquist]

Package: lix
Version: 0.9.24-1+b2
Severity: wishlist

Dear Maintainer,

There's a 0.9.29 release available - please package it in Debian.

Thanks for your work on the Lix package!

-- Andreas Rönnquist
gus...@debian.org


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

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

Versions of packages lix depends on:
ii  liballegro-acodec5.2 2:5.2.5.0-3
ii  liballegro-audio5.2  2:5.2.5.0-3
ii  liballegro-image5.2  2:5.2.5.0-3
ii  liballegro-ttf5.22:5.2.5.0-3
ii  liballegro5.22:5.2.5.0-3
ii  libc62.29-2
ii  libgcc1  1:9.2.1-8
ii  libphobos2-ldc-shared87  1:1.17.0-2
ii  lix-data 0.9.24-1+b2

lix recommends no packages.

lix suggests no packages.

-- no debconf information

Bug#941389: virt-manager: Missing dependency from gir1.2-gtksource-4

[manul]

Package: virt-manager
Version: 1:2.2.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrading virt-manager to the latest version, once started it is unable 
to open virtual machine details/console pop windows (as well as some other pop 
windows like connection settings etc).
Installing gir1.2-gtksource-4 fixes the issue but, it is not in the current 
dependencies of virt-manager (which I believe it must be).

Thank you.


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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-gtk-3.0   3.24.11-1
ii  gir1.2-gtk-vnc-2.0   0.9.0-1.1+b1
ii  gir1.2-libosinfo-1.0 1.6.0-1
ii  gir1.2-libvirt-glib-1.0  1.0.0-1
ii  gir1.2-vte-2.91  0.58.0-1
ii  librsvg2-common  2.44.14-1
ii  python3  3.7.3-1
ii  python3-dbus 1.2.12-1
ii  python3-gi   3.34.0-1
ii  python3-gi-cairo 3.34.0-1
ii  python3-libvirt  5.0.0-1
ii  virtinst 1:2.2.1-1

Versions of packages virt-manager recommends:
ii  gir1.2-spiceclientglib-2.0  0.37-1
ii  gir1.2-spiceclientgtk-3.0   0.37-1
ii  libvirt-daemon-system   5.6.0-2

Versions of packages virt-manager suggests:
pn  gir1.2-secret-1  
pn  gnome-keyring
pn  python3-guestfs  
ii  ssh-askpass  1:1.2.4.1-10+b1
pn  virt-viewer  

-- no debconf information

Bug#941388: RM: editmoin -- RoQA; dead upstream, last release in 2011; python2-only; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941363: [filezilla] Filezilla doesn't start, returns an undefined symbol error

[Diederik de Haas]

Package: filezilla
Version: 3.39.0-2
Followup-For: Bug #941363

Confirming that I have the exact same issue.
I don't remember exactly when, but this issue started somewhere between
1 and 2 weeks ago, iow not today.
My sources.list only contains http://httpredir.debian.org/debian/, thus
it is a pure Debian system.

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

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

Versions of packages filezilla depends on:
ii  filezilla-common 3.39.0-2
ii  libatk1.0-0  2.34.0-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-1
ii  libfilezilla00.18.2-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgnutls30  3.6.9-5
ii  libgtk2.0-0  2.24.32-4
ii  libhogweed4  3.5.1+really3.4.1-1
ii  libnettle6   3.5.1+really3.4.1-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpugixml1v51.9-3
ii  libsqlite3-0 3.29.0-2
ii  libstdc++6   9.2.1-8
ii  libwxbase3.0-0v5 3.0.4+dfsg-12
ii  libwxgtk3.0-0v5  3.0.4+dfsg-12

Versions of packages filezilla recommends:
ii  xdg-utils  1.1.3-1

filezilla suggests no packages.

-- no debconf information

Bug#936764: jhbuild: Python2 removal in sid/bullseye

[Christoph Reiter]

On Sun, Sep 29, 2019 at 11:38 PM Jeremy Bicha  wrote:
>
> On Mon, Sep 23, 2019 at 3:03 AM Christoph Reiter
>  wrote:
> > jhbuild master now works with Python 3. There are likely still bugs as
> > the test coverage isn't that good.
> >
> > ./autogen.sh --with-python=python3
>
> It's easier to package from a tarball release than to do a git
> snapshot, so I will probably wait for a 3.35 release to package the
> new py3 jhbuild.

OK, I'll create a release next week.

Bug#639086: jhbuild: Missing moduleset DTD and schemas

[Jeremy Bicha]

Sorry for the very late response.

The general opinion is that people should download the moduleset they want from
https://gitlab.gnome.org/GNOME/jhbuild/tree/master/modulesets/

jhbuild upstream used to keep old versioned modulesets around. Now
they don't which means that the provided modulesets which target git
master for each project will gradually deteriorate as upstream
projects add new dependencies and local copies aren't updated.

I mean someone could update jhbuild in Debian stable releases; it's
just not really been done so far and isn't a high priority for us.

If I don't hear back from you, we'll probably eventually close this bug.

Thanks,
Jeremy Bicha

Bug#941044: elpa-elpy: creating the elpy-doc package

[Nicholas D Steeves]

Hi Salman,

On Tue, Sep 24, 2019 at 12:19:54AM +0200, Salman Mohammadi wrote:
> Package: elpa-elpy
> Version: 1.31.0-1
> Severity: wishlist
> 
> Dear Nicholas,
> 
> It would be nice if you create the package `elpy-doc` alongside
> elpa-elpy to manage html docs separately.
> 
> If you want, I can also offer my help, in form of an MR, to reduce the time
> you need to
> invest on this matter
> 

Thanks for the offer, I appreciate your enthusiasm! :-)

In this case I had previously decided to keep the html docs part of
the elpa-elpy package and not break them out, because:

While this is a hybrid elisp+python package, it primarily follows Emacs
packaging conventions. eg: originally it shipped documentation in info
and manpage formats, but not in html.  Adding html was a concession
for Python developers' expectations (this is a Python IDE after all!),
but I want the info page to remain part of the main package.

Debian Policy §12.3 states

If package is a build tool, development tool, command-line tool,
or library development package, package (or package-dev in the
case of a library development package) already provides
documentation in man, info, or plain text format, and package-doc
provides HTML or other formats, package should declare at most a
Suggests on package-doc. Otherwise, package should declare at most
a Recommends on package-doc.

That means that elpa-elpy would only be able to "declare at most a
Suggests on" proposed elpy-doc package, meaning it wouldn't be
installed by default with elpa-elpy.

The HTML docs are only 476K (a little over half the size of Parso's).
I'm not convinced that this fulfills "If a package comes with large
amounts of documentation that many users of the package will not
require" (Policy §12.3) recommendation for a separate doc package, and
also because IMHO Elpy is near impossible to use effectively without
its documentation; A poor experience with other IDEs' documentation is
another reason I've chosen a politic of "maximum accessibility to
documentation" for this package.  I also suppose that users will have
already installed some other Python documentation and reference
material, so am not counting the disk space for sphinx and libjs (and
rtd theme, thanks again for the MR) deps.

In a nutshell, I chose the current method because I believe it
provides the greatest good.  If enough people disagree, the options
that are conformant to policy seem to be:

  1. Create elpy-doc and move the man and info pages to this package,
 and Recommend it.  Users who install with --no-install-recommends
 may complain basic necessary documentation is not included, or
 may just give up.
  2. Move HTML docs to elpy-doc, and declare it as a Suggests.  Users
 may complain that their preferred format for documentation is not
 installed by default.  There was already a bug filed to this
 affect.

Let's keep this bug open for a few years, in case other people
disagree.


Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#941387: RM: cfget -- RoQA; dead upstream, HP 404s; python2-only; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941386: RM: balder2d -- RoQA; dead upstream, last release in 2009; python2-only; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#935189: python-pypdf2 removal

[Kjö Hansi Glaz]

I pushed a 0.3beta1 tag ported to python3 and depends on python3-pypdf2.
Feedback is welcome!

Cheers

Bug#939104: bookletimposer: Python2 removal in sid/bullseye -- drop python-distutils-extra build dependency

[Kjö Hansi Glaz]

I pushed a 0.3beta1 tag ported to python3 and depends on
python3-distutils-extra. Feedback is welcome!

Cheers

Bug#936764: jhbuild: Python2 removal in sid/bullseye

[Jeremy Bicha]

On Mon, Sep 23, 2019 at 3:03 AM Christoph Reiter
 wrote:
> jhbuild master now works with Python 3. There are likely still bugs as
> the test coverage isn't that good.
>
> ./autogen.sh --with-python=python3

It's easier to package from a tarball release than to do a git
snapshot, so I will probably wait for a 3.35 release to package the
new py3 jhbuild.

> The python-pygraphviz dep can be dropped, I can't find any usage of it
> in the code base.

I uploaded jhbuild 3.34 today and changed the suggested package to
graphviz since it supplies 'dot' which is suggested for a minor
feature in the jhbuild user help. Thanks for the tip!

I'm fine with this bug being Serious and jhbuild potentially dropping
out of Testing temporarily.

The jhbuild package hasn't included the modulesets since 2010. Those
can be either referenced directly over https or downloaded locally.
The jhbuild package is useful because you don't have to manually build
and install the Python scripts and keep them up to date manually. I
hope upstream continues to do periodic tarball releases.

I still find jhbuild to be more convenient than buildstream for my
GNOME stuff, but I packaged buildstream just in case (and it's
probably useful for someone).

Thanks,
Jeremy Bicha

Bug#941385: UT99: sound missing due to missing dependency osspd

[esp]

Package: game-data-packager
Version: 63
Severity: normal
Tags: newcomer

Dear Maintainer,

UT99.yaml perfectly packages Unreal Tournament. The game plays 100% fine
without the windowed mouse bug as present in Unreal Gold. The game however does
not have sound after initial installation due to missing deb package osspd (OSS
Proxy Daemon: Userland OSS emulation). As soon as this package gets installed
the sound works 100% fine. Suggestion to include a osspd package dependency to
inform user to apt install osspd. Thanks

Best regards,
ESP




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

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

Versions of packages game-data-packager depends on:
ii  dpkg1.19.7
ii  fakeroot1.23-1
ii  python3 3.7.3-1
ii  python3-debian  0.1.35
ii  python3-yaml3.13-2

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  63

Versions of packages game-data-packager suggests:
pn  arj   
ii  binutils  2.31.1-16
pn  cabextract
pn  cdparanoia
ii  dynamite  0.1.1-2+b2
ii  gcc   4:8.3.0-1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  innoextract   1.7-2+b1
pn  lgc-pg
pn  lgogdownloader
ii  lhasa [lzh-archiver]  0.3.1-3
ii  make  4.2.1-1.2
ii  p7zip-full16.02+dfsg-6
ii  python3-gi3.30.4-1
pn  steam 
pn  steamcmd  
pn  unace-nonfree 
ii  unar  1.10.1-2+b4
ii  unrar 1:5.6.6-1
pn  unshield  
ii  unzip 6.0-23+deb10u1
pn  vorbis-tools  
ii  xdelta1.1.3-9.2
pn  xdelta3   

-- no debconf information

Bug#941384: RM: libindicate -- RoQA; dead upstream, last release in 2013; orphaned; rc buggy; python2-only

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941383: RM: pidgin-libnotify -- RoQA; rc buggy; dead upstream, last release in 2008; popcon dropping rapidly; alternative exists

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941382: RM: cigi-ccl -- RoQA; rc buggy; version dead upstream; not in stable; last upload in 2015

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941381: Unreal: mouse stuck in unreal gold windowed mode

[esp]

Package: game-data-packager
Version: 63
Severity: normal
Tags: newcomer

Dear Maintainer,

Game-data-packager correctly installs Unreal Gold (unreal.yaml), the
proprietary linux launcher however has a bug in windowed mode in which the
mouse gets stuck in the upper right corner of the window. A workaround is to
switch to fullscreen mode via Alt+Return to have the mouse correctly working.
Suggestion to install Unreal Gold by default in fullscreen mode. This
fullscreen mode can be configured in /unreal-gold/System/UnrealLinux.ini by
setting StartupFullscreen=True. Thanks

Best regards,
ESP



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

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

Versions of packages game-data-packager depends on:
ii  dpkg1.19.7
ii  fakeroot1.23-1
ii  python3 3.7.3-1
ii  python3-debian  0.1.35
ii  python3-yaml3.13-2

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  63

Versions of packages game-data-packager suggests:
pn  arj   
ii  binutils  2.31.1-16
pn  cabextract
pn  cdparanoia
ii  dynamite  0.1.1-2+b2
ii  gcc   4:8.3.0-1
pn  gdebi | gdebi-kde 
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  innoextract   1.7-2+b1
pn  lgc-pg
pn  lgogdownloader
ii  lhasa [lzh-archiver]  0.3.1-3
ii  make  4.2.1-1.2
ii  p7zip-full16.02+dfsg-6
ii  python3-gi3.30.4-1
pn  steam 
pn  steamcmd  
pn  unace-nonfree 
ii  unar  1.10.1-2+b4
ii  unrar 1:5.6.6-1
pn  unshield  
ii  unzip 6.0-23+deb10u1
pn  vorbis-tools  
ii  xdelta1.1.3-9.2
pn  xdelta3   

-- no debconf information

Bug#940453: RM: toxiproxy -- ROM; no longer needed

[Scott Kitterman]

On Sunday, September 29, 2019 4:02:14 PM EDT Alexandre Viau wrote:
> I always test with the following method before I request a removal:
> 
>  - ssh mirror.ftp-master.debian.org "dak rm -Rn "
> 
> Could it be that it does not catch all cases where there are
> reverse-deps? And do the ftpmasters run some kind of check before
> removing a package?
> 
> Before we consider re-introducing toxiproxy, we should check if
> golang-github-shopify-sarama-dev's dependency is necessary.

Roughly the same check is run when we process removals.  I notice that there's 
an alternate to toxiproxy-dev, but it doesn't seem to exist in Debian.  Maybe 
it would be a better choice.

Scott K

Bug#941380: RFP: codebraid -- A pandoc wrapper enablong code execution in Markdown documents.

[Emmanuel Charpentier]

Package: wnpp
Severity: wishlist

* Package name: codebraid
  Version : 0.4.0
  Upstream Author : Geoffrey Poore 
* URL : https://github.com/gpoore/codebraid
* License : BSD 3-clause
  Programming Lang: Python
  Description : A pandoc wrapper enabling code execution in Markdown
documents.

Codebraid does for Markdown documents what pythontex does for LaTeX documents,
namely retrieving source code snippets in a Markdown document, running them in
the relevant interpreter and inserting the results (code, text and/or graphics)
in the compiled document, then processed by pandoc.

This functionality allows for the creation of consistent documents collecting
text, data, models, analysis code and results and discussion, thus achieving
some of the goals of Reproducible Research (see
https://en.wikipedia.org/wiki/Reproducibility#Reproducible_research).

This tool also allows for code fragments re-use, thus allowing to decouple the
explanatory text logic from the programming order, thus fullfilling some goals
of literate programming (https://en.wikipedia.org/wiki/Literate_programming).

These methodologies are important tools in the production of verifiable (e. g.
scientific) documents, and may be important in the production of well-
documented computer programs.

Analogous tools already exist: Among those dedicated to the production of
scientific documents, I have used the following:

  * D. Knuth's Web/CWeb system is the tool used to build TeX and Metafont,
supporting
Pascal and C code respectively, the text being LaTeX.

  * The R packages sweave and knitr , the latter supporting R, Python and Julia
code
and partially supporting a dozen other languages (no continuity between
code
snippets) ; the text is LaTeX.

  * SageTeX post-processes a LaTeX document containing Sagemath snippets (which
can
call about a dozen different tools and languages) and insert the results in
the
   document, which can be re-processed.

  * Pythontex does the same for LaTeX documents, supporting a half-dozen source
code
languages. Among them, Sagemath (which was my original reason to search for
an
alternative to knitr/SageTeX).

  * knitr can also be used with Markdown text.

  * The Babel system of emacs' org-mode supports about 70 source code
languages, using
a sui generis markup language.

I am also aware of the existence of various systems, each, to the best of my
knowledge, dedicated to a specific task:

  * The Sphinx ecosystem, dedicated to the documentation of Python source code.

  * Pweave (ditto).

Why package codebraid ?

  * Markdown support. Important for two reasons:

- Whereas LaTeX is ideal for the production of documents  ultimately aimed
at
  printing, it is ill-adapted to producing, for example, HTML or epub
documents.
  Parts of its cross-reference system, such as indexing, being page number
based,
  makes no sens for, say, a presentation or an ebook.

- Latex is much more heavy than Markdown, and, therefore, nowadays, much
less
  popular. It also needs more work: While I have practisdd LaTeX since
1987,
  I am still forced to use the disorganised, disparate and enormous
documentation
  of its zillions packages...

  * (Supposedly) easy addition of support for new source-code languages. (Note:
it
*seems* easy, but I am yet to do it in practice...). In comparison, adding
a new
language to knitr is heavy...

  * Independence of any editor (this one is aimed at org-mode : emacs isn't
everyone's tool...).

  * Programming language: not everybody is expert in R or in emacs-lisp... No
need to
maintain an R installation (you have to maintain a Python installation, but
this is
a basic Debian requirement...).

The cherry on my cake: in its current development version (0.5.0), codebraid
supports Sagemath (http://www.sagemath.org/).

TL;DR: notwithstanding Markdown's limitations (e. g. the lack of an universal
cross-reference system, inconsistencies in table handling, etc...), the
packaging of codebraid would offer to Debian users an important tool for the
creation of consistent documents via Markdown, without involving LaTeX heavy-
handedness.

Note: not being an Ordained Debian Developer (C)(R)(TM), I can't package it
myself. Thus this RFP.

Bug#941379: xfce4-mailwatch-plugin: please consider adding support for secret-tool and/or libsecret

[Scott Barker]

Package: xfce4-mailwatch-plugin
Version: 1.2.0-3
Severity: normal

Dear Maintainer,

Please consider adding support for secret-tool or libsecret for retrieving 
passwords, instead of storing them in plaintext.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfce4-mailwatch-plugin depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libexo-1-0   0.12.4-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcrypt20  1.8.4-5
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u1
ii  libgnutls30  3.6.7-4
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  xfce4-panel  4.12.2-1

xfce4-mailwatch-plugin recommends no packages.

xfce4-mailwatch-plugin suggests no packages.

-- debconf-show failed

Bug#933576: debhelper: dh_installman is terribly slow

[Niels Thykier]

Control: tags -1 pending

Colin Watson:
> On Sun, Sep 01, 2019 at 06:22:00AM +, Niels Thykier wrote:
>> Colin Watson:
>>> I think I might actually extend manconv instead; it already does a
>>> certain amount of what you need here and just needs autodetection of
>>> input encoding and the multiple-files interface.
>>>
>>> manconv is currently installed in man-db's libexecdir, but I could
>>> easily move it onto $PATH.  Since it isn't currently on $PATH, that
>>> would provide you with an easy way to test whether this new interface is
>>> supported (I could also add "manconv --has-bulk" or something, but I
>>> don't think it's necessary in this case).
>>
>> SGTM. :)
> 
> For internal code organisation reasons it ended up being easier to add a
> new "man-recode" tool instead.
> 
> Could you please try the tmp/recode-tool branch of
> https://git.savannah.gnu.org/cgit/man-db.git ?  To build it, something
> like this should work:
> 
>   sudo apt build-dep man-db
>   ./bootstrap
>   ./configure --prefix=/usr --libexecdir=\${libdir} 
> --with-config-file=/etc/manpath.config --enable-mb-groff 
> --enable-silent-rules --with-db=gdbm
>   make -j4
>   make -j4 check
> 
> You should then be able to run src/man-recode.
> 
> Initial performance testing from my end: to convert all the pages in
> manpages-pl to UTF-8, it takes about 0.6 seconds.  This is cheating
> slightly because it takes a short cut in the case where the pages
> already appear to be in UTF-8; so if I instead tell it to convert to
> ISO-8859-2, it takes about 6.3 seconds.  Compared to about 122 seconds
> (without parallelisation) with "man -l --recode UTF-8", I think that's
> probably good enough.
> 
> Thanks,
> 

Hi Colin,

I got around to testing your branch and the tool seem to work as
advertised.  Indeed, performance is a lot better with this tool compared
to "man --recode".

I have committed support for debhelper transparently using man-recode
when present instead of "man --recode" to master (closing this bug).
Please upload man-db with man-recode to Debian unstable at your
convenience. :)

Thanks,
~Niels

Bug#941378: initscripts: Boot broken on non-linux

[Samuel Thibault]

Package: initscripts
Version: 2.96~beta-2
Severity: normal

Hello,

Version 2.96~beta-2 introduced calling setterm during fsck, but that
isn't available on non-Linux and thus breaks the boot. Please make that
conditionned by the presence of setterm.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.8+git20190109-486-dbg/Hurd-0.9
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages initscripts depends on:
ii  coreutils   8.30-3
ii  debianutils 4.8.6.3
ii  lsb-base11.1.0
ii  sysv-rc 2.96~beta-2
ii  sysvinit-utils  2.96~beta-2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.44.6-1
ii  psmisc 23.2-1

initscripts suggests no packages.

-- Configuration Files:
/etc/default/tmpfs changed [not included]
/etc/init.d/checkfs.sh changed [not included]
/etc/init.d/checkroot.sh changed [not included]

-- no debconf information

-- 
Samuel Thibault 

Bug#940629: fatrace: add support for detecting rename events

[Martin Pitt]

Martin Pitt [2019-09-29 21:43 +0200]:
> I made some initial experiments with this today [1], on kernel 5.3. (Note that
> this won't eventually look like this, there needs to be a fallback for older
> kernels.) But so far this isn't encouraging -- the results for "normal"
> open/close/read/write are much worse. In particular, I get a lot of ESTALE
> event fds now that previously resolved to existing files just fine, and also
> the pid → /proc/pid/comm resolution is now much less reliable.

Note for myself: I found out the root cause: It's in the file_handle → fd
resolution in

event_fd = open_by_handle_at(AT_FDCWD, (struct file_handle *) fid->handle, 
O_RDONLY);

 Due to the AT_FDCWD this only works for events that are on the same file
 system as the cwd of fatrace (e. g. in --current-mount mode). There is some
 impedance mismatch of the fanotify FAN_EVENT_INFO_TYPE_FID API, which only
 delivers the rather useless "fsid", and open_by_handle_at() which expects
 "some fd from the mount point that contains the file handle".

So in "global" (not --current-mount) mode, this could work like this: When
iterating over /proc/self/mounts when setting up fanotifys for every mount,
open the mount point as "mount_fd", statfs() it, and remember a map fsid →
mount_fd, and do lookups in print_event when it calls open_by_handle_at().

I'll look at this at some later time.

Martin

Bug#875172: [rlplot] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:09:19PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: rlplot
> Version: 1.5-3
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

rlplot is dead upstream, does anyone intend to port it themselves? Otherwise
let's remove it, we're moving forward with the Qt4 removal.

Cheers,
Moritz

Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

[Emmanuel Arias]

Hello Raphael,

Thanks for your help and sorry for the my bad things on the package.

I have some question for you: Why impacket was uploaded to NEW? If you
restored python-impacket the build dependecies was not restored?


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

El dom., 29 de sep. de 2019 a la(s) 10:42, Raphael Hertzog
(hert...@debian.org) escribió:
>
> Hi,
>
> On Fri, 27 Sep 2019, Emmanuel Arias wrote:
> > I've just push to salsa the last changes.
> > I will need sponsorship to upload it.
>
> I took care of it. But I reverted the removal of python-impacket for
> now, it still has reverse dependencies in Debian (and even more in Kali).
>
> I had to cleanup a few things too, there was some upstream doc installed
> in a wrong directory (/usr/share/doc/impacket). The changelog was
> mishandled, the UNRELEASED entry for 0.9.19 should have been merged with
> the 0.9.20.
>
> And I had to rename debian/{install,links,examples} to 
> debian/python3-impacket.*
> but that's because I restored python-impacket. But in general, I find it
> better to be explicit about the target package so I tend to avoid the
> former names.
>
> You had already pushed a tag, in general it's best when the uploader
> pushes the tag so that if he has something to correct, he can do it.
> Thus I dropped your tag and you will have to drop it on your side if you
> want to get the correct one.
>
> Cheers,
>
> > El jue., 26 de sep. de 2019 a la(s) 17:02, Sophie Brun (
> > sop...@offensive-security.com) escribió:
> >
> > > Hi Emmanuel,
> > >
> > > ldapdomaindump is not in Debian but I packaged it for Kali last year.
> > > The repo is here:
> > > https://gitlab.com/kalilinux/packages/python-ldapdomaindump
> > > I don't remember if the package is totally compliant with the Debian
> > > policy but you can reuse it and improve it for Debian.
> > >
> > > For impacket: I build the package with the Kali package
> > > python3-ldapdomaindump: no tests are really run.
> > > I think we can just override dh_auto_test for the moment.
> > >
> > > I push few changes including a patch to avoid the installation of the
> > > examples/*py as scripts in usr/bin/
> > > There were not in usr/bin in python-impacket and I think it's better to
> > > not have all these scripts in /usr/bin (but it's only my personal 
> > > opinion).
> > >
> > > Cheers,
> > >
> > > Sophie
> > >
> > >
> > > Le 26/09/2019 à 17:06, Emmanuel Arias a écrit :
> > > > Hi Sophie, take care that I push some changes to salsa.
> > > >
> > > > the test are failing because |ldapdomaindump is not in debian (that is
> > > correct?) I will package |ldapdomaindump.||
> > > > ||
> > > > ||
> > > > ||So I think that the best solution is patch the tests to skipped it and
> > > in  new version (when |ldapdomaindump) is in|||
> > > > |||debian create a new version|||
> > > > |||
> > > > |||
> > > > |||any suggestion?|||
> > > > |||
> > > > |||
> > > > Cheers,
> > > > Arias Emmanuel
> > > > @eamanu
> > > > http://eamanu.com
> > > >
> > > >
> > > > El jue., 26 de sep. de 2019 a la(s) 11:03, Sophie Brun (
> > > sop...@offensive-security.com )
> > > escribió:
> > > >
> > > > Hello,
> > > >
> > > > Le 26/09/2019 à 15:18, Emmanuel Arias a écrit :
> > > > > I will update the package.
> > > >
> > > > I started to update the package (I need it for the reverse depends
> > > in pkg-security team)
> > > >
> > > > Can I push my changes on the git repo or maybe you prefer to update
> > > everything yourself?
> > > >
> > > > Cheers,
> > > > Sophie
> > > >
> > >
>
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>

Bug#874870: Version 2.x is qt5-based

[Moritz Mühlenhoff]

On Sun, Mar 18, 2018 at 09:11:24PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi! Version 2.x is qt5-based. Please check if you can update this game. Feel 
> free to ask for help with Qt5 if needed.

It's been 1.5 years and we're now moving forward with the Qt4 removal. The 
package
hasn't been uploaded since 2017, does anyone plan to update in the next weeks,
otherwise it'll be removed along with Qt4.

Cheers,
Moritz

Bug#941377: libpocketsphinx-dev: missing dependency on libsphinxbase-dev for pkgconfig file

[James Cowgill]

Package: libpocketsphinx-dev
Version: 0.8+5prealpha+1-6
Severity: important

Hi,

The pkgconfig file in libpocketsphinx-dev is broken because the package
is missing a dependency on libsphinxbase-dev:

$ pkg-config --libs pocketsphinx
Package sphinxbase was not found in the pkg-config search path.
Perhaps you should add the directory containing `sphinxbase.pc'
to the PKG_CONFIG_PATH environment variable
Package 'sphinxbase', required by 'pocketsphinx', not found

James



signature.asc
Description: OpenPGP digital signature

Bug#941376: Should monotone be removed?

[Moritz Muehlenhoff]

Source: monotone
Severity: serious

Should monotone be removed? Dead upstream, last upload three years ago
and removed from testing since 1.5 years.

Cheers,
Moritz

Bug#940453: RM: toxiproxy -- ROM; no longer needed

[Alexandre Viau]

I always test with the following method before I request a removal:

 - ssh mirror.ftp-master.debian.org "dak rm -Rn "

Could it be that it does not catch all cases where there are
reverse-deps? And do the ftpmasters run some kind of check before
removing a package?

Before we consider re-introducing toxiproxy, we should check if
golang-github-shopify-sarama-dev's dependency is necessary.

Cheers,

--
Alexandre Viau
av...@debian.org

On Sun, Sep 29, 2019 at 3:36 PM Paul Gevers  wrote:
>
> Hi all,
>
> On Sun, 15 Sep 2019 19:40:11 -0400 Alexandre Viau  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> >
> > toxiproxy is no longer needed by any package. It should
> > be removed from the archive.
> >
> > It used to be here as a dependency for telegraph which never made it to
> > the archive.
>
> golang-github-shopify-sarama depends on it. Any idea how this has
> slipped through? The removal of toxiproxy can't migrate to testing now.
>
> Paul

Bug#933577: transition: evolution-data-server

[Paul Gevers]

Control: tags -1 - moreinfo

Hi,

On Wed, 31 Jul 2019 18:53:21 +0100 Iain Lane  wrote:
> I've uploaded to experimental-NEW and I'm in the process of testing
> r(-build)-deps now. I'll make any bugs block this one so we can see
> what's needed. This definitely *will* need sourceful changes to quite a
> few packages. +moreinfo for now until we're ready to go.
> 
> Ben file (not super confident in the correctness of this but I guess we
> can fix it later):
> 
> title = "evolution-data-server";
> is_affected = .depends ~ 
> /libebook-1.2-19|libedata-book-1.2-25|libebook-contacts-1.2-2|libecal-1.2-19|libedata-cal-1.2-29|libebook-contacts-1.2-2/
>  | .depends ~ 
> /libebook-1.2-20|libedata-book-1.2-26|libebook-contacts-1.2-4|libecal-2.0-1|libedata-cal-2.0-1|libebook-contacts-1.2-3/
>  | .build-depends /libecal1.2-dev|libedata-cal1.2-dev/ | .build-depends 
> /libecal2.0-dev|libedatacal1.2-dev/;
> is_good = .depends ~ 
> /libebook-1.2-20|libedata-book-1.2-26|libebook-contacts-1.2-4|libecal-2.0-1|libedata-cal-2.0-1|libebook-contacts-1.2-3/
>  | .build-depends /libecal1.2-dev|libedata-cal1.2-dev/;
> is_bad = .depends ~ 
> /libebook-1.2-19|libedata-book-1.2-25|libebook-contacts-1.2-2|libecal-1.2-19|libedata-cal-1.2-29|libebook-contacts-1.2-2/
>  | .build-depends /libecal2.0-dev|libedatacal1.2-dev/;

I just ACK'ed the gnome-desktop3 transition, so let's wait until that
migrates. In the mean time, please bump the severity of the FTBFS bug.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#941375: RM: alliance -- RoQA; dead upstream, 5.1.1 rel'd in 2014; python2 only; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#940498: jackson-databind: CVE-2019-14540 CVE-2019-16335

[Markus Koschany]

Control: tags -1 pending

On Mon, 16 Sep 2019 15:14:37 +0200 Salvatore Bonaccorso
 wrote:
> Source: jackson-databind
> Version: 2.9.9.3-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole

[...]

> p.s.: wondering where that will going to end ;-)

Hi,

I also think it is starting to get silly now. I will upload 2.10.0 to
unstable shortly but I suggest to address these kind of issues from now
on only via stable-updates. This can be done two or three times per
year. It is basically just adding new classes to the blacklist. I
believe the whole approach of blacklisting classes is not very
sophisticated.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#941374: RM: vimoutliner -- RoQA; last MU in 2009, last 3 uploads are NMUs; last upstream release in 2014; python2-only; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#934630: transition: octave

[Paul Gevers]

Control: tags -1 confirmed

Hi Sébastien,

On Mon, 12 Aug 2019 17:53:33 +0200 =?utf-8?q?S=C3=A9bastien_Villemot?=
 wrote:
> Please schedule a transition for octave 5.
> 
> Most reverse dependencies have already been updated by the Debian Octave Group
> and should therefore be compatible with the new version. We stand ready to NMU
> other reverse dependencies should the need arise.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#934927: Status update request

[Paul Gevers]

Hi Pirate,

On 28-09-2019 06:40, Pirate Praveen wrote:
> Are we blocked by some other transitions?
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Could you please next time provide more context than only the bug
number. It's annoying to need to look it up if all you need to do is add
"libgit2 transition" somewhere.

That said, are you aware of any progress on the julia front?

Paul

Bug#940453: RM: toxiproxy -- ROM; no longer needed

[Scott Kitterman]

On Sun, 29 Sep 2019 21:35:56 +0200 Paul Gevers  wrote:
> Hi all,
> 
> On Sun, 15 Sep 2019 19:40:11 -0400 Alexandre Viau  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > toxiproxy is no longer needed by any package. It should
> > be removed from the archive.
> > 
> > It used to be here as a dependency for telegraph which never made it to
> > the archive.
> 
> golang-github-shopify-sarama depends on it. Any idea how this has
> slipped through? The removal of toxiproxy can't migrate to testing now.

No idea.  I don't recall having forced this through the warning that there 
were rdpends.  I can't say if DAK failed to detect it or I was asleep at the 
switch.

At this point, someone will need to re-upload it from snapshot.d.o.  Anyone 
that does, feel free to ping me on #debian-ftp and I'll give it a early review 
in New.

Scott K

Bug#940629: fatrace: add support for detecting rename events

[Martin Pitt]

Hello Paul,

Paul Wise [2019-09-18 12:20 +0800]:
> Linux fanotify now supports detecting file renames, it would be nice to
> have support for those (AFAICT there is no support for them yet) and for any 
> other fanotify events that have been added in recent years.

This isn't the first time I get this request, and it has bothered me as well.
Detecting renames and also deletions should be possible with the very new
(Linux 5.1, i. e. 4 months old) FAN_REPORT_FID mode.

I made some initial experiments with this today [1], on kernel 5.3. (Note that
this won't eventually look like this, there needs to be a fallback for older
kernels.) But so far this isn't encouraging -- the results for "normal"
open/close/read/write are much worse. In particular, I get a lot of ESTALE
event fds now that previously resolved to existing files just fine, and also
the pid → /proc/pid/comm resolution is now much less reliable.

Currently this feels like a bad trade-off to make, but I'll investigate this
further.

Martin

[1] https://paste.fedoraproject.org/paste/6IjETdiFcz3E3hrYWilbqA

Bug#936681: gwyddion: Python2 removal in sid/bullseye

[Shayan Doust]

Hello,

Just a notice to those who read this: it seems like with the python2 ->
python3 migration, python-gtk2-dev becomes redundant and should be avoided.

I will try contact upstream to see if this is a possible change to
incorporate into their workflow as any future releases will probably be
big and therefore more time has to be spent re-doing any patchwork.

Kind regards,
Shayan Doust



signature.asc
Description: OpenPGP digital signature

Bug#935042: Patch for avoid phoning home

[marcos]

Hello

The CheckUpdates() function is executed every time an audit is done. It
makes a DNS query and uses the TXT field of the DNS record for  this.
You can check if you have latest version by running "dig -t TXT
lynis-latest-version.cisofy.com" but you  would be "phoning home"
yourself :-).

The package will be removed soon if the bug isn't fixed, so i cc the
pkg-security team asking for sponsorship in case the maintainer is not
available.

Greetings,

Marcos

Description: The CheckUpdates() function is executed every time an audit is done. It makes a DNS query and uses the TXT field of the DNS record for this. This patch cancels this function. You can check if you have latest version by running "dig -t TXT lynis-latest-version.cisofy.com" but you would be "phoning home" yourself :-).  
Author: Marcos Fouces 
Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935042
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/

--- a/include/functions
+++ b/include/functions
@@ -254,29 +254,7 @@
 
 
 CheckUpdates() {
-PROGRAM_LV="00"; DB_MALWARE_LV="00"; DB_FILEPERMS_LV="00"
-if [ ${RUN_UPDATE_CHECK} -eq 1 ]; then
-LYNIS_LV_RECORD="lynis-latest-version.cisofy.com."
-FIND=$(which dig 2> /dev/null | grep -v "no [^ ]* in")
-if [ ! -z "${FIND}" ]; then
-PROGRAM_LV=$(dig +short +time=3 -t txt lynis-latest-version.cisofy.com 2> /dev/null | grep -v "connection timed out" | sed 's/[".]//g' | grep "^[1-9][0-9][0-9]$")
-else
-FIND=$(which host 2> /dev/null | grep -v "no [^ ]* in ")
-if [ ! -z "${FIND}" ]; then
-PROGRAM_LV=$(host -t txt -W 3 lynis-latest-version.cisofy.com 2> /dev/null | grep -v "connection timed out" | awk '{ if ($1=="lynis-latest-version.cisofy.com" && $3=="text") { print $4 }}' | sed 's/"//g' | grep "^[1-9][0-9][0-9]$")
-if [ "${PROGRAM_LV}" = "" ]; then PROGRAM_LV=0; fi
-else
-FIND=$(which drill 2> /dev/null | grep -v "no [^ ]* in ")
-if [ ! -z "${FIND}" ]; then
-PROGRAM_LV=$(drill txt ${LYNIS_LV_RECORD} | awk '{ if ($1=="lynis-latest-version.cisofy.com." && $4=="TXT") { print $5 }}' | tr -d '"' | grep "^[1-9][0-9][0-9]$")
-if [ -z "${PROGRAM_LV}" ]; then PROGRAM_LV=0; fi
-else
-LogText "Result: dig, drill or host not installed, update check skipped"
-UPDATE_CHECK_SKIPPED=1
-fi
-fi
-fi
-fi
+echo "In Debian distro package, check for updates are disabled."
 }
 
 

Bug#933548: transition: gnome-desktop3

[Paul Gevers]

Control: tags -1 confirmed

On Mon, 16 Sep 2019 01:16:36 +0200 Andreas Henriksson 
wrote:
> Control: tags -1 - moreinfo
> 
> Dear release team,
> 
> I've done rebuild tests of reverse dependencies for the gnome-desktop3
> transition and the results are that there's one failure:
> budge-desktop
> 
> (The build logs are temprorarily available from:
> https://fatal.se/tmp/gnome-desktop-3_3.34/build-logs/
> )
> 
> It seems there's a version of budge-desktop prepared in experimental
> that adresses the problem.
> 
> This transition should thus hopefully be in good shape and ready
> to go at any point when the release team have a slot free for it.

Let's get on with this.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#940453: RM: toxiproxy -- ROM; no longer needed

[Paul Gevers]

Hi all,

On Sun, 15 Sep 2019 19:40:11 -0400 Alexandre Viau  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> toxiproxy is no longer needed by any package. It should
> be removed from the archive.
> 
> It used to be here as a dependency for telegraph which never made it to
> the archive.

golang-github-shopify-sarama depends on it. Any idea how this has
slipped through? The removal of toxiproxy can't migrate to testing now.

Paul

Bug#930240: ncbi-blast+ FTCBFS: configures for the build architecture

[Aaron M. Ucko]

Michael Crusoe  writes:

> Shall we apply the incremental patch, or should we wait for your full fix?

Thanks for the reminder!  This report accidentally fell off my radar. :-/
Getting on it now.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#941373: RM: keepnote -- RoQA; last upstream release in 2012, last upload 2013; orphaned; python2-only; depends on outdated pygtk; low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#941372: texlive-extra-utils: A new version of pythontex is available

[Emmanuel Charpentier]

Package: texlive-extra-utils
Version: 2019.20190830-1
Severity: wishlist

Dear Maintainer,

Geoffrey Poore has finalized a new version of pythontex this summer. This
version has been uploaded on CTAN on  Sep 25, 2019.

Among other minor and not-so-minor fixes en enhancements, this version offers
complete support for R, thus offering a sometimes-needed alternative to knitr.

An update of the Debian TeXLive packaging should include this new version. Any
(gues)stimate of the time such an update could be available ?



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 1227 Jan 31  2019 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 3105 Sep 25 07:43 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jul 31 09:21 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 30 03:33 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 30 03:33 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug  5 06:55 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 30 03:33 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 30 03:33 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 Sep 24 08:47 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  2  2018 mktex.cnf
-rw-r--r-- 1 root root 475 Aug  5 06:55 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-extra-utils depends on:
ii  libunicode-linebreak-perl  0.0.20190101-1+b1
ii  python 2.7.16-1
ii  tex-common 6.12
ii  texlive-base   2019.20190830-1
ii  texlive-binaries   2019.20190605.51237-3
ii  texlive-latex-base 2019.20190830-1

Versions of packages texlive-extra-utils recommends:
ii  ghostscript9.27~dfsg-3.1
ii  libfile-homedir-perl   1.004-1
ii  liblog-log4perl-perl   1.49-1
ii  libyaml-tiny-perl  1.73-1
ii  ruby   1:2.5.1
ii  texlive-latex-recommended  2019.20190830-1

Versions of packages texlive-extra-utils suggests:
ii  chktex  1.7.6-3
ii  dvidvi  1.0-8.2+b1
ii  dvipng  1.15-1.1+b1
ii  fragmaster  1.7-8
ii  lacheck 1.26-17
ii  latexdiff   1.3.0-1
ii  latexmk 1:4.65-0.2
ii  purifyeps   1.1-2
pn  xindy   

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.6.1

Versions of packages texlive-extra-utils 

Bug#941371: autorenamer: should recommend gir1.2-gnomedesktop-3.0 for proper thumbnail support

[Sebastian Peters]

Package: autorenamer
Version: 0.5-1
Severity: wishlist

Dear Maintainer,

autorenamer complains about 'Importing GNOME desktop library failed. Thumbnail 
support will be limited.' Indeed there seems to be only a placeholder icons for 
images.

Installation of gir1.2-gnomedesktop-3.0 solves the issue. Please consider to 
add this dependency as 'Recommends' (or 'Suggest').

Best
Sebastian

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

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

Versions of packages autorenamer depends on:
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.58.3-2
ii  gir1.2-gtk-3.03.24.10-1
ii  python3   3.7.3-1

autorenamer recommends no packages.

autorenamer suggests no packages.

-- no debconf information

Bug#941368: savelog prompts when overwriting files that are read only

[Simon Deziel]

Here is a merge request addressing the bug:

https://salsa.debian.org/debian/debianutils/merge_requests/3

Regards,
Simon

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Dmitry Bogatov]

[2019-09-28 08:11] Sean Whitton 
> Hello,
>
> On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote:
>
> >> Candidate language attached. It adds "Also excepted are packages which 
> >> require a
> >> feature of an alternate init system which is not available in SysV-Style
> >> init systems.". Thoughts?
> >
> > Imho, it opens loophole.
> > [...]
>
> Okay, so what we want to express here is the idea that there is an
> exception for a package which uses a feature of systemd, where something
> equivalent cannot be achieved by using a sysvinit script?  Such as
> something to access the systemd dbus interface.
>
> I'm not sure how to express that right now, but I think it can be done.

I believe I proposed wording for this down in this thread.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#941370: hivelytracker FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: hivelytracker
Version: 0+git20180223-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

hivelytracker fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that is using
dh_auto_build. Even then it fails, because the relevant Makefile hard
codes the build architecture pkg-config. Beyond that, the
PKG_CONFIG_PATH setting needs to be removed, because it breaks the
pkg-config cross wrapper. Please consider applying the attached patch.

Helmut
diff --minimal -Nru hivelytracker-0+git20180223/debian/changelog 
hivelytracker-0+git20180223/debian/changelog
--- hivelytracker-0+git20180223/debian/changelog2018-09-04 
14:16:02.0 +0200
+++ hivelytracker-0+git20180223/debian/changelog2019-09-29 
19:57:16.0 +0200
@@ -1,3 +1,13 @@
+hivelytracker (0+git20180223-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable and make the cross
+  wrapper work by removing the PKG_CONFIG_PATH override.
+
+ -- Helmut Grohne   Sun, 29 Sep 2019 19:57:16 +0200
+
 hivelytracker (0+git20180223-3) unstable; urgency=medium
 
   * debian/hivelytracker.desktop: updated.
diff --minimal -Nru hivelytracker-0+git20180223/debian/patches/cross.patch 
hivelytracker-0+git20180223/debian/patches/cross.patch
--- hivelytracker-0+git20180223/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ hivelytracker-0+git20180223/debian/patches/cross.patch  2019-09-29 
19:57:14.0 +0200
@@ -0,0 +1,17 @@
+--- hivelytracker-0+git20180223.orig/sdl/Makefile.linux
 hivelytracker-0+git20180223/sdl/Makefile.linux
+@@ -3,11 +3,12 @@
+ BASEDIR = $(CURDIR)/..
+ 
+ CC = gcc
++PKG_CONFIG ?= pkg-config
+ 
+ CFLAGS = -g -D__SDL_WRAPPER__
+ 
+-CFLAGS += -g $(shell PKG_CONFIG_PATH=/usr/$(BASELIBDIR)/pkgconfig pkg-config 
sdl --cflags) $(shell PKG_CONFIG_PATH=/usr/$(BASELIBDIR)/pkgconfig pkg-config 
gtk+-2.0 --cflags)
+-LFLAGS += -lm -L/usr/$(BASELIBDIR) $(shell 
PKG_CONFIG_PATH=/usr/$(BASELIBDIR)/pkgconfig pkg-config sdl --libs) $(shell 
PKG_CONFIG_PATH=/usr/$(BASELIBDIR)/pkgconfig pkg-config gtk+-2.0 --libs) 
-lSDL_image -lSDL_ttf -lfreetype -lz -lX11
++CFLAGS += -g $(shell $(PKG_CONFIG) sdl --cflags) $(shell $(PKG_CONFIG) 
gtk+-2.0 --cflags)
++LFLAGS += -lm -L/usr/$(BASELIBDIR) $(shell $(PKG_CONFIG) sdl --libs) $(shell 
$(PKG_CONFIG) gtk+-2.0 --libs) -lSDL_image -lSDL_ttf -lfreetype -lz -lX11
+ 
+ 
+ CFLAGS += -I$(BASEDIR) \
diff --minimal -Nru hivelytracker-0+git20180223/debian/patches/series 
hivelytracker-0+git20180223/debian/patches/series
--- hivelytracker-0+git20180223/debian/patches/series   2018-08-12 
18:33:41.0 +0200
+++ hivelytracker-0+git20180223/debian/patches/series   2019-09-29 
19:55:50.0 +0200
@@ -2,3 +2,4 @@
 data-dirs
 font-path
 drop-m3264
+cross.patch
diff --minimal -Nru hivelytracker-0+git20180223/debian/rules 
hivelytracker-0+git20180223/debian/rules
--- hivelytracker-0+git20180223/debian/rules2018-02-25 21:33:37.0 
+0100
+++ hivelytracker-0+git20180223/debian/rules2019-09-29 19:57:16.0 
+0200
@@ -12,7 +12,7 @@
dh $@ --sourcedirectory=sdl
 
 override_dh_auto_build:
-   $(MAKE) -C sdl -f Makefile.linux
+   dh_auto_build -- -f Makefile.linux
 
 override_dh_auto_clean:
@echo no clean target

Bug#941369: mark pyflakes and pyflakes3 Multi-Arch: foreign

[Helmut Grohne]

Package: pyflakes,pyflakes3
Version: 2.1.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:pygobject src:python-apt src:netplan.io

The affected packes fail to satisfy their cross Build-Depends, because
their dependency on pyflakes or pyflakes3 is unsatisfiably. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign or annotated :native. In this case,
the foreign marking is reasonable, because pyflakes is a command line
application that operates on (textual) source files. Given that pyflakes
does not import sources, it should not exhibit architecture-dependent
behaviour even in the presence of python extensions. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru pyflakes-2.1.1/debian/changelog 
pyflakes-2.1.1/debian/changelog
--- pyflakes-2.1.1/debian/changelog 2019-07-16 18:30:30.0 +0200
+++ pyflakes-2.1.1/debian/changelog 2019-09-29 13:43:13.0 +0200
@@ -1,3 +1,10 @@
+pyflakes (2.1.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark pyflakes and pyflakes3 Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 29 Sep 2019 13:43:13 +0200
+
 pyflakes (2.1.1-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru pyflakes-2.1.1/debian/control pyflakes-2.1.1/debian/control
--- pyflakes-2.1.1/debian/control   2019-07-16 18:22:34.0 +0200
+++ pyflakes-2.1.1/debian/control   2019-09-29 13:43:11.0 +0200
@@ -20,6 +20,7 @@
 
 Package: pyflakes
 Architecture: all
+Multi-Arch: foreign
 Depends: python-pyflakes (=${binary:Version}),
  ${misc:Depends},
  ${python:Depends},
@@ -36,6 +37,7 @@
 
 Package: pyflakes3
 Architecture: all
+Multi-Arch: foreign
 Depends: python3-pyflakes (=${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},

Bug#941368: savelog prompts when overwriting files that are read only

[Simon Deziel]

Package: debianutils
Version: 4.9

If savelog is invoked as a *normal user* and asked to create files
that are not writeable (-m 0400), it will prompt during mv:

$ savelog -qm 0400 bar
mv: replace 'bar', overriding mode 0400 (r)?

Bug#941367: RFS: z3 4.8.6-1 -- theorem prover from Microsoft Research

[Fabian Wolff]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: m...@debian.org, locutusofb...@debian.org, sylves...@debian.org, 
lebedev...@gmail.com

Dear mentors,

I am looking for a sponsor for an upload of the z3 package.

The current maintainer, Michael Tautschnig, is apparently not active anymore, 
because
he has not made an upload for this package for several years now, and didn't 
respond
to any of my emails. Because I'd already made several non-maintainer uploads 
for this
package in the past, I decided to add myself as co-maintainer (I have added 
Michael in
the X-Debbugs-CC above just to be sure).

My changes are summarized in the latest changelog entry:

  z3 (4.8.6-1) unstable; urgency=medium

* New upstream release.
* Make watch file more robust (match (z3|Z3) instead of just z3).
* Add myself to Uploaders in debian/control.
* Drop the libz3-cil package (not all build dependencies are available
  in Debian; also see the discussion in #886590).
* Update/refresh patches.
* Drop python-z3 package and replace it with python3-z3
  (Closes: #886590, #938876).
* Enable autopkgtest package testing and add several superficial and
  non-superficial test cases.
* Add -fPIC to DEB_CXXFLAGS_MAINT_APPEND in an attempt to fix #940266.
* Try to make the build more reproducible.

   -- Fabian Wolff   Sun, 29 Sep 2019 18:21:54 +0200

In particular, I've introduced the new python3-z3 package, so whoever decides to
sponsor this upload, please remember to also upload binaries, because the 
package has
to go through the NEW queue.

My changes are on Salsa (I'll push to the actual repository once somebody has 
given
me sufficient ("Maintainer") permissions to do so), and also on Mentors:

  https://salsa.debian.org/wolff-guest/z3
  https://mentors.debian.net/package/z3

Thanks for your help!

Best regards,
Fabian

Bug#941366: If I run vim, but only vim.tiny is present, please don't say "command not found"

[Jason Spiro]

Package:  vim-tiny
Version:  2:8.1.0875-5

## The problem

It was the first week of the semester, and I was using a machine which
wasn't yet able to connect to my school's wireless network.  (It's
tricky to connect a new Linux machine to my school's wireless network,
and I hadn't yet connected.)

I was in class, and I was in a hurry to launch a text editor.  I tried
to launch vim, but I got an error message stating that it wasn't
installed.  So I launched nano instead, and suffered with an
unfamiliar editor (nano) for the entire three-hour lecture.

Weeks later, I realize that vim _had_ been installed.  You see,
vim-tiny had been installed on the machine all along.  It provides a
'vi' command, but no 'vim' command.

## My suggestion

Here is a suggestion which will help to prevent other people from
falling into similar situations in the future.

vim-tiny should continue to call its main binary 'vi', as usual.

If you try to launch 'vim' or 'gvim', vim-tiny should not launch Vim.
But it should display the following message, which will notify the
user that vim.tiny is already installed and available:

You tried to launch vim, but only vim.tiny is installed.
Please install vim-gtk3 or any other full Vim package.
If you have no Internet access, you may use vim.tiny for now; but
note that it's very minimal.  Please install a full Vim package when
you have a chance.

## Conclusion

Thanks in advance,
--Jason

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Yves-Alexis Perez]

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

Hi,

libimobiledevice in Buster has some issue with devices running iOS 13+.
Backup using idevicebackup2 never finishes, apparently because of some
behavior change in newer iOS version.

With coordination with upstream
(https://github.com/libimobiledevice/libimobiledevice/issues/848) a
small fix was identified.

Would it be possible to upload a fixed package to Buster at some point?
The fix is not yet in sid (a previous package is waiting in NEW, I'll
upload a package fix soon) so it's more a pre-approval.

The debdiff is attached for review.

Thanks in advance,
-- 
Yves-Alexis

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Differences in libimobiledevice between 1.2.1~git20181030.92c5462-1 and 
1.2.1~git20181030.92c5462-2
diff -Nru libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 
libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog
--- libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 2019-01-08 
16:24:55.0 +0100
+++ libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 2019-09-29 
17:14:37.0 +0200
@@ -1,3 +1,10 @@
+libimobiledevice (1.2.1~git20181030.92c5462-2) UNRELEASED; urgency=medium
+
+  * d/patches: properly handle partial SSL writes
+  * d/gbp.conf: follow buster branch
+
+ -- Yves-Alexis Perez   Sun, 29 Sep 2019 17:14:37 +0200
+
 libimobiledevice (1.2.1~git20181030.92c5462-1) unstable; urgency=medium
 
   * New upstream snapshot
diff -Nru libimobiledevice-1.2.1~git20181030.92c5462/debian/gbp.conf 
libimobiledevice-1.2.1~git20181030.92c5462/debian/gbp.conf
--- libimobiledevice-1.2.1~git20181030.92c5462/debian/gbp.conf  2019-01-08 
16:24:55.0 +0100
+++ libimobiledevice-1.2.1~git20181030.92c5462/debian/gbp.conf  2019-09-29 
17:14:37.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
 upstream-branch = upstream/master
 pristine-tar = True
 
diff -Nru 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0003-idevice-properly-handle-partial-SSL-writes.patch
 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0003-idevice-properly-handle-partial-SSL-writes.patch
--- 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0003-idevice-properly-handle-partial-SSL-writes.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0003-idevice-properly-handle-partial-SSL-writes.patch
 2019-09-29 17:14:37.0 +0200
@@ -0,0 +1,46 @@
+From: Nikias Bassen 
+Date: Sun, 29 Sep 2019 17:10:46 +0200
+Subject: idevice: properly handle partial SSL writes
+
+---
+ src/idevice.c | 23 +++
+ 1 file changed, 15 insertions(+), 8 deletions(-)
+
+diff --git a/src/idevice.c b/src/idevice.c
+index cb9bb5c..dd47e67 100644
+--- a/src/idevice.c
 b/src/idevice.c
+@@ -366,18 +366,25 @@ LIBIMOBILEDEVICE_API idevice_error_t 
idevice_connection_send(idevice_connection_
+   }
+ 
+   if (connection->ssl_data) {
++  uint32_t sent = 0;
++  while (sent < len) {
+ #ifdef HAVE_OPENSSL
+-  int sent = SSL_write(connection->ssl_data->session, (const 
void*)data, (int)len);
+-  debug_info("SSL_write %d, sent %d", len, sent);
++  int s = SSL_write(connection->ssl_data->session, (const 
void*)(data+sent), (int)(len-sent));
+ #else
+-  ssize_t sent = 
gnutls_record_send(connection->ssl_data->session, (void*)data, (size_t)len);
++  ssize_t s = 
gnutls_record_send(connection->ssl_data->session, (void*)(data+sent), 
(size_t)(len-sent));
+ #endif
+-  if ((uint32_t)sent == (uint32_t)len) {
+-  *sent_bytes = sent;
+-  return IDEVICE_E_SUCCESS;
++  if (s < 0) {
++  break;
++  }
++  sent += s;
+   }
+-  *sent_bytes = 0;
+-  return IDEVICE_E_SSL_ERROR;
++  debug_info("SSL_write %d, sent %d", len, sent);
++  if (sent < len) {
++  *sent_bytes = 0;
++  return IDEVICE_E_SSL_ERROR;
++  }
++  *sent_bytes = sent;
++  return IDEVICE_E_SUCCESS;
+   }
+   return internal_connection_send(connection, data, len, sent_bytes);
+ }
diff -Nru libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/series 
libimobiledevice-1.2.1~git20181030.92c5462/debian

Bug#938328: rabbyt: Python2 removal in sid/bullseye

[Reiner Herrmann]

A fork of rabbyt that support Python 3 is available here:
 https://github.com/Ryex/Rabbyt


signature.asc
Description: PGP signature

Bug#941364: ITS: tstools

[Boyuan Yang]

Package: tstools
Severity: important
X-Debbugs-CC: lgra...@gmail.com

Dear tstools maintainer,

I found that the package you maintain in Debian (
https://tracker.debian.org/pkg/tstools) is not in good shape and has some
release-critical (RC) bugs. Given that this package saw no updates in the last
10 years, I am filing an ITS (Intent to Salvage) bug according to §5.12 in
Debian's Developers Reference[1].

Please let me know if you are going to continue with package maintenance for
tstools. If no response is received with in 21 days (by Oct. 20, 2019), I will
proceed and upload a non-maintainer upload (NMU) to DELAYED/7 and fix bugs
lying in tstools, which would also have the package maintainership
transferred.

Thank you very much and looking forward to your reply.

Best Regards,
Boyuan Yang


[1] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging


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

Bug#927104: criu: Please update to python3

[Salvatore Bonaccorso]

Hi Scott,

On Sat, Aug 24, 2019 at 10:28:34PM -0400, Scott Kitterman wrote:
> On Saturday, August 24, 2019 5:22:11 AM EDT Salvatore Bonaccorso wrote:
> > Contorl: tags -1 + help
> > 
> > Hi
> > 
> > At the moment I'm somehow a bit time limited to work on src:criu, but
> > not completely lost track. But if someone wants to help here and on
> > the FTBFS bug then be my guest, will happily merge proposed changes.
> > 
> > In any case criu should not block the python2.7 removal, so feel free
> > to request removal from unstable at any point it is needed for you.
> > 
> > I plan at the moment to keep it anyway updated in experimental, as it
> > is still before uploading a new version to unstable at all.
> 
> I took a brief look at this.  I did not make progress on the FTBFS, so I'm 
> unable to test anything, but I can make some suggestions on the Python bits.
> 
> At the very least, you'll need the following:
> 
> In debian/rules chang with python2 to python3
> 
> Add PYTHON="python3" to the install override
> 
> In debian control:
> 
> Build-depend on python3-all instead of python-all
> 
> Drop the depends on python-future and python-ipaddr
> Change python-protobuf to python3-protobuf
> 
> More generally, there's a missing build-dep on pkg-config.
> 
> It looks like upstream supports python3, so that's at least a start.

I have currently the attached on top of the changes in the Debian
packaging repository. Though I neeed to check new failures to work
with crit on dumped data, which I have not with the previous version.

Regards,
Salvatore
>From 6b80290a07c85524c05b7c7b070c77290da4913d Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Sun, 29 Sep 2019 16:56:47 +0200
Subject: [PATCH] Update to use python3

Build-Depends on python3-all instead of python-all.

Drop Depends on python-future, python-ipaddr and change Depends on
python-protobuf to python3-protobuf.

Replace ${python:Depends} substitution with ${python3:Depends}.

Pass --with python3 to dh in debian/rules and pass PYTHON="python3" in
the dh_auto_install override.

Closes: #927104
Thanks: Scott Kitterman
---
 debian/control | 8 +++-
 debian/rules   | 4 ++--
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index c07659a9bdc4..0c85ee527fd0 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends:
  pkg-config,
  protobuf-c-compiler,
  protobuf-compiler,
- python-all (>= 2.6.6-3~),
+ python3-all,
  xmlto
 Standards-Version: 4.3.0
 Homepage: https://www.criu.org/
@@ -25,11 +25,9 @@ Rules-Requires-Root: no
 Package: criu
 Architecture: amd64 arm64 armhf ppc64el s390x
 Depends:
- python-future,
- python-ipaddr,
- python-protobuf,
+ python3-protobuf,
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends}
 Recommends: iproute2 | iproute
 Description: checkpoint and restore in userspace
diff --git a/debian/rules b/debian/rules
index d5a74b47adbe..a5eb30cdfb5a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,10 +6,10 @@ PACKAGE = $(firstword $(shell dh_listpackages))
 TMP = $(CURDIR)/debian/$(PACKAGE)
 
 %:
-	dh ${@} --with python2
+	dh ${@} --with python3
 
 override_dh_auto_install:
-	dh_auto_install -- DESTDIR="$(CURDIR)/debian/criu" PREFIX="/usr" LIBEXECDIR="/usr/lib"
+	dh_auto_install -- DESTDIR="$(CURDIR)/debian/criu" PREFIX="/usr" LIBEXECDIR="/usr/lib" PYTHON="python3"
 
 override_dh_auto_test:
 	# disabled: doesn't work yet
-- 
2.23.0

Bug#940866: nmu: ga_5.7-4

[Drew Parsons]

On 2019-09-29 21:17, Paul Gevers wrote:

Hi Drew,

On 21-09-2019 06:23, Drew Parsons wrote:

armci-mpi has been updated, so ga should be rebuilt to match
(nwchem binNMU will follow after this)

nmu ga_5.7-4 . ANY . unstable . -m "rebuild against armci-mpi 
0.0~git20190412.643ea1a"


Done, but does this actually mean that ga is statically linked against
armci-mpi? If not, can you explain the situation (I am trying to 
learn).



armci-mpi is indeed statically linked.  I wasn't involved with the full 
setup of the package so I can't provide the full rationale behind it.  
Sometimes in scientific computing, especially in HPC, static linking is 
used to ensure that results of a computation are reproducible precisely 
the same way they were to match published results, bugs and all.  Buggy 
results need to be reproducible.  Perhaps that's why. Perhaps we should 
update it to provide and link against shared libraries. Upstream 
configure does have the option --enable-shared.


cc:ing Michael Banck for more comment.

Drew

Bug#941354: [Pkg-javascript-devel] Bug#941354: proposed fix

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 29 6:13:21 PM IST, Paolo Greppi  
wrote:
>Should I upload this to unstable ?

Yes
>Will it automatically roll to stable ?

No, you will have to build it on buster and upload to buster-security after 
security team approves the debdiff.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#941198: initscripts: packages should ship systemd units

[Russ Allbery]

Bill Allombert  writes:
> On Sat, Sep 28, 2019 at 06:02:52PM -0700, Russ Allbery wrote:

>> I agree.  This seems entirely reasonable to me.  Both the behavior and
>> the inherent documentation are better with unit files, and systemd is
>> the default init system so that's an advantage for a lot of our users.

>> That said, if anyone does object to this, please do speak up and
>> explain why this would be a problem.

> There is a little technical detail that should be handled though:
> User might have made change to /etc/default/xxx that is sourced
> by /etc/init.d/xxx.

> Such change must not be ignored by the unit files, because we require
> configuration to be preserved across upgrade.

Yes, good call.  This is partly an unrelated issue in that anyone adding a
unit file in the past also should have thought about this problem and
tackled it in some way, but we're likely to make the problem more visible
by encouraging a bunch of additional packages to add unit files.

Do you have an idea for wording to use for this?

-- 
Russ Allbery (r...@debian.org)   

Bug#933192: Please try with 0.30

[Jelmer Vernooij]

lintian-brush 0.30 (now in unstable) should report the files it
thinks have uncommitted changes when running with --verbose. Could you
try that?

Does the tree perhaps contain submodules?

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#941363: [filezilla] Filezilla doesn't start, returns an undefined symbol error

[rastersoft]

Package: filezilla
Version: 3.39.0-2
Severity: grave

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

When trying to launch it, nothing happens. When launching from a command 
line, it returns:


    filezilla: symbol lookup error: filezilla: undefined symbol: 
_ZTIN2fz6threadE


Tried to uninstall (and purge) the package and reinstall, but still fails.

Tried the binary (version 3.44.2) downloaded directly from Filezilla 
home page (dinamically linked, and links against the libfilezilla file 
from debian itself) and works fine.



--- System information. ---
Architecture:
Kernel: Linux 4.19.0-1-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 suldr www.bchemnet.com
500 stable repo.skype.com
500 stable linux.teamviewer.com
500 stable dl.google.com

--- Package information. ---
Depends (Version) | Installed
===-+-
filezilla-common (= 3.39.0-2) | 3.39.0-2
libatk1.0-0 (>= 1.12.4) | 2.34.0-1
libc6 (>= 2.28) |
libcairo2 (>= 1.2.4) |
libdbus-1-3 (>= 1.9.14) |
libfilezilla0 (>= 0.15.1) |
libfontconfig1 (>= 2.12.6) |
libfreetype6 (>= 2.2.1) |
libgcc1 (>= 1:3.0) |
libgdk-pixbuf2.0-0 (>= 2.22.0) |
libglib2.0-0 (>= 2.16.0) |
libgnutls30 (>= 3.6.5) |
libgtk2.0-0 (>= 2.10.0) |
libhogweed4 |
libnettle6 |
libpango-1.0-0 (>= 1.14.0) |
libpangocairo-1.0-0 (>= 1.14.0) |
libpangoft2-1.0-0 (>= 1.14.0) |
libpugixml1v5 (>= 1.7) |
libsqlite3-0 (>= 3.5.9) |
libstdc++6 (>= 5.2) |
libwxbase3.0-0v5 (>= 3.0.4+dfsg) |
libwxgtk3.0-0v5 (>= 3.0.4+dfsg) |


Recommends (Version) | Installed
=-+-===
xdg-utils | 1.1.3-1


Package's Suggests field is empty.

--
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[David Steele]

On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton  wrote:
>
> Hello,
>
> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:
>
> > Reasonable. Then let's drop part about Depends:
> >
> >   [ ... All packages with daemons must provide init.d scripts ...],
> >   unless software is only usable, by upstream's design, when
> >   pid1 is provided by some other init system.
>
> I think this would work.  What do you think, David?

I don't know. It provides more clarity the original Policy question, but raises
a technical one I don't know the answer to. For my special case, is it
practical to use systemd (via D-Bus) to manage system daemon
start/stop when it is
not pid1? If yes, things may have gotten worse (I'm responsible for getting this
all to work correctly?). In that case I would prefer a statement discouraging
systemd-specific features.

Bug#941354: proposed fix

[Salvatore Bonaccorso]

On Sun, Sep 29, 2019 at 02:43:21PM +0200, Paolo Greppi wrote:
> I have imported the upstream patch in a new version 1.13.0-3:
> https://salsa.debian.org/js-team/node-yarnpkg/commit/6808cd918e8c12182e14666c715bb1d372d82449/pipelines
> 
> I have checked that it now uses https even if http links are present in 
> yarn.lock as follows:
> 
> mkdir /tmp/qw
> cd /tmp/qw
> yarnpkg add string-width
> rm -rf node_modules/
> sed -i 's/https:/http:/g' yarn.lock
> yarnpkg cache clean strip-ansi
> yarnpkg cache clean string-width
> yarnpkg cache clean ansi-regex
> yarnpkg cache clean emoji-regex
> yarnpkg cache clean is-fullwidth-code-point
> yarnpkg cache clean strip-ansi
> 
> strace -s 256 yarnpkg install &> q
> ping registry.yarnpkg.com # it's 104.16.22.35
> grep 104.16.22.35 q
> 
> I get this:
> connect(21, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
> corso)
> connect(22, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
> corso)
> connect(26, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
> corso)
> connect(27, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
> corso)
> connect(28, {sa_family=AF_INET, sin_port=htons(443), 
> sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
> corso)
> 
> Should I upload this to unstable ?

Yes, either that or even uploading to the new upstream version fixing
the issue, both will work here as bullseye is a long way away.

> Will it automatically roll to stable ?

No. But we need to decice if the update should go out via a DSA or if
releasing it in a point release is enough.

Regards,
Salvatore

Bug#941198: initscripts: packages should ship systemd units

[Josh Triplett]

On Sun, 29 Sep 2019 12:03:11 +0200 Bill Allombert  wrote:
> On Sat, Sep 28, 2019 at 06:02:52PM -0700, Russ Allbery wrote:
> > Sean Whitton  writes:
> > 
> > > I don't currently have any reason to doubt we have a project consensus
> > > that systemd unit files should be included in packages in addition to
> > > sysvinit scripts, so I hope we can make this change.
> > 
> > I agree.  This seems entirely reasonable to me.  Both the behavior and the
> > inherent documentation are better with unit files, and systemd is the
> > default init system so that's an advantage for a lot of our users.
> > 
> > That said, if anyone does object to this, please do speak up and explain
> > why this would be a problem.
> 
> There is a little technical detail that should be handled though:
> User might have made change to /etc/default/xxx that is sourced
> by /etc/init.d/xxx.
> 
> Such change must not be ignored by the unit files, because we require
> configuration to be preserved across upgrade.

I've seen multiple packages handle this through maintainer scripts that
migrate (non-default) settings from /etc/default to a systemd drop-in or
similar configuration file.

Bug#930268: forwarded

[Bastien ROUCARIES]

control: forwarded -1 https://github.com/microsoft/TypeScript/issues/33661

Bug#897081: wmfrog: Does not update weather regularly

[Jeremy Sowden]

On Sat, 28 Apr 2018, at 07:40:39 +0300, Yavor Doganov wrote:
> The file LBWN_dat gets updated every 5 minutes (as expected) but LBWN
> was updated only once and it seems the app is getting the data from
> there.  FWIW, the wmweather package is working properly with the same
> station (updating every 30 minutes).

Wmfrog downloads the raw observations and attempts to decode them.  It
only updates LBWN if it does so succesfully.  Wmweather, on the other
hand, downloads the already decoded observations, which are also
available.  My guess is that wmfrog's decoder can't parse the raw
observations under certain circumstances.  I'll do some debugging and
see if I can reproduce the problem.

J.


signature.asc
Description: PGP signature

Bug#897081: wmfrog: Does not update weather regularly

[Jeremy Sowden]

On 2019-09-29, at 14:35:05 +0100, Jeremy Sowden wrote:
> On Sat, 28 Apr 2018, at 07:40:39 +0300, Yavor Doganov wrote:
> > The file LBWN_dat gets updated every 5 minutes (as expected) but
> > LBWN was updated only once and it seems the app is getting the data
> > from there.  FWIW, the wmweather package is working properly with
> > the same station (updating every 30 minutes).
>
> Wmfrog downloads the raw observations and attempts to decode them.  It
> only updates LBWN if it does so succesfully.  Wmweather, on the other
> hand, downloads the already decoded observations, which are also
> available.  My guess is that wmfrog's decoder can't parse the raw
> observations under certain circumstances.  I'll do some debugging and
> see if I can reproduce the problem.

That didn't take long.

The current raw observations for LBWN are:

  2019/09/29 13:30
  LBWN 291330Z 10011KT CAVOK 25/13 Q1013 NOSIG

wmfrog complains about invalid data and doesn't save them.

The current decoded observations are:

  Varna, Bulgaria (LBWN) 43-12N 027-55E 43M
  Sep 29, 2019 - 09:30 AM EDT / 2019.09.29 1330 UTC
  Wind: from the E (100 degrees) at 13 MPH (11 KT):0
  Visibility: greater than 7 mile(s):0
  Temperature: 77 F (25 C)
  Dew Point: 55 F (13 C)
  Relative Humidity: 47%
  Pressure (altimeter): 29.91 in. Hg (1013 hPa)
  ob: LBWN 291330Z 10011KT CAVOK 25/13 Q1013 NOSIG
  cycle: 13

wmweather displays them.

J.


signature.asc
Description: PGP signature

Bug#941362: openimageio: FTBFS on armel and mipsel with openexr 2.3.0-6

[Paul Gevers]

Source: openimageio
Version: 2.0.10~dfsg0-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

Your package is part of the openexr transition, but it fails to build on armel
and mipsel.

Paul

Tail of log for openimageio on armel:

[ 77%] Building CXX object 
src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/include/OpenImageIO/pugixml.cpp.o
cd "/<>/build/src/libOpenImageIO" && /usr/bin/c++  
-DEMBED_PLUGINS=1 -DOpenImageIO_EXPORTS -DUSE_BOOST_ASIO=1 -DUSE_DCMTK=1 
-DUSE_FFMPEG -DUSE_FREETYPE -DUSE_GIF -DUSE_LIBRAW=1 -DUSE_OCIO=1 -DUSE_OPENCV 
-DUSE_OPENJPEG -DUSE_OPENVDB=1 -DUSE_STD_REGEX -DUSE_TBB=1 -DUSE_WEBP=1 
-D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
-I"/<>/build/include" -I"/<>/src/include" 
-I/usr/include/arm-linux-gnueabi -I/usr/include/OpenEXR 
-I/usr/include/openjpeg-2.3 -I/usr/include/freetype2  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   -Wall 
-fno-math-errno -Wno-unused-local-typedefs -Wno-unused-result -Wno-aligned-new 
-Wno-noexcept-type -std=c++11 -UUSE_FIELD3D -o 
CMakeFiles/OpenImageIO.dir/__/include/OpenImageIO/pugixml.cpp.o -c 
"/<>/src/include/OpenImageIO/pugixml.cpp"
[ 77%] Linking CXX shared library libOpenImageIO.so
cd "/<>/build/src/libOpenImageIO" && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/OpenImageIO.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -latomic -shared 
-Wl,-soname,libOpenImageIO.so.2.0 -o libOpenImageIO.so.2.0.10 
CMakeFiles/OpenImageIO.dir/imagebufalgo.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_pixelmath.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_channels.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_compare.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_copy.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_deep.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_draw.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_addsub.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_muldiv.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_mad.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_orient.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_xform.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_yee.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebufalgo_opencv.cpp.o 
CMakeFiles/OpenImageIO.dir/deepdata.cpp.o CMakeFiles/OpenImageIO.dir/exif.cpp.o 
CMakeFiles/OpenImageIO.dir/exif-canon.cpp.o 
CMakeFiles/OpenImageIO.dir/formatspec.cpp.o 
CMakeFiles/OpenImageIO.dir/imagebuf.cpp.o 
CMakeFiles/OpenImageIO.dir/imageinput.cpp.o 
CMakeFiles/OpenImageIO.dir/imageio.cpp.o 
CMakeFiles/OpenImageIO.dir/imageioplugin.cpp.o 
CMakeFiles/OpenImageIO.dir/imageoutput.cpp.o 
CMakeFiles/OpenImageIO.dir/iptc.cpp.o CMakeFiles/OpenImageIO.dir/xmp.cpp.o 
CMakeFiles/OpenImageIO.dir/color_ocio.cpp.o 
CMakeFiles/OpenImageIO.dir/maketexture.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/argparse.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/benchmark.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/errorhandler.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/filesystem.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/farmhash.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/filter.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/hashes.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/paramlist.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/plugin.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/SHA1.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/strutil.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/sysutil.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/thread.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/timer.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/typedesc.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/ustring.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libutil/xxhash.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libtexture/texturesys.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libtexture/texture3d.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libtexture/environment.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libtexture/texoptions.cpp.o 
CMakeFiles/OpenImageIO.dir/__/libtexture/imagecache.cpp.o 
CMakeFiles/OpenImageIO.dir/__/bmp.imageio/bmpinput.cpp.o 
CMakeFiles/OpenImageIO.dir/__/bmp.imageio/bmpoutput.cpp.o 
CMakeFiles/OpenImageIO.dir/__/bmp.imageio/bmp_pvt.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/cineoninput.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/Cineon.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/OutStream.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/Codec.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/Reader.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/Writer.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/CineonHeader.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/ElementReadStream.cpp.o 
CMakeFiles/OpenImageIO.dir/__/cineon.imageio/libcineon/InStream.cpp.o 
CMa

Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

[Raphael Hertzog]

Hi,

On Fri, 27 Sep 2019, Emmanuel Arias wrote:
> I've just push to salsa the last changes.
> I will need sponsorship to upload it.

I took care of it. But I reverted the removal of python-impacket for
now, it still has reverse dependencies in Debian (and even more in Kali).

I had to cleanup a few things too, there was some upstream doc installed
in a wrong directory (/usr/share/doc/impacket). The changelog was
mishandled, the UNRELEASED entry for 0.9.19 should have been merged with
the 0.9.20.

And I had to rename debian/{install,links,examples} to debian/python3-impacket.*
but that's because I restored python-impacket. But in general, I find it
better to be explicit about the target package so I tend to avoid the
former names.

You had already pushed a tag, in general it's best when the uploader
pushes the tag so that if he has something to correct, he can do it.
Thus I dropped your tag and you will have to drop it on your side if you
want to get the correct one.

Cheers,

> El jue., 26 de sep. de 2019 a la(s) 17:02, Sophie Brun (
> sop...@offensive-security.com) escribió:
> 
> > Hi Emmanuel,
> >
> > ldapdomaindump is not in Debian but I packaged it for Kali last year.
> > The repo is here:
> > https://gitlab.com/kalilinux/packages/python-ldapdomaindump
> > I don't remember if the package is totally compliant with the Debian
> > policy but you can reuse it and improve it for Debian.
> >
> > For impacket: I build the package with the Kali package
> > python3-ldapdomaindump: no tests are really run.
> > I think we can just override dh_auto_test for the moment.
> >
> > I push few changes including a patch to avoid the installation of the
> > examples/*py as scripts in usr/bin/
> > There were not in usr/bin in python-impacket and I think it's better to
> > not have all these scripts in /usr/bin (but it's only my personal opinion).
> >
> > Cheers,
> >
> > Sophie
> >
> >
> > Le 26/09/2019 à 17:06, Emmanuel Arias a écrit :
> > > Hi Sophie, take care that I push some changes to salsa.
> > >
> > > the test are failing because |ldapdomaindump is not in debian (that is
> > correct?) I will package |ldapdomaindump.||
> > > ||
> > > ||
> > > ||So I think that the best solution is patch the tests to skipped it and
> > in  new version (when |ldapdomaindump) is in|||
> > > |||debian create a new version|||
> > > |||
> > > |||
> > > |||any suggestion?|||
> > > |||
> > > |||
> > > Cheers,
> > > Arias Emmanuel
> > > @eamanu
> > > http://eamanu.com
> > >
> > >
> > > El jue., 26 de sep. de 2019 a la(s) 11:03, Sophie Brun (
> > sop...@offensive-security.com )
> > escribió:
> > >
> > > Hello,
> > >
> > > Le 26/09/2019 à 15:18, Emmanuel Arias a écrit :
> > > > I will update the package.
> > >
> > > I started to update the package (I need it for the reverse depends
> > in pkg-security team)
> > >
> > > Can I push my changes on the git repo or maybe you prefer to update
> > everything yourself?
> > >
> > > Cheers,
> > > Sophie
> > >
> >

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#941361: Can not detect external monitor which is connected to hybrid graphics

[gulfstream]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20190815-1
Severity: grave

Hello, my laptop is Thinkpad P1 which has hybrid graphics. The one is Intel 
graphic card, the other is Nvidia P2000. It can not detect any external monitor 
which
connect to the Thinkpad P1's HDMI port.

How can I use the external monitor with my laptop?


Best regards,
Gulfstream



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

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.

Bug#941128: xorg-server FTBFS

[Sven Joachim]

Control: found -1 2:1.19.1-1
Control: tags -1 bullseye sid

On 2019-09-28 19:06 +, Niels Thykier wrote:

> Control: reassign -1 xorg-server
> Control: retitle -1 xorg-server: build target must depend on build-*
> Control: tags -1 ftbfs
>
> Timo Aaltonen:
>> Package: debhelper
>> Severity: important
>>
>> Hi, debhelper 12.4 was fine but the current one broke xorg-server build,
>> build-indep isn't run at all. With the old version it was run right in
>> the beginning:
>>
>> dh build --with quilt,autoreconf --parallel
>>debian/rules build-indep
>> make[1]: Entering directory '/<>'
>> mkdir -p build-source
>> tar \
>> --owner=0 --group=0 \
>> --transform 's,^,xorg-server/,' \
>> --exclude=debian \
>> --exclude=autom4te.cache \
>> -cf - * | xz > build-source/xorg-server.tar.xz
>> tar: build-source/xorg-server.tar.xz: file changed as we read it
>>> build-source-stamp
>> dh build-indep --with quilt,autoreconf --parallel
>>dh_quilt_patch -i -O--parallel
>> Applying patch 001_fedora_extramodes.patch
>> patching file hw/xfree86/common/extramodes
>> ...
>>
>> but now it's skipped:
>>
>> dh build --with quilt,autoreconf --parallel
>>dh_quilt_patch -O--parallel
>> Applying patch 001_fedora_extramodes.patch
>> patching file hw/xfree86/common/extramodes
>> ...
>>
> This problem is fundamentally caused by xorg-server's "build" target not
> invoking build-arch and build-indep (eventually).  The xorg-server
> package is assumed to invoke all relevant build steps as a part of the
> build target itself but it fails to do the build-arch and build-indep
> steps as a part of its build target.

It seem this has been present since xorg-server's rules file was
switched to dh, but it only has become serious recently.

I had a look how to fix that, here is what I tried.

Naive approach 1:

--8<---cut here---start->8---
diff --git a/debian/rules b/debian/rules
index 7365fed6c..c5d5e5e03 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,8 +34,8 @@ override_dh_auto_build:
 override_dh_auto_test:
dh_auto_test -- -j1 VERBOSE=1

-build: abibumpcheck
-build-indep: build-source-stamp
+build build-arch: abibumpcheck
+build build-indep: build-source-stamp

 override_dh_auto_install:
dh_auto_install --builddirectory=debian/build/main \
--8<---cut here---end--->8---

Result was that make processed the build-source-stamp target first
before running dh_quilt_patch and dh_autoreonf.  This is bad, because
xorg-server-source is supposed to contain the patched and autoreconfed
source.

Naive approach 2:

--8<---cut here---start->8---
diff --git a/debian/rules b/debian/rules
index 7365fed6c..cbdd15c31 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,8 +34,9 @@ override_dh_auto_build:
 override_dh_auto_test:
dh_auto_test -- -j1 VERBOSE=1

-build: abibumpcheck
+build-arch: abibumpcheck
 build-indep: build-source-stamp
+build: build-arch build-indep

 override_dh_auto_install:
dh_auto_install --builddirectory=debian/build/main \
--8<---cut here---end--->8---

This seems to work, but now a full (arch+indep) build configures and
builds the source tree twice, which wastes quite a bit of time.

In the end I decided to remove the build and build-indep targets
altogether[1], which does the trick for me (tested full, arch-only and
indep-only builds).

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/c119638422dbb051d6f575e12df353b2cc3a0f44

Bug#941360: fwupd: Failed to activate service: timed out

[definetti]

Package: fwupd
Version: 1.3.2-1
Severity: important

Dear Maintainer,

after updating to 1.3.2-1 the fwupd service fails to run. I think this depends
on the permissions on the /var/cache/fwupd folder, which is a link to
/var/cache/private/fwupd.


● fwupd.service - Firmware update daemon
   Loaded: loaded (/lib/systemd/system/fwupd.service; static; vendor preset:
enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-29 15:15:51 CEST; 24s
ago
 Docs: https://fwupd.org/
  Process: 16141 ExecStart=/usr/lib/fwupd/fwupd (code=exited,
status=239/CACHE_DIRECTORY)
 Main PID: 16141 (code=exited, status=239/CACHE_DIRECTORY)

running fwupd with superuser permissions results in no error



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

Versions of packages fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.2-1
ii  libgcab-1.0-0  1.2-5
ii  libglib2.0-0   2.61.2-2
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.1-2
ii  libsqlite3-0   3.29.0-2
ii  libtss2-esys0  2.1.0-4+b1
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt  0.8-4
pn  fwupd-signed  
ii  python3   3.7.3-1

fwupd suggests no packages.

-- no debconf information

Bug#941349: [kdeconnect]

[Ximo Baldó i Soriano]

Package: kdeconnect
Version: 1.3.3-2

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

Sorry for bad writting... and incomplete command paste. Correct command on 
console is:

$ kdeconnect-cli --share plano-lavila.pdf -d $zapatofono
Sent /http://plano-lavila.pdf/[1]

As I've said, it sends everything as url link as I said before.

--- System information. ---
Architecture: 
Kernel:   Linux 5.2.0-3-amd64

Debian Release: bullseye/sid
  950 unstablewww.deb-multimedia.org 
  900 unstable-debug  deb.debian.org 
  900 unstableftp.debian.org 
  800 experimentalftp.debian.org 
  500 stable  people.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==
-+-==
kde-cli-tools  | 4:5.14.5-1
libqca-qt5-2-plugins   | 2.2.1-2
plasma-framework   | 5.62.0-1
qml-module-qtquick-controls| 5.11.3-2
qml-module-qtquick-controls2   | 
5.11.3+dfsg-2
qml-module-qtquick-layouts | 5.11.3-4
qml-module-qtquick2| 5.11.3-4
sshfs  | 
2.10+repack-2+b1
kio| 5.62.1-1
libc6(>= 2.14) | 
libfakekey0   (>= 0.1) | 
libkf5configcore5  (>= 4.97.0) | 
libkf5configwidgets5   (>= 4.96.0) | 
libkf5coreaddons5   (>= 5.2.0) | 
libkf5dbusaddons5  (>= 4.97.0) | 
libkf5i18n5(>= 4.97.0) | 
libkf5iconthemes5   (>= 5.0.0) | 
libkf5kcmutils5  (>= 5.8.0+git20150316.0112+15.04) | 
libkf5kiocore5 (>= 5.3.0+git20141016.0314) | 
libkf5kiofilewidgets5  (>= 4.96.0) | 
libkf5kiowidgets5  (>= 4.96.0) | 
libkf5notifications5 (>= 5.8.0+git20150317.0114+15.04) | 
libkf5service-bin  | 
libkf5service5  (>= 5.2.0+git20140930) | 
libkf5waylandclient5  (>= 4:5.4.0) | 
libkf5widgetsaddons5   (>= 4.96.0) | 
libqca-qt5-2   (>= 2.1.0~) | 
libqt5core5a   (>= 5.11.0~rc1) | 
libqt5dbus5(>= 5.7.0~) | 
libqt5gui5  (>= 5.7.0) | 
libqt5network5 (>= 5.7.0~) | 
libqt5qml5  (>= 5.0.2) | 
libqt5widgets5 (>= 5.7.0~) | 
libqt5x11extras5(>= 5.6.0) | 
libstdc++6(>= 5.2) | 
libx11-6   | 
libxtst6   | 


Package's Recommends field is empty.

Suggests  (Version) | Installed
===-+-===
plasma-workspace| 4:5.14.5.1-1
python-nautilus | 1.2.2-2







[1] http://plano-lavila.pdf


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

Bug#941354: proposed fix

[Paolo Greppi]

I have imported the upstream patch in a new version 1.13.0-3:
https://salsa.debian.org/js-team/node-yarnpkg/commit/6808cd918e8c12182e14666c715bb1d372d82449/pipelines

I have checked that it now uses https even if http links are present in 
yarn.lock as follows:

mkdir /tmp/qw
cd /tmp/qw
yarnpkg add string-width
rm -rf node_modules/
sed -i 's/https:/http:/g' yarn.lock
yarnpkg cache clean strip-ansi
yarnpkg cache clean string-width
yarnpkg cache clean ansi-regex
yarnpkg cache clean emoji-regex
yarnpkg cache clean is-fullwidth-code-point
yarnpkg cache clean strip-ansi

strace -s 256 yarnpkg install &> q
ping registry.yarnpkg.com # it's 104.16.22.35
grep 104.16.22.35 q

I get this:
connect(21, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(22, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(26, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(27, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)
connect(28, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operazione ora in 
corso)

Should I upload this to unstable ?
Will it automatically roll to stable ?

Paolo