Bug#935907: lintian: Build only needed test packages on partial tests

[Felix Lechner]

Hi,

On Tue, Aug 27, 2019 at 8:09 AM Xavier  wrote:
>
> This can be workaround using a "manifest"

Starting with commit 64a7ccd2, t/bin/build-test-packages builds test
packages only when their sources have changed. The sources are
generated from templates and the test specifications. For each test,
the manifest is located in
./debian/test-out/packages/.../source-files.sha1sums.

For the Gitlab runner, it means that only toolchain changes or updated
prerequisites (but not updated test specifications or templates)
should invalidate stored artifacts. Otherwise, test packages can be
carried from one run to the next. Please feel free to implement it, if
you know how.

At this point, it is not clear if and how adaptive building will be
offered in t/bin/runtests. We may rely instead on the fix for #927476
to provide a warning, although it is less customer-friendly than it
should be.

Kind regards
Felix Lechner

Bug#945869: lintian: false positive for debian-rules-not-executable

[Felix Lechner]

Hi Andreas,

I created the attached test case in Lintian, but I cannot get the tag
to show using '--pedantic':

$ frontend/lintian --pedantic
debian/test-out/packages/tags/checks/debian/rules/permissions-775/permissions-775_1.0.dsc
P: permissions-775 source: uses-debhelper-compat-file

even though d/rules shows as group writable in the tar file:

$ tar tvf 
debian/test-out/packages/tags/checks/debian/rules/permissions-775/permissions-775_1.0.tar.xz
drwxr-xr-x 0/0   0 2019-09-29 11:11 permissions-775-1.0/
drwxr-xr-x 0/0   0 2019-09-29 11:11 permissions-775-1.0/debian/
-rw-r--r-- 0/0 509 2019-09-29 11:11
permissions-775-1.0/debian/changelog
-rw-r--r-- 0/0   3 2019-09-29 11:11
permissions-775-1.0/debian/compat
-rw-r--r-- 0/0 662 2019-09-29 11:11
permissions-775-1.0/debian/control
-rw-r--r-- 0/01282 2019-09-29 11:11
permissions-775-1.0/debian/copyright
-rwxrwxr-x 0/0 291 2019-09-29 11:11 permissions-775-1.0/debian/rules
drwxr-xr-x 0/0   0 2019-09-29 11:11
permissions-775-1.0/debian/source/
-rw-r--r-- 0/0  13 2019-09-29 11:11
permissions-775-1.0/debian/source/format
drwxr-xr-x 0/0   0 2019-09-29 11:11
permissions-775-1.0/debian/tests/
-rw-r--r-- 0/0  12 2019-09-29 11:11
permissions-775-1.0/debian/tests/control
-rwxr-xr-x 0/0  17 2019-09-29 11:11
permissions-775-1.0/debian/tests/test

Equally perplexingly, I also do not see the tag in libtasn1-06. How do
you invoke Lintian? Also, what is your umask, please (although it
should not matter)?

$ frontend/lintian --pedantic libtasn1-6_4.14-3.dsc
E: libtasn1-6 source: source-is-missing doc/cyclo/cyclo-libtasn1.html
line length is 567 characters (>512)
P: libtasn1-6 source: insane-line-length-in-source-file
doc/cyclo/cyclo-libtasn1.html line length is 567 characters (>512)
P: libtasn1-6 source: no-dep5-copyright
P: libtasn1-6 source: package-uses-old-debhelper-compat-version 11
P: libtasn1-6 source: source-contains-prebuilt-javascript-object
doc/cyclo/cyclo-libtasn1.html line length is 567 characters (>512)

Kind regards
Felix Lechner


permissions-775_1.0.dsc
Description: Binary data


permissions-775_1.0.tar.xz
Description: application/xz

Bug#945870: Unmet Dependency on libgegl-common

[mason1920]

Package: libgegl-0.4-0
Version: 0.4.18-2
Severity: grave

Dear Maintainer,

I attempted to use GIMP, but got this error in return:
gimp: symbol lookup error: gimp: undefined symbol: gegl_rectangle_subtract

The libgegl-0.4-0 package was the issue, as I wasn't able to install it because 
of it's dependency on an available package.
It requires libgegl-common (>= 0.4.18-2) but 1:0.4.16-dmo2 is all that's to be 
installed.

What I find odd is the apt policy for libgegl-common:
libgegl-common:
  Installed: 1:0.4.16-dmo2
  Candidate: 1:0.4.16-dmo2
  Version table:
*** 1:0.4.16-dmo2 100
100 /var/lib/dpkg/status
 0.4.18-2 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
500 http://deb.debian.org/debian unstable/main i386 Packages

So I tried installing the available version using package=version, and APT 
considered it a downgrade.
Should be easy to fix the candidate, but unusable at the moment if you don't 
force "downgrade" it.

Bug#945869: lintian: false positive for debian-rules-not-executable

[Andreas Metzler]

On 2019-11-30 Felix Lechner  wrote:
> On Fri, Nov 29, 2019 at 9:48 PM Andreas Metzler  wrote:

>> -rwxrwxr-x 0/01277 2019-07-27 17:24 debian/rules

> The check in Lintian here should perhaps use a bitwise 'and':

> 
> https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/rules.pm#L174-176

> Is there a reason for the group write permissions?

Hello Felix,

it is the result of the default umask with usergroups. ;-) I guess
debian/* is group-writeable for almost all of "my" packages.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#945869: lintian: false positive for debian-rules-not-executable

[Felix Lechner]

Hi Andreas,

On Fri, Nov 29, 2019 at 9:48 PM Andreas Metzler  wrote:
>
> -rwxrwxr-x 0/01277 2019-07-27 17:24 debian/rules

The check in Lintian here should perhaps use a bitwise 'and':


https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/rules.pm#L174-176

Is there a reason for the group write permissions?

Kind regards
Felix Lechner

Bug#945869: lintian: false positive for debian-rules-not-executable

[Andreas Metzler]

Package: lintian
Version: 2.39.0
Severity: normal

Running lintian on libtasn1-6_4.14-3.dsc I get

P: libtasn1-6 source: debian-rules-not-executable

although the file is 775:
ametzler@argenau:/tmp/TASN$ tar tvf libtasn1-6_4.14-3.debian.tar.xz | \
grep rules
-rwxrwxr-x 0/01277 2019-07-27 17:24 debian/rules

cu Andreas

Bug#919039: RM: linuxbrew-wrapper -- RoQA; orphaned; python2-only; low popcon

[Mo Zhou]

control: retitle -1 RM: linuxbrew-wrapper -- RoM; orphaned; python2-only; low 
popcon

changing RoQA -> RoM. I agree the removal.

Bug#938840: xcffib: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Hi Gianfranco,

I noticed you did a couple of NMUs for this package, so I'm wondering
if you could take care of this issue (Bug #938840).  I'm not sure if
it's just a dependency change like #943259, or requires more
substantial work.  Its Bug (#936169) has the full list of options.

On Fri, Aug 30, 2019 at 07:58:57AM +, Matthias Klose wrote:
> Package: src:xcffib
> Version: 0.8.1-0.3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 

Sylvestre and I are coordinating the uploads at Bug #936169 for
autopep8, so if Iain Learmonth doesn't take care of this one please
let us know if you're interested :-)


Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#936169: autopep8: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Hi Sylvestre,

I noticed that the changelog of autopep8 was missing an entry for the
last upload, so I integrated it, and update the <= to << on packages
I'm working on to unblock this bug.

So #945725: py-autopep8-el is ready to go and I have DM.
   #943259: vim-autopep8 was completed today

Would you be willing to sponsor an NMU for #943259 at the appropriate
time, if necessary, so all the packages can arrive in the archive on
the same day?  I've uploaded it to mentors have marked it "Needs a
sponsor: No", but I wanted it to be ready to go because I expect to
have zero Debian time next week.

  https://mentors.debian.net/package/vim-autopep8
  dget 
https://mentors.debian.net/debian/pool/main/v/vim-autopep8/vim-autopep8_1.0.7-1.1.dsc

I hope Gianfranco will be willing to do #938840: xcffib, but if not I
hope to find time to take care of it in the next few days.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#943259: [PATCH 0/1] Re: vim-autopep8: Python2 removal in sid/bullseye

[Nicholas D Steeves]

Hi Balasankar,

I'm not sure if you noticed this bug earlier this year, but it's RC
now, so I took the liberty to fix it, because the autopep8 fix it
blocks affects one of my packages.  'hope that's ok with you, since
the package used to be collab-maint and hasn't been updated in many
years.  If you don't want me to NMU it, please let me know at your
earliest convenience :-)

The email that follows this one has the patch attached.

Nicholas D Steeves (1):
  Swap dependency of python-autopep8 for python3-autopep8 (>> 1.4.4-1)

 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.20.1

Bug#943259: [PATCH 1/1] Swap dependency of python-autopep8 for python3-autopep8 (>> 1.4.4-1)

[Nicholas D Steeves]

Signed-off-by: Nicholas D Steeves 
---
 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 25adec3..00ef84e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+vim-autopep8 (1.0.7-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Swap dependency of python-autopep8 for python3-autopep8 (>> 1.4.4-1),
+which now provides /usr/bin/autopep8.
+
+ -- Nicholas D Steeves   Fri, 29 Nov 2019 23:34:59 -0500
+
 vim-autopep8 (1.0.7-1) unstable; urgency=low
 
   * Initial release (Closes: #806573)
diff --git a/debian/control b/debian/control
index 8222523..942a765 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=collab-maint/vim-autopep8.git;
 
 Package: vim-autopep8
 Architecture: all
-Depends: python-autopep8,
+Depends: python3-autopep8 (>> 1.4.4-1),
  vim,
  vim-addon-manager,
  ${misc:Depends},
-- 
2.20.1

Bug#939311: monero: FTBFS on arm64: final link failed: file in wrong format

[Bertrand Jacquin]

Hi,

This bug is related to https://sourceware.org/bugzilla/show_bug.cgi?id=25210

-- 
Bertrand


signature.asc
Description: Digital signature

Bug#945868: ros-rospkg: OS detection is wrong for Ubuntu, uses deprecated LSB instead of os-release

[Steve Langasek]

Package: ros-rospkg
Version: 1.2.0-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, the latest version of ros-rosdep was failing to build due to test
failures related to ros-rospkg, which was not properly detecting the
platform as Ubuntu.  Digging into this, I found that ros-rospkg was relying
on the lsb_release command to detect Debian and Ubuntu as platforms; but
lsb_release is not part of the base system, so this fails when the
additional lsb-release package is not installed.

The attached patch fixes ros-rospkg to use os-release on Ubuntu, which works
for all supported releases.  I have not looked to confirm that
/etc/os-release is also guaranteed to be present on all supported Debian
releases, but it probably is.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ros-rospkg-1.2.0/debian/patches/series 
ros-rospkg-1.2.0/debian/patches/series
--- ros-rospkg-1.2.0/debian/patches/series  2019-11-24 01:47:43.0 
-0800
+++ ros-rospkg-1.2.0/debian/patches/series  2019-11-29 17:05:19.0 
-0800
@@ -3,3 +3,4 @@
 0003-Set-rosversion-to-Debian.patch
 0004-Use-Python-in-instead-of-string-find.patch
 0005-Replace-deprecated-platform-functions-with-distro.patch
+ubuntu-uses-fdo-not-lsb.patch
diff -Nru ros-rospkg-1.2.0/debian/patches/ubuntu-uses-fdo-not-lsb.patch 
ros-rospkg-1.2.0/debian/patches/ubuntu-uses-fdo-not-lsb.patch
--- ros-rospkg-1.2.0/debian/patches/ubuntu-uses-fdo-not-lsb.patch   
1969-12-31 16:00:00.0 -0800
+++ ros-rospkg-1.2.0/debian/patches/ubuntu-uses-fdo-not-lsb.patch   
2019-11-29 17:09:14.0 -0800
@@ -0,0 +1,20 @@
+Description: Don't rely on LSB-based OS detection for Ubuntu
+ All recent versions of Ubuntu ship /etc/os-release, and the lsb_release
+ command is only available if the optional lsb-release package is
+ installed.
+Author: Steve Langasek 
+Last-Updated: 2019-11-29
+
+Index: ros-rospkg-1.2.0/src/rospkg/os_detect.py
+===
+--- ros-rospkg-1.2.0.orig/src/rospkg/os_detect.py
 ros-rospkg-1.2.0/src/rospkg/os_detect.py
+@@ -756,7 +756,7 @@
+ OsDetect.register_default(OS_QNX, QNX())
+ OsDetect.register_default(OS_RHEL, Rhel())
+ OsDetect.register_default(OS_SLACKWARE, Slackware())
+-OsDetect.register_default(OS_UBUNTU, LsbDetect("Ubuntu"))
++OsDetect.register_default(OS_UBUNTU, FdoDetect("ubuntu"))
+ OsDetect.register_default(OS_CLEARLINUX, FdoDetect("clear-linux-os"))
+ OsDetect.register_default(OS_NIXOS, FdoDetect("nixos"))
+ OsDetect.register_default(OS_WINDOWS, Windows())

Bug#945763: gcc-9 ftbfs on mipsel

[YunQiang Su]

YunQiang Su  于2019年11月29日周五 下午2:21写道：
>
> 在 2019-11-29五的 07:00 +0100，Matthias Klose写道：
> > On 28.11.19 18:09, YunQiang Su wrote:
> > > Matthias Klose  于2019年11月28日周四 下午5:51写道：
> > > > On 28.11.19 10:44, Matthias Klose wrote:
> > > > > Package: src:gcc-9
> > > > > Version: 9.2.1-20
> > > > > Severity: serious
> > > > > Tags: sid bullseye
> > > > >
> > > > > gcc-9 ftbfs on mipsel with a bootstrap comparison failure, most
> > > > > likely triggered
> > > > > by the LTO build enabled in -20.
> > > > >
> > > > > bootstrap comparison failure!
> > > > > libbacktrace/elf.o differs
> > > > > libbacktrace/.libs/elf.o differs
> > > > > make[4]: *** [Makefile:24878: compare] Error 1
> > > >
> > > > Please could you have a look?
> > >
> > > sure. I will look at it tomorrow
> >
> > hmm, that also fails in gcc-7, which didn't see any code changes from
> > 7.5.0-1 to
> > 7.5.0-2.
>
> Maybe, it meets a buggy machine?

due to the Loongson's patch to add sync?

>


-- 
YunQiang Su

Bug#945867: lintian: Unable to override warning in -dbgsym

[Dmitry Smirnov]

Package: lintian
Version: 2.38.0~bpo10+1
Severity: normal

Lintian throws "field-too-long Built-Using" error for "nomad-dbgsym" but 
overriding it appears to be impossible as "nomad-dbgsym.lintian-overrides" is 
ignored?

Cheers,
 Dmitry Smirnov


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

Bug#945618:

[thomasw]

I built some kernels from mainline to narrow this down exactly. I don't 
reproduce in 5.3.10. I reproduce in 5.3.11. Not sure if something was fixed in 
the kernel that exposed an Orca/Speech Dispatcher bug or if this is a kernel 
regression. Hopefully narrowing this down helps some. 5.3.10 to 5.3.11 is very 
few commits.

Bug#654659: ITP: plover

[Harlan Lieberman-Berg]

retitle 654659 ITP: plover -- stenotype input method
owner 654659 !
thanks

Sorry for letting this lie for so long.  I've redone the packaging of
the latest weekly at the advice of upstream, and it seems to be in a
good state.  I'm holding off on uploading it until a more experienced
plover user tests my debs, but that should be happening in the next
week.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#934372: snapd: does not work under cgroup v2 at all

[Ryutaroh Matsumoto]

Package: snapd
Version: 2.42.1-1
Followup-For: Bug #934372
Control: block 943981 by -1
Control: severity -1 minor
Control: user pkg-systemd-maintain...@lists.alioth.debian.org
Control: usertag -1 + cgroupv2

Dear Maintainer,

The situation improved in version 2.42.1, now we have
$ snap run hello-world
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
Hello World!

I changed the severity and a usertag cgroupv2, see also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981

Best regards,
Ryutaroh

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

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

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.2-10
ii  ca-certificates  20190110
ii  gnupg2.2.12-1+deb10u1
ii  libapparmor1 2.13.2-10
ii  libc62.29-3
ii  libcap2  1:2.25-2
ii  libseccomp2  2.4.2-2
ii  libudev1 241-7~deb10u1
ii  openssh-client   1:7.9p1-10
ii  squashfs-tools   1:4.4-1
ii  systemd  241-7~deb10u1
ii  udev 241-7~deb10u1

Versions of packages snapd recommends:
ii  gnupg  2.2.12-1+deb10u1

Versions of packages snapd suggests:
ii  zenity  3.30.0-2

-- no debconf information

Bug#937647: marked as done (python-cliapp: Python2 removal in sid/bullseye)

[Sandro Tosi]

>* QA upload
>* Drop python2 support (Closes: #937647)
>* Run tests during build and under autopkgtest

there are still 2 rdeps
http://sandrotosi.me/debian/py2removal/python-cliapp_1.svg !


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

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Sean Whitton]

control: tag -1 +pending

Hello Nicholas,

On Fri 29 Nov 2019 at 01:26PM -05, Nicholas D Steeves wrote:

> At any rate, I've submitted an update MR here (see previous email for
> extended rationale):
>
>   https://salsa.debian.org/sten-guest/policy/merge_requests/3

Thank you for preparing a patch.  Unfortunately, I don't think that we
should be committing a stub paragraph to the Policy Manual.

The text of your patch outside of the stub paragraph doesn't read as
well at what Russ proposed.  So I've gone ahead and committed Russ's
text to master, and marked it as closing this bug.

If you'd like to convert your stub paragraph into an actual patch,
against current master, please do share it for consideration.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945866: bugs.debian.org: $PATH error with root (su command)

[n00stream...@gmail.com]

Package: bugs.debian.org
Severity: important


Hello,
I have a fresh Debian10 install with netinstall amd64 ISO without desktop 
environment, only bash on startup. You need to login
with a normal user. Than get root privileges with su (type su), enter password, 
than display the PATH variable (type echo
$PATH). The variable dont switch to root's PATH variable.

BYPASS: Read /etc/profile after su (type source /etc/profile). Than it switchs 
to root's PATH. 


Subject: bugs.debian.org: $PATH error with root (su command)
Package: bugs.debian.org
Severity: important

Dear Maintainer,

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

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

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


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

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

Bug#945864: unhide[208429]: segfault at 7ffd06cfec58 ip 000055c15aa077d3 sp 00007ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]

[Christoph Anton Mitterer]

Package: unhide
Version: 20130526-3
Severity: grave
Justification: renders package unusable



Since 1-3 weeks unhide segfaults every time:

Nov 30 01:39:48 heisenberg kernel: unhide[208429]: segfault at 7ffd06cfec58 ip 
55c15aa077d3 sp 7ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]
Nov 30 01:39:48 heisenberg kernel: Code: 00 48 89 45 c8 31 c0 48 63 05 5d 98 00 
00 48 8d 04 85 0f 00 00 00 48 83 e0 f0 48 29 c4 48 89 65 98 48 29 c4 31 c0 48 
89 65 90  d8 3e 00 00 31 c0 66 0f 1f 44 00 00 48 8b 4d 98 48 8b 55 90 c7


Cheers,
Chris.

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

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

Versions of packages unhide depends on:
ii  libc6  2.29-3

unhide recommends no packages.

Versions of packages unhide suggests:
ii  rkhunter  1.4.6-7

-- no debconf information

Bug#945865: jami: Broken chat view

[Bruno Kleinert]

Package: jami
Version: 20190215.1.f152c98~ds1-1+b1
Severity: normal

Hi,

the chat view in Jami is broken: When Jami is started and I click on names in
my contact list on the left, the chat view remains empty. When I resize the
Jami window, some contents in the chat view appear. However, they are
misplaced. I run Jami in GNOME3 in a Wayland session.

Please see attached screenshot:
  * The chat "bubbles" are misplaced and one is cut
  * The buttons (return, audio call, video call) are invisable
  * The text input field is displayed at the wrong position

Some days ago I reported https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=945377. Both result in different curroptions of chats,
but I'm unsure if they are related to each other.

Cheers - Bruno



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

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

Versions of packages jami depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  jami-daemon  20190215.1.f152c98~ds1-1+b1
ii  libayatana-appindicator3-1   0.5.4-1
ii  libc62.29-3
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libclutter-1.0-0 1.26.2+dfsg-12
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libgcc1  1:9.2.1-20
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.3-1
ii  libgtk-3-0   3.24.13-1
ii  libnm0   1.20.8-1
ii  libnotify4   0.7.8-1
ii  libpango-1.0-0   1.42.4-7
ii  libqrencode4 4.0.2-2
ii  libqt5core5a 5.12.5+dfsg-2
ii  libqt5dbus5  5.12.5+dfsg-2
ii  libqt5gui5   5.12.5+dfsg-2
ii  libqt5sql5   5.12.5+dfsg-2
ii  libqt5sql5-sqlite5.12.5+dfsg-2
ii  libstdc++6   9.2.1-20
ii  libwebkit2gtk-4.0-37 2.26.2-1
ii  libx11-6 2:1.6.8-1

jami recommends no packages.

jami suggests no packages.

-- no debconf information

Bug#945863: python-caja: Build python3 bindings for Caja components

[Sandro Knauß]

Source: python-caja
Version: 1.22.1-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal
Control: block 945674 by -1
Control: block 937628 by -1

I can not replace python-caja with a python3 package, as this package,
don't provide a Python3 binding. Vlad mentioned in #937628 that 1.22.0
is compatible for Python2 and Python3. So please built a PYthon3
binding, so reverse dependencies can switch to the Python3 binding.

hefee


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

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

Bug#938682: Future of Trac in Debian

[Martin]

On 2019-11-29 18:13, Nicholas D Steeves wrote:
> IMHO one of the Debian Trac uploaders should post to the #12130 Trac
> ticket informing them of our plan.

I linked to the email of 2019-10-14:
https://trac.edgewall.org/ticket/12130#comment:63

Bug#945862: /etc/cron.daily/apt-compat: Use "sleep" later in the script

[Bjarni Ingi Gislason]

Package: apt
Version: 1.8.4
Severity: minor

Dear Maintainer,

   * What led up to the situation?

  The "sleep" funtion was shown in the output of "ps".

###

  Do not put the script to a sleep, if it is afterwards not going to do
its job.

  Therefor call "random_sleep" after "check_power || exit 0".

N.B. Other bug reports about the file are #829443 and #898312.

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

Kernel: Linux 5.3.9-3 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.17-3
ii  libapt-pkg5.0   1.8.4
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libgnutls30 3.6.10-5
ii  libseccomp2 2.4.2-2
ii  libstdc++6  9.2.1-19

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.7
ii  gnupg2.2.17-3
pn  powermgmt-base   

-- Configuration Files:
/etc/cron.daily/apt-compat changed [not included]

-- no debconf information

-- 
Bjarni I. Gislason

Bug#924673: libopencsd0:amd64: New flag needed to compile CoreSight support in the perf tools

[Wookey]

On 2019-10-28 00:45 +, Wookey wrote:
> On 2019-03-15 11:09 -0600, Mathieu Poirier wrote:

> > Starting with the 5.1 Linux kernel cycle it is mandatory to add the command 
> > line
> > option "CORESIGHT=1" to enable CoreSight support when compiling the perf 
> > tools.
> 
> The debian kernel package does indeed now need a small patch to enable
> coresight in perf. Attached. (and this bug re-assigned to the kernel).

It's been a month chaps. Any chance of aplying this two-liner? Or at
least confirming that it will go in in due course?

Or do I need to do do this as a salsa pull request instead?

> --- debian/rules.d/tools/perf/Makefile~   2019-09-10 11:36:37.0 
> +
> +++ debian/rules.d/tools/perf/Makefile2019-10-24 15:54:13.659470790 
> +
> @@ -22,6 +22,9 @@
>  # an explicit exception.  Override detection of libcrypto.
>  MAKE_PERF += NO_LIBCRYPTO=1
>  
> +# perf only links against libopencsd (coresight) if specifically enabled
> +MAKE_PERF += CORESIGHT=1
> +
>  # Currently babeltrace support for `perf data' is not automatically detected.
>  MAKE_PERF += LIBBABELTRACE=1
>  



Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#945861: inetutils: CVE-2019-0053

[Salvatore Bonaccorso]

Source: inetutils
Version: 2:1.9.4-10
Severity: important
Tags: security upstream
Control: found -1 2:1.9.4-7
Control: found -1 2:1.9.4-2

Hi,

The following vulnerability was published for inetutils, the CVE
description on MITRe might be missleading as it indicates it is
somehow related to Juniper only. But see other refernces, [1] and [2].

CVE-2019-0053[0]:
| Insufficient validation of environment variables in the telnet client
| supplied in Junos OS can lead to stack-based buffer overflows, which
| can be exploited to bypass veriexec restrictions on Junos OS. A stack-
| based overflow is present in the handling of environment variables
| when connecting via the telnet client to remote telnet servers. This
| issue only affects the telnet client #8212; accessible from the
| CLI or shell #8212; in Junos OS. Inbound telnet services are not
| affected by this issue. This issue affects: Juniper Networks Junos OS:
| 12.3 versions prior to 12.3R12-S13; 12.3X48 versions prior to
| 12.3X48-D80; 14.1X53 versions prior to 14.1X53-D130, 14.1X53-D49; 15.1
| versions prior to 15.1F6-S12, 15.1R7-S4; 15.1X49 versions prior to
| 15.1X49-D170; 15.1X53 versions prior to 15.1X53-D237, 15.1X53-D496,
| 15.1X53-D591, 15.1X53-D69; 16.1 versions prior to 16.1R3-S11,
| 16.1R7-S4; 16.2 versions prior to 16.2R2-S9; 17.1 versions prior to
| 17.1R3; 17.2 versions prior to 17.2R1-S8, 17.2R2-S7, 17.2R3-S1; 17.3
| versions prior to 17.3R3-S4; 17.4 versions prior to 17.4R1-S6,
| 17.4R2-S3, 17.4R3; 18.1 versions prior to 18.1R2-S4, 18.1R3-S3; 18.2
| versions prior to 18.2R1-S5, 18.2R2-S2, 18.2R3; 18.2X75 versions prior
| to 18.2X75-D40; 18.3 versions prior to 18.3R1-S3, 18.3R2; 18.4
| versions prior to 18.4R1-S2, 18.4R2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-0053
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0053
[1] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:12.telnet.asc
[2] 
https://raw.githubusercontent.com/hackerhouse-opensource/exploits/master/inetutils-telnet.txt

Regards,
Salvatore

Bug#938682: Future of Trac in Debian

[Martin]

On 2019-11-29 16:24, Sandro Tosi wrote:
> I know it may sound hard, but is it now time to remove trac from
> Debian, and ideally re-introduce it back when it's being ported to
> py3k?

See also:
https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs
What would be the alternative?

It would be nice to have newer versions (based on Python 2) as
backports or sloppy backports for buster, but that will not be
possible anymore, as soon as Trac is removed from unstable,
right?

Btw. Trac development is still active (1.4 released three months
ago, but slow, maybe because of lack of developers:
"Trac 1.4 is the first major release of Trac in almost 3 years."
Trac 1.6 will probably use Python 3. But when? Nobody knows.

Cheers

Bug#945860: The test depends need to be updated

[Sebastien Bacher]

Package: liborcus
Version: 0.15.3-2

The debian/tests/control Depends didn't get updated for the new -15
binaries, which makes the tests depends now not installable

Bug#945859: gnupg2: CVE-2019-14855: Web of Trust forgeries using collisions in SHA-1 signatures

[Salvatore Bonaccorso]

Source: gnupg2
Version: 2.2.17-3
Severity: important
Tags: security upstream fixed-upstream
Forwarded: https://dev.gnupg.org/T4755
Control: found -1 2.2.12-1+deb10u1

Hi,

The following vulnerability was published for gnupg2, and was fixed
upstream in 2.2.28.

CVE-2019-14855[0]:
WoT forgeries using SHA-1

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14855
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14855
[1] https://dev.gnupg.org/T4755

Regards,
Salvatore

Bug#945619: transition: kdepim 19.08

[Sandro Knauß]

Hey,

 I prepared a patch for zanshin [!1]. That means I could now built every 
reverse dependency with KDEPIM 19.08 and nothing is stopping me to start with 
the transition (except the ACK from your side).

hefee

!1: https://salsa.debian.org/qt-kde-team/extras/zanshin/merge_requests/1

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

Bug#945858: b-d on python3-all-dev, but not built for all supported Python3 versions

[Sebastien Bacher]

Package: libplist
Version: 2.0.1~git20190104.3f96731-1

The package build-depends on python3-all-dev, but does not build for all
supported python3 versions, it should rather b-d on python3-dev if it
only needs to build with the current python version

Bug#945330: yt ftbfs in unstable

[Sebastien Bacher]

The issue seems similar to https://github.com/yt-project/yt/issues/2313
and due to numpy 1.17

Which has been fixed with that commit
https://github.com/yt-project/unyt/commit/27894c1e

Cheers,

Bug#938682: Future of Trac in Debian

[Nicholas D Steeves]

Hi,

Sandro Tosi  writes:

> Hello everyone,
> i'd like to discuss the future of Trac in Debian. as we all know, Trac
> is still python2, and while there are plans to port it to python3
> (https://trac.edgewall.org/ticket/12130) that port is not there yet,
> and it may take quite some time to reach a state it can be tested, let
> alone released.
>
> What should we do in the meantime? bin:trac has 30 reverse
> dependencies (its plugins/addons) and all of them collectively are
> likely forceing several other python2 packages to stay in Debian
> because they depend on them.
>
> I know it may sound hard, but is it now time to remove trac from
> Debian, and ideally re-introduce it back when it's being ported to
> py3k?

At that upstream issue gwync writes that he might have to drop Trac in
Fedora if there isn't a py3 test release "before Fedora 32 is GA".  I'm
not sure what "GA" means, but given their release schedule here:

  https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html

and it looks like they'll be dropping py2 on 2020-01-01, and thus Trac.

IMHO one of the Debian Trac uploaders should post to the #12130 Trac
ticket informing them of our plan.  Is there a concrete plan yet? eg:

  We intend to remove Python 2 from Debian by 31 January, and
  because we are a conservative and slow moving distribution we are
  slowly working are way through thousands of application dependency
  chains to remove applications that do not support Python 3, rather
  than breaking everything at once by simply removing the interpreter on
  New Year's Day.  If we were not removing packages now we could not
  meet this objective.
  .
  We would like to continue distribute Software-X in Debian, so is there
  a Python 3 port we can package that is ready for testing today?

--

Which is to say, I think the question of "remove now" is contingent on
that question.  If there is zero hope of a py3 port in a testable state
by py2 EOL, then it's ok to drop now, but we need to do more to maintain
good relationships with upstreams.


Best,
Nicholas


signature.asc
Description: PGP signature

Bug#945857: rust-tiff: (build-)depends on cruft package.

[Peter Green]

Package: rust-tiff
Version: 0.3.1-2
Severity: serious
Tags: bullseye, sid

librust-tiff-dev depends on and the rust-tiff source package build-depends on 
librust-num-derive-0.2+default-dev which is no longer provided by 
librust-tiff-dev. It seems to have been replaced by 
librust-num-derive-0.3+default-dev

Bug#859513: New version available upstream

[Louis-Philippe Véronneau]

On 19-11-29 03 h 08, László Böszörményi (GCS) wrote:
> If you follow the development of AngularJS then you know its end of
> life [3] since July 1, 2018 (more than a year ago). Its still
> supported with critical updates including security fixes until June
> 30, 2021. Indeed, that's about one and half years from now, but see
> the current situation. With the package update developers will need to
> update their web applications to support the (breaking) changes in
> AngularJS 1.7.x just to realize its end-of-life status. Maybe they
> already started migrating to an other web framework or better start
> migrating now to an other one. Does it worth to update the package or
> should it be removed from our archives?
>
> [3] https://www.convective.com/angularjs-end-of-life/

I wasn't aware of this and although I am not sure you should base your
decision solely on my point of view (I don't have tons of experience
maintaining things in Debian), here's what I think.

1. If it's not too much work, you should package 1.7.x, not worry too
much about breakage and add something like "(Breaks: libjs-angularjs (<<
1.6.0)". If you don't have the energy, I think leaving this package
as-is is also fine.

2. I don't think this package should be removed from unstable before the
end of the LTS period, as it's still useful and will ease the transition
to Angular (if it's packaged).

3. An RC bug about AngularJS being EOL should be opened to make sure
libjs-angularjs doesn't migrate to testing and be released in Bullseye.

4. You should contact the security team // the release team and see what
they think of this.

Do you have any plans to package Angular? I think putting your energy
there would be a much wiser move than on a package bound not to be
released in Bullseye.

Thanks for your work on this package!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#945855: RM: pyevolve -- ROM; Python2, inactive upstream

[Christian Kastner]

Package: ftp.debian.org
Severity: normal

Please remove pyevolve from unstable. The popcon is low, and there has
been no upstream activity in years. It's still Python 2 only and because
of the points raised in the previous sentence, I don't think that the
effort of converting to Python 3 would be worthwhile.


Regards,
Christian

Bug#945856: RM: libmpikmeans -- ROM; abandoned, low popcon

[Christian Kastner]

Package: ftp.debian.org
Severity: normal

Please remove libmpikmeans from unstable. There hasn't been upstream
activity in 8 years, and its popcon is very low.

There's an RC bug because it's still Python 2 only, but without an
active upstream, I don't think that the effort of converting to Python 3
would be worthwhile.

Christian

Bug#936850: patch

[Moritz Mühlenhoff]

tags 936850 patch
thanks

All reverse dependencies to the Python 2 package are gone, patch attached.

Cheers,
Moritz
diff -Naur libesedb-20181229.orig/debian/control libesedb-20181229/debian/control
--- libesedb-20181229.orig/debian/control	2019-01-27 04:28:57.0 +0100
+++ libesedb-20181229/debian/control	2019-11-29 23:03:51.165989678 +0100
@@ -3,7 +3,7 @@
 Maintainer: Debian Security Tools 
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 11),
- pkg-config, python-dev, python3-dev, libbfio-dev,
+ pkg-config, python3-dev, libbfio-dev,
 Standards-Version: 4.3.0
 Section: libs
 Homepage: https://github.com/libyal/libesedb
@@ -53,18 +53,6 @@
  This package contains tools to access data stored in EDB files:
  esedbexport, esedbinfo.
 
-Package: python-libesedb
-Section: python
-Architecture: any
-Depends: libesedb1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Extensible Storage Engine DB access library -- Python 2 bindings
- libesedb is a library to access the Extensible Storage Engine (ESE)
- Database File (EDB) format. The ESE database format is used in may
- different applications like Windows Search, Windows Mail, Exchange,
- Active Directory, etc..
- .
- This package contains Python 2 bindings for libesedb.
-
 Package: python3-libesedb
 Section: python
 Architecture: any
diff -Naur libesedb-20181229.orig/debian/python-libesedb.install libesedb-20181229/debian/python-libesedb.install
--- libesedb-20181229.orig/debian/python-libesedb.install	2019-01-26 14:15:31.0 +0100
+++ libesedb-20181229/debian/python-libesedb.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Naur libesedb-20181229.orig/debian/rules libesedb-20181229/debian/rules
--- libesedb-20181229.orig/debian/rules	2019-01-27 04:37:36.0 +0100
+++ libesedb-20181229/debian/rules	2019-11-29 23:03:32.982571033 +0100
@@ -12,10 +12,10 @@
 export SKIP_PYTHON_TESTS=1
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-python2 --enable-python3 CFLAGS="-g"
+	dh_auto_configure -- --enable-python3 CFLAGS="-g"
 
 override_dh_missing:
 	dh_missing -Xpyesedb.a -X.la --fail-missing

Bug#936853: patch

[Moritz Mühlenhoff]

tags 936853 patch
thanks

All reverse dependencies to the Python 2 package are gone, patch attached.

Cheers,
Moritz
diff -Naur libevtx-20181227.orig/debian/control libevtx-20181227/debian/control
--- libevtx-20181227.orig/debian/control	2019-01-14 00:36:29.0 +0100
+++ libevtx-20181227/debian/control	2019-11-29 22:59:19.118592303 +0100
@@ -3,7 +3,7 @@
 Maintainer: Debian Security Tools 
 Uploaders: Hilko Bengen 
 Build-Depends: debhelper (>= 11),
- pkg-config, python-dev, python3-dev, libbfio-dev,
+ pkg-config, python3-dev, libbfio-dev,
 Standards-Version: 4.3.0
 Section: libs
 Homepage: https://github.com/libyal/libevtx
@@ -44,15 +44,6 @@
  This package contains tools to access data stored in EVT log files:
  evtxexport, evtxinfo.
 
-Package: python-libevtx
-Section: python
-Architecture: any
-Depends: libevtx1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Windows XML Event Log format access library -- Python 2 bindings
- libevtx is a library to access the Windows XML Event Log (EVTX) format.
- .
- This package contains Python 2 bindings for libevtx.
-
 Package: python3-libevtx
 Section: python
 Architecture: any
diff -Naur libevtx-20181227.orig/debian/python-libevtx.install libevtx-20181227/debian/python-libevtx.install
--- libevtx-20181227.orig/debian/python-libevtx.install	2016-08-02 11:13:37.0 +0200
+++ libevtx-20181227/debian/python-libevtx.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Naur libevtx-20181227.orig/debian/rules libevtx-20181227/debian/rules
--- libevtx-20181227.orig/debian/rules	2019-01-14 00:36:29.0 +0100
+++ libevtx-20181227/debian/rules	2019-11-29 22:59:02.011107593 +0100
@@ -10,10 +10,10 @@
 export SKIP_PYTHON_TESTS=1
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-python2 --enable-python3
+	dh_auto_configure -- --enable-python3
 
 override_dh_missing:
 	dh_missing -X.la -X/pyevtx.a --fail-missing

Bug#945854: Please include additional virtio modules used for boot into initramfs for MODULES=most

[Josh Triplett]

Package: initramfs-tools-core
Version: 0.135
Severity: wishlist

Please consider adding the modules needed for virtiofs to MODULES=most,
to support booting a system from virtiofs.

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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.30-3+b1
ii  cpio 2.13+dfsg-1
ii  e2fsprogs1.45.4-1
ii  klibc-utils  2.0.7-1
ii  kmod 26-3
ii  logsave  1.45.4-1
ii  udev 243-8

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.30.1-4
ii  pigz 2.4-1+b1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.9-1

-- no debconf information

Bug#944819: fixed in cyrus-imapd 3.0.12-2

[Paul Gevers]

Hi Xavier,

On Thu, 28 Nov 2019 20:44:27 + Xavier Guimard  wrote:

[...]

>  cyrus-imapd (3.0.12-2) unstable; urgency=medium

[...]

>* Improve autopkgtest:
>  + use native autopkgtest packages system
>  + add more perl packages to minimize cpan downloads

I don't know how CPAN works, but I hope this way of testing remains
reproducible over the lifetime of a Debian release. I would hate it when
a passing test turns bad because of changes on the internet At least
make sure that the test fails gracefully (i.e. with the skippable
restriction and proper error handling) in case your resources are
(temporarily) not available. Would it make sense to ship your test
vectors and other required code in a separate test package.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#945853: Please enable CONFIG_VIRTIO_FS and CONFIG_VIRTIO_PMEM

[Josh Triplett]

Source: linux
Version: 5.3.9-3
Severity: wishlist

Please consider enabling CONFIG_VIRTIO_FS (newer filesystem-over-virtio
protocol) and CONFIG_VIRTIO_PMEM (persistent memory devices over
virtio).

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

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

Bug#938682: Future of Trac in Debian

[Sandro Tosi]

Hello everyone,
i'd like to discuss the future of Trac in Debian. as we all know, Trac
is still python2, and while there are plans to port it to python3
(https://trac.edgewall.org/ticket/12130) that port is not there yet,
and it may take quite some time to reach a state it can be tested, let
alone released.

What should we do in the meantime? bin:trac has 30 reverse
dependencies (its plugins/addons) and all of them collectively are
likely forceing several other python2 packages to stay in Debian
because they depend on them.

I know it may sound hard, but is it now time to remove trac from
Debian, and ideally re-introduce it back when it's being ported to
py3k?

thanks,
sandro

Bug#945852: epiphany-browser: Epiphany fails to save print as pdf

[Roberto De Oliveira]

Package: epiphany-browser
Version: 3.34.1-1+b1
Severity: important

Dear Maintainer,

I tried to use Epiphany to print a file as pdf. I selected the option with
different path
and no one worked. Also it fails with other file types, like svg and ps. The
only message
that I received with journalctl -f was:

nov 29 17:16:35 linuxbox dbus-daemon[701]: [system] Rejected send message, 0
matched rules; type="method_return", sender=":1.3" (uid=109 pid=696
comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error
name="(unset)" requested_reply="0" destination=":1.272" (uid=1001 pid=19247
comm="epiphany --new-window ")
nov 29 17:16:35 linuxbox dbus-daemon[701]: [system] Rejected send message, 0
matched rules; type="method_return", sender=":1.3" (uid=109 pid=696
comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error
name="(unset)" requested_reply="0" destination=":1.272" (uid=1001 pid=19247
comm="epiphany --new-window ")




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

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

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  epiphany-browser-data 3.34.1-1
ii  gsettings-desktop-schemas 3.34.0-2
ii  iso-codes 4.4-1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-3
ii  libcairo2 1.16.0-4
ii  libdazzle-1.0-0   3.34.1-1
ii  libgcr-base-3-1   3.33.4-2
ii  libgcr-ui-3-1 3.33.4-2
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.3-1
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgtk-3-03.24.12-1
ii  libhogweed5   3.5.1+really3.5.1-2
ii  libjavascriptcoregtk-4.0-18   2.26.2-1
ii  libjson-glib-1.0-01.4.4-2
ii  libnettle73.5.1+really3.5.1-2
ii  libnotify40.7.8-1
ii  libpango-1.0-01.42.4-7
ii  libsecret-1-0 0.19.1-1
ii  libsoup2.4-1  2.68.2-1
ii  libsqlite3-0  3.30.1-1
ii  libwebkit2gtk-4.0-37  2.26.2-1
ii  libxml2   2.9.4+dfsg1-8

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20190110
ii  evince   3.34.1-1
ii  yelp 3.34.0-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#945851: libnum-ocaml-dev: missing Breaks+Replaces: ocaml-nox (<< 4.08)

[Andreas Beckmann]

Package: libnum-ocaml-dev
Version: 1.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libreins-ocaml-dev

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

[...]
  Selecting previously unselected package libnum-ocaml-dev.
  Preparing to unpack .../27-libnum-ocaml-dev_1.2-2_amd64.deb ...
  Unpacking libnum-ocaml-dev (1.2-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-LYjFx6/27-libnum-ocaml-dev_1.2-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/ocaml/arith_flags.cmx', which is also in 
package ocaml-nox 4.05.0-11
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../28-libreins-ocaml-dev_0.1a-9+b1_amd64.deb ...
  Unpacking libreins-ocaml-dev (0.1a-9+b1) over (0.1a-7+b1) ...
  Preparing to unpack .../29-ocaml-compiler-libs_4.08.1-4_amd64.deb ...
  Unpacking ocaml-compiler-libs (4.08.1-4) over (4.05.0-11) ...
  dpkg: considering deconfiguration of ocaml-base-nox, which would be broken by 
installation of ocaml-nox ...
  dpkg: yes, will deconfigure ocaml-base-nox (broken by ocaml-nox)
  Preparing to unpack .../30-ocaml-nox_4.08.1-4_amd64.deb ...
  De-configuring ocaml-base-nox (4.05.0-11) ...
  Unpacking ocaml-nox (4.08.1-4) over (4.05.0-11) ...
  Replacing files in old package ocaml-base-nox (4.05.0-11) ...
  Preparing to unpack .../31-ocaml-base-nox_4.08.1-4_amd64.deb ...
  Unpacking ocaml-base-nox (4.08.1-4) over (4.05.0-11) ...
  Preparing to unpack .../32-ocaml-interp_4.08.1-4_amd64.deb ...
  Unpacking ocaml-interp (4.08.1-4) over (4.05.0-11) ...
  Selecting previously unselected package libnum-ocaml.
  Preparing to unpack .../33-libnum-ocaml_1.2-2_amd64.deb ...
  Unpacking libnum-ocaml (1.2-2) ...
  Preparing to unpack .../34-libss2_1.45.4-1_amd64.deb ...
  Unpacking libss2:amd64 (1.45.4-1) over (1.44.5-1+deb10u2) ...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-LYjFx6/27-libnum-ocaml-dev_1.2-2_amd64.deb


cheers,

Andreas


libreins-ocaml-dev_0.1a-9+b1.log.gz
Description: application/gzip

Bug#945618:

[Ben Hutchings]

Control: reassign -1 orca

I'm reassigning this to orca, in case there is something that can be
done there to allow power saving when it's not actively speaking.

Ben.

On Thu, 2019-11-28 at 20:54 -0500, thom...@fastmail.cn wrote:
> I have to appologize for an error I made when reporting this. It can
> actually be reproduced in both Arch and Debian. The difference was
> that I didn't have pulseaudio installed on my Arch system. I am blind
> and use Orca. If I have Orca playing through pulse, the pc states are
> not entered in both Arch and Debian with the newer kernels. If pulse
> is on but Orca is disabled, I can enter the pc states. I am not sure
> if all sounds playing through pulse cause the pc states to not be
> entered or if this is specifically an Orca/speech-dispatcher/espeak-
> ng problem. I had sighted assistance reading powertop with Orca
> disabled and could only test this one case with no sounds playing
> (sighted help is limited in my current living situation). The
> information in my first message about the kernels where this occurs
> and those in which this does not occur is still accurate. I don't
> think this matters but I will include that I use the Mate desktop.
> 
-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug




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

Bug#919218: non-transition: libqt5gui5-gles

[Dmitry Shachnev]

Dear Release team,

On Sun, Jan 13, 2019 at 11:09:37PM +0300, Dmitry Shachnev wrote:
> In Qt/KDE team, we have recently been working on Qt packages built
> with OpenGL ES support. This is what most participants of the Qt OpenGL
> thread [1] expressed their wish for.
>
> The main idea is that there is now a libqt5gui5-gles package (and,
> in future, libqt5quick5-gles and some others) that can be installed
> instead of their non-gles equivalents and provide mostly the same API.
> It is described in more details in README.Debian [2].
>
> However, in order for this scheme to work properly, we need to rebuild
> all packages depending on libqt5gui5 to gain a new dependency on
> libqt5gui5 | libqt5gui5-gles (they will get it automatically from the
> symbols file if they do not use any desktop OpenGL specific ABI).
>
> This is not a regular transition because the packages can be rebuilt
> at any time, in any order, and there are no testing migrations involved.
>
> Would such a rebuild be possible? If yes, can we plan for it to happen
> after the freeze? Or maybe it's even possible to do it now?

Thanks for setting up the tracker! Given that libqt5gui5-gles package has
reached testing now, would it be possible to start binNMUs?

As I said earlier, they can be done in any order and not necessarily all
at once.

Some packages are already green in the tracker. They do not need any action.
Also, no rebuilds are needed on armel and armhf as on these architectures Qt
uses OpenGL ES by default.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#945850: ITP: libime -- Generic Input Method Implementation

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang 

* Package name: libime
  Version : 0.0~git20191103.442e091
  Upstream Author : Xuetian Weng 
* URL : https://github.com/fcitx/libime
* License : LGPL-2.1+
  Programming Lang: C++
  Description : Generic Input Method Implementation

Libime is a generic input method implementation library. It is mainly
used by fcitx5, the next generation of fcitx input method framework.

This package will be co-maintained under Debian Input Method Team.

-- 
Thanks,
Boyuan Yang


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

Bug#945824: [python3-numpy] Depends on python3.8 and python3.7

[Sandro Tosi]

control: tags -1 +wontfix

> the numpy package depends on all possible Python 3 versions at the same
> time:
>
> * python
> * python3.7
> * python3.8
>
> There is no need to depend on the individual Python versions; any
> supported version should be sufficient. Otherwise both versions are
> pulled, even when they are not used.

this is likely an artifact of shipping f2py3.7 and f2py3.8 with a
shebang referring directly to a versioned interpreter. that's always
been the case with multiple interpreters.

> My specific problem with that is that CMake fails to find the Python 3.7
> development libraries when Python 3.8 is installed without development
> libs. This happens in the "casacore" package:

that sounds a bug/deficiency in casacore that you may want to address.


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

Bug#945835: [Pkg-utopia-maintainers] Bug#945835: firewalld: New point release available with important bugfixes

[Michael Biebl]

Hi

Am 29.11.19 um 15:41 schrieb Wiebe Verweij:
> Package: firewalld
> Version: 0.6.3-5
> Severity: important
> 
> Dear Maintainer,
> 
> Please consider updating this package to the latest point release firewalld, 
> it includes numerous bugfixes.
> 
> For example, using ipsets with the nftables backend in the version packaged 
> is broken because entries don't get added properly.
> This is fixed by ipset: fix set apply if IndividualCalls=yes in the latest 
> point release.
> 
> Also see the release notes: 
> https://firewalld.org/2019/05/firewalld-0-6-4-release

Debian stable won't see new upstream releases, as this is against the
policy for stable as defined by the release managers. I can't change
that policy unfortunately.

I might provide a backport of newer versions though.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940646


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#945849: breezy: autopkgtest regression: FAILED (failures=2, known_failure_count=66)

[Paul Gevers]

Source: breezy
Version: 3.0.2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of breezy the autopkgtest of breezy *on arm64*
fails in testing when that autopkgtest is run with the binary packages
of breezy from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
breezy from testing3.0.2-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/arm64/b/breezy/3532573/log.gz

==
FAIL:
breezy.tests.test__dirstate_helpers.TestPackStat.test_ancient_ctime(dirstate_Pyrex)
--
Traceback (most recent call last):
testtools.testresult.real._StringException: Empty attachments:
  log

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/breezy/tests/test__dirstate_helpers.py",
line 1388, in test_ancient_ctime
self.assertEqual(1240428288, self.unpack_field(packed, "st_ctime"))
  File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line
1317, in assertEqual
pprint.pformat(a), pprint.pformat(b)))
AssertionError: not equal:
a = 1240428288
b = 0

==
FAIL:
breezy.tests.test__dirstate_helpers.TestPackStat.test_ancient_mtime(dirstate_Pyrex)
--
Traceback (most recent call last):
testtools.testresult.real._StringException: Empty attachments:
  log

Traceback (most recent call last):
  File
"/usr/lib/python3/dist-packages/breezy/tests/test__dirstate_helpers.py",
line 1376, in test_ancient_mtime
self.assertEqual(1240428288, self.unpack_field(packed, "st_mtime"))
  File "/usr/lib/python3/dist-packages/breezy/tests/__init__.py", line
1317, in assertEqual
pprint.pformat(a), pprint.pformat(b)))
AssertionError: not equal:
a = 1240428288
b = 0

--
Ran 30634 tests in 198.010s

FAILED (failures=2, known_failure_count=66)



signature.asc
Description: OpenPGP digital signature

Bug#945848: RFS: tycho/1.2.0-1 [NMU] -- build Eclipse plugins with Maven

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-j...@lists.debian.org

Dear mentors,

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

 * Package name: tycho
   Version : 1.2.0-1
   Upstream Author : NA
 * URL : https://eclipse.org/tycho/
 * License : EPL-1.0
 * Vcs : https://salsa.debian.org/java-team/tycho
   Section : java

It builds those binary packages:

  libtycho-java - build Eclipse plugins with Maven

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/t/tycho/tycho_1.2.0-1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * Update to upstream tycho-1.2.0
   * Update to compat level 12
   * Standards Version updated to 4.4.1


-- 
Regards
Sudip

Bug#945847: materia-gtk-theme: New upstream release

[Vincent Blut]

Package: materia-gtk-theme
Version: 20190315-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Upstream released new versions providing, among other things, support 
for GNOME 3.34, so it would be really great to have an updated version 
in Debian.

Thanks for you work,
Vincent

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAl3hfpEXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4Dh+g//bOaj7s3wKNhxCTp3tcsUVP8q
2PttTXGPg+rWjPkGfEKlmKf6H0OIybha0bsmruYyLykbWIYf2SumJMnNurt5/W22
p6WZCDGJhWeNzQHPJooCkewBalJojS77pMev3DylD4gIT4EySd1WEP8GErKAvKIC
bNEByQ4CxPB6xOsxRgq3tAbH9ud1fCOjiIfW3HJy9DLiR37l2Mso20Rufrsb2gOj
wOtHQCLwRAMacVPWf89syWw1ACQlZJ3Mvp322LmBnyzKM2WaGJ4z9Cis5yEfAbSx
LRG2rEOXR7C86ycLtTooJcCn7bESMkjhdBTOoUvjbmoH+i3Atkq5U3XuSLmUhjEZ
yPVnqpLUkpf9w8rXnNGqZQxAmMaMhe/ShaGUt2QYWaXf6Ka96unP27tuVJCPyZhv
2T5fdYKgLjatybD3EMGbVV1ukaTRhUAmzNVbg4vud/KNK6fzvXXkt/bnmxK3aavf
/1tU12P7w2olzNUia0UNW3ZaKLIzFe0rbOGxoEo/2NnOLTWlEJM6OKee/rIaS9jr
Il1B248YPxETjiiCYao7c6ZVC0B1K7DCg1V9NKuNhGYLQ4DkpPVTfnj0xgv24RKd
HO9uLvE/iJQVRoVyrsug44cWy5HIHq3V75BgdMVxrryP6/LAHuLHyPPi6MfaoIjn
1j/RD610EOzWuJxEn40=
=8xOF
-END PGP SIGNATURE-

Bug#945542: [Pkg-rust-maintainers] Bug#945542: Bug#945542: debcargo -- Randomly adds and removes binary packages

[Ximin Luo]

Bastian Blank:
> [..]
> 
>> What solution would make you happy here? (or at least acceptable).
> 
> Stick to one binary package per source package.
> 
> The only point that shows up again and again are cycles, which don't
> pose a problem in the dpkg world.
> 

Whilst dpkg can install cycles, they only work well in special circumstances 
that don't apply to rust packages. For example where the same source package 
builds everything in the cycle, or where the source packages in question are 
very stable and essential e.g. glibc and gcc.

The reason is when building the source package you have to install all the 
Build-Depends. So if source package A and B depend on each other's binary 
packages, and A and B are not yet in Debian, you have no easy automated way of 
building them. You have to do the hacky manual bootstrap way where you sudo cp 
stuff into /usr. Doing this for 600 rust packages, and continuing to do this in 
the future, is not a standard I want to adopt for the Debian Rust team, and I 
don't think anyone would enjoy making this part of the normal process of making 
rust packages. There is also the issue that rust crate often change API 
compatibility, so occasionally you will have to rebootstrap cycles even if one 
of the packages exists already in the archive but at an older version.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#945846: task-kde-desktop: Use print-manager instead of system-config-printer for KDE installation task

[Shmerl]

Package: task-kde-desktop
Version: 3.55
Severity: wishlist

Dear Maintainer,

Currently, when selecting KDE in Debian installer, task-kde-desktop pulls in
system-config-printer for
printer settings, which is part of Gnome project and isn't well integrated with
KDE Plasma. Instead, it
should use print-manager, which provides printer settings in KDE's own System
Settings interface, and as
well allows printer queue access for active jobs in notifications area (system
tray).

Thanks!



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

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

Versions of packages task-kde-desktop depends on:
ii  kde-standard  5:104
ii  sddm  0.18.0-1
ii  task-desktop  3.55
ii  tasksel   3.55

Versions of packages task-kde-desktop recommends:
pn  apper   
ii  dragonplayer4:17.08.3-1
ii  gimp2.10.12-1
ii  hunspell-en-us  1:2018.04.16-1
ii  hyphen-en-us2.8.8-7
ii  k3b 18.08.1-1
ii  k3b-i18n18.08.1-1
ii  kdeaccessibility4:17.08.3+5.104
ii  libreoffice 1:6.3.3-3
ii  libreoffice-help-en-us  1:6.3.3-3
ii  libreoffice-kde51:6.3.3-3
ii  mythes-en-us1:6.3.1-1
ii  orca3.34.0-2
ii  plasma-nm   4:5.14.5-2
pn  system-config-printer   

task-kde-desktop suggests no packages.

-- no debconf information

Bug#945845: buster-pu: package qtwebengine-opensource-src/5.11.3+dfsg-2+deb10u1

[Dmitry Shachnev]

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

Dear Release team,

This update fixes bug #919504 that is also known as #929286, #931860, #933278
and #945147.

The debdiff is attached. Please see the header of the added patch for the
description of the fix.

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+qtwebengine-opensource-src (5.11.3+dfsg-2+deb10u1) buster; urgency=medium
+
+  * Fix PDF parsing by adding the missing non-const overrides for
+CPDF_Dictionary::GetDict() and CPDF_Reference::GetDict(). This also
+fixes QWebEnginePage::print() method (closes: #919504).
+
+ -- Dmitry Shachnev   Fri, 29 Nov 2019 23:04:08 +0300
+
 qtwebengine-opensource-src (5.11.3+dfsg-2) unstable; urgency=medium
 
   [ Dmitry Shachnev ]
--- /dev/null
+++ b/debian/patches/getdict-overrides.patch
@@ -0,0 +1,80 @@
+Description: fix GetDict methods in CPDF_Object descendants
+ In commit [1], Qt WebEngine developers backported a change to cpdf_object.h
+ that splits GetDict() virtual method into two: const and non-const.
+ .
+ However, this change was not applied to CPDF_Dictionary and CPDF_Reference
+ that are descendant classes of CPDF_Object. So they were missing the non-const
+ override, and the method from base class CPDF_Object was used instead (which
+ always returns nullptr).
+ .
+ In upstream PDFium, all files were changed in [2], so the bug was specific to
+ Qt WebEngine 5.11 (Chromium 65-based) branch.
+ .
+ [1]: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=bc188914f3ce1d2c
+ [2]: https://pdfium.googlesource.com/pdfium/+/7e28208d26764438
+Author: Dmitry Shachnev 
+Last-Update: 2019-11-29
+
+--- a/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_dictionary.cpp
 b/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_dictionary.cpp
+@@ -42,10 +42,12 @@ CPDF_Object::Type CPDF_Dictionary::GetTy
+   return DICTIONARY;
+ }
+ 
+-CPDF_Dictionary* CPDF_Dictionary::GetDict() const {
+-  // The method should be made non-const if we want to not be const.
+-  // See bug #234.
+-  return const_cast(this);
++CPDF_Dictionary* CPDF_Dictionary::GetDict() {
++  return this;
++}
++
++const CPDF_Dictionary* CPDF_Dictionary::GetDict() const {
++  return this;
+ }
+ 
+ bool CPDF_Dictionary::IsDictionary() const {
+--- a/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_dictionary.h
 b/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_dictionary.h
+@@ -33,7 +33,8 @@ class CPDF_Dictionary : public CPDF_Obje
+   // CPDF_Object:
+   Type GetType() const override;
+   std::unique_ptr Clone() const override;
+-  CPDF_Dictionary* GetDict() const override;
++  CPDF_Dictionary* GetDict() override;
++  const CPDF_Dictionary* GetDict() const override;
+   bool IsDictionary() const override;
+   CPDF_Dictionary* AsDictionary() override;
+   const CPDF_Dictionary* AsDictionary() const override;
+--- a/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_reference.cpp
 b/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_reference.cpp
+@@ -35,11 +35,16 @@ int CPDF_Reference::GetInteger() const {
+   return obj ? obj->GetInteger() : 0;
+ }
+ 
+-CPDF_Dictionary* CPDF_Reference::GetDict() const {
++CPDF_Dictionary* CPDF_Reference::GetDict() {
+   CPDF_Object* obj = SafeGetDirect();
+   return obj ? obj->GetDict() : nullptr;
+ }
+ 
++const CPDF_Dictionary* CPDF_Reference::GetDict() const {
++  const CPDF_Object* obj = SafeGetDirect();
++  return obj ? obj->GetDict() : nullptr;
++}
++
+ bool CPDF_Reference::IsReference() const {
+   return true;
+ }
+--- a/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_reference.h
 b/src/3rdparty/chromium/third_party/pdfium/core/fpdfapi/parser/cpdf_reference.h
+@@ -27,7 +27,8 @@ class CPDF_Reference : public CPDF_Objec
+   ByteString GetString() const override;
+   float GetNumber() const override;
+   int GetInteger() const override;
+-  CPDF_Dictionary* GetDict() const override;
++  CPDF_Dictionary* GetDict() override;
++  const CPDF_Dictionary* GetDict() const override;
+   bool IsReference() const override;
+   CPDF_Reference* AsReference() override;
+   const CPDF_Reference* AsReference() const override;
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ no-icudtl-dat.patch
 disable-last_commit_position.patch
 verbose-gn-bootstrap.patch
 fix-gcc-8-i386.patch
+getdict-overrides.patch


signature.asc
Description: PGP signature

Bug#945815: release.debian.org: unblock: ltsp/19.11-1

[Mike Gabriel]

Hi Vagrant, hi all,

On  Fr 29 Nov 2019 09:03:23 CET, Vagrant Cascadian wrote:


Package: release.debian.org
Severity: normal
X-Debbugs-CC: Vagrant Cascadian ,  
debian-b...@lists.debian.org, debian-...@lists.debian.org


The new version of LTSP no longer ships the ltsp-client-builder .udeb,
so it should be removed from the relevent block-udeb rules.


For Debian Edu, this will break the terminal server build variant, but  
that should be tolerable.



I believe debian-edu, the only user I'm aware of using the
ltsp-client-builder .udeb is working on updating to the newer version of
ltsp.

The ltsp-client-builder .udeb may also need to be removed from testing,
although it appears to be removed from sid, so maybe it's just a matter
of waiting for some cleanup processes?

Thanks all!


This week I did my first tests of the new LTSP rewrite and I am  
excited about how easy things have been reworked. Of course, we need  
to heavily adapt Debian Edu's way of setting up the LTSP server, but  
with the new release of LTSP, setup and also maintenance should be  
much easier than before.


Vagrant, please note that LTSP 19.11-1 fails at user login because of  
incompatibility with fuse3 (see #945521). The bug report comes with a  
patch and maybe you want to fix it first before having LTSP migrated  
to testing...


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp9Iw9YZByDx.pgp
Description: Digitale PGP-Signatur

Bug#943916: virt-manager: 2.2.1-2 not migrating

[Jonathan Rubenstein]

2.2.1-2 was uploaded to unstable as both a source and binary (all)
upload, and britney wants a source-only upload to cause a binary build
by buildd before it will be migrated to testing. This is listed as one
of the excuses.

Please consider uploading a new version with no changes as a
source-only upload so that the package will migrate to testing after 5
days.

On Thu, 31 Oct 2019 16:11:19 -0400 Jonathan Rubenstein
 wrote:
> Package: virt-manager
> Version: 2.2.1-2
> Severity: minor
> Tags: bullseye
>
> Version 2.2.1-2 was successfully uploaded to unstable, but isn't
> migrating to testing/bullseye. It's been blocked for 23 days. Excuses
> report not being built on buildd.
> https://qa.debian.org/excuses.php?package=virt-manager
>
> I am a testing user and am looking forward to the migration.
>
> Sincerely,
>
> Jonathan
>
>
>

Bug#945844: RM: lunch -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove lunch. The homepage vanished off the net, it's unmaintained (last
upload in 2011) and depends on Python 2.

Cheers,
Moritz

Bug#937695: reverse build depends still exist

[Paul Gevers]

Control: severity -1 normal

This package still has a reverse build depends. Let's not make this bug
RC just yet.

paul@testavoira ~ $ reverse-depends fontcustom -b
Reverse-Build-Depends
=
* fonts-fork-awesome

Paul



signature.asc
Description: OpenPGP digital signature

Bug#938318: fixed in qscintilla2 2.11.2+dfsg-1

[Gudjon I. Gudjonsson]

Hi Andrej

On Tuesday, 26 November 2019 15:49:33 CET Andrej Shadura wrote:
> On Wed, 02 Oct 2019 05:00:12 + gud...@gudjon.org (Gudjon I.
> Gudjonsson) wrote:
> > Source: qscintilla2
> > Source-Version: 2.11.2+dfsg-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > qscintilla2, which is due to be installed in the Debian FTP archive.
> 
> Hi, why did you ignore my message above asking to wait with this removal?

I'm very sorry. But Qscintilla wasn't uploaded to unstable until Nov 02 and 
accepted on
Nov 14 which is quite some time from your message dated Sept 17.

I hope upstream updates the program soon to python3 and you get it into 
Debian again.

Regards
Gudjon

Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

[Russ Allbery]

Bastian Blank  writes:

> The output of debcargo breaks the Debian archive by increasing the
> Package file much more then it needs to do.  Plus it can create
> oversized Provides lines.

Procedurally in Debian neither of these are justifications for setting the
severity to serious.  This is not a Policy requirement that has reached
consensus, and the release team is the team in Debian that has the
delegated responsibility to determine which bugs are release-critical for
the next release.

I realize that you're frustrated, and I suspect you're feeling like the
Rust package maintainers are not respecting something that you think is
obvious, but I don't think that fighting over the bug severity is the
right way to approach this disagreement in Debian.  If you feel that
you've reached an impasse in this discussion, this is what the Technical
Committee is for.

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

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Nicholas D Steeves]

Hi Sean,

Sean Whitton  writes:

> Hello Nicholas,
>
> I am not sure what is going on with your (1), (2) and (3).  Perhaps you
> could propose your change in the form of a patch.
>

Those numbers refer to annotations in the quoted portion.  IIRC you're
also using notmuch mode, so

  [ x more citation lines. Click/Enter to show. ]

Needs to be activated to make them visible.

At any rate, I've submitted an update MR here (see previous email for
extended rationale):

  https://salsa.debian.org/sten-guest/policy/merge_requests/3


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#932939: Confirmed bug 932939

[Aragon Gouveia]

Just writing to confirm the same behaviour with a Supermicro X10SRL-F.

main-menu segfaults at the beginning of d-i just after ethdetect runs 
and before a network interface is configured.


Changing PXE console kernel boot options from:
   console=tty0 console=ttyS0,115200n8
to:
   console=ttyS0,115200n8

works around the issue here too.

Hope this helps!

Bug#945831: RFS: libonig/6.9.4-1 --

[Adam Borowski]

Hi!

On Fri, Nov 29, 2019 at 02:16:34PM +0100, Jörg Frings-Fürst wrote:
>Package name: libonig
>Version : 6.9.4-1

> Changes since the last upload:
> 
>* Neu upstream release.
>  - Refresh symbols file and add Build-Depends-Package field.
>  - Remove upstream applied patches:
>+ 0105-CVE-2019-13224.patch
>+ 0110-CVE-2019-13225.patch
>  - Refresh debain/copyright.
>  - Fixes CVE-2019-19204: heap-buffer-overflow in fetch_interval_quantifier
>  due to double PFETCH (Closes: #945313).
>  - Fixes CVE-2019-19203: heap-buffer-overflow in gb18030_mbc_enc_len
>  (Closes: #945312).
>  - Fixes CVE-2019-19012: Out of bounds read in mbc_to_code()
>  (Closes: #944959).
>  - Fixes CVE-2019-16163: Stack Exhaustion Problem (Closes: #939988).
>  - Fixes CVE-2019-19246: heap-based buffer over-read in 
> str_lower_case_match.
>* debian/watch:_Correct typo.
>* Declare compliance with Debian Policy 4.4.1.1 (No changes needed).
>* Switch to debhelper-compat:
>  - debian/control: change to debhelper-compat (=12)
>  - remove debian/compat
>* debian/control:
>  - Add Rules-Requires-Root: binary-targets.

Is there a reason for binary-targets?  None of the binary packages ship any
files with non-standard owner, and I don't see anything else that would
require fakeroot.  Also, I've tried building the package with R³: no, and it
seems to build ok.  Am I missing something?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#945843: RFS: grdesktop/0.23+d040330-5 [QA] -- GNOME frontend for the rdesktop client

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the package "grdesktop".

 * Package name: grdesktop
   Version : 0.23+d040330-5
   Upstream Author : Thorsten Sauter 
 * URL : http://www.nongnu.org/grdesktop/
 * License : GPL-2+
 * Vcs : None
   Section : x11

It builds this binary package:

  grdesktop - GNOME frontend for the rdesktop client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/grdesktop/grdesktop_0.23+d040330-5.dsc

Changes since the last upload:

   * QA upload.
   * debian/patches/08_gsettings-port.diff: Fix regression in handling of
 the RDP protocol setting (Closes: #945842).  Thanks Thomas Hooge.

Bug#920118: [PATCH 0/2] moreutils: sponge: (not) attempt to preserve ownership

[Joey Hess]

I don't like complicating the man page with discussion of this. The
man page concisely and correctly documents the actual behavior.

Varying the behavior based on whether the user is root seems to just be
asking for trouble.

It does not emulate tee either; a non-root user who can write to a file
they don't own can tee to it and its owner will be preserved; tee simply
opens the file and writes over it.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Guillem Jover  writes:

> As I mentioned on debian-devel, I think major parts of this and of the
> sysuser stuff fall under dpkg realm. And my plan is to implement this
> kind of functionality natively in dpkg, regardless of whatever the
> outcome of that GR is.

> Of course some parts of the functionality needed to manage/track
> temporary pathnames requires integration or hooking into an init system
> or chroot/container manager, but that's true regardless of the
> implementation.

Could you say more about how you think dpkg would be able to handle
systemd-tmpfiles?  As you mention, this is something that has to be done
at every system boot, which seems pretty far afield from dpkg's domain.
Do you want to maintain custom dpkg plugins for every init system that a
dpkg system may support?  (My recollection is that dpkg supports other
OSes like Solaris.)

(systemd-sysusers is another matter and a bit more obviously doable with
dpkg, although if Sam's option three wins, I'd ask everyone in the
project, including you as dpkg maintainer, to consider the possible
benefits of using cross-distribution mechanisms instead of Debian-specific
mechanisms.)

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

Bug#945842: grdesktop: Debian patch for gsettings broken: wrong settings-name used

[Yavor Doganov]

Control: tags -1 + pending

Thomas Hooge wrote:
> The current debian patch for gsettings uses different settings
> names: rdp-protocol and rdp_protocol. So the setting ist never
> applied to the gui. The selection stays at protocol "Windows 2000".

Yes, GSettings does not allow keys with underscore, so this key has
been changed.  The problem here is that I also changed the key in the
hash table while I shouldn't.

Thanks for the report, I'll fix this shortly.

Bug#945587: [Pkg-freeipa-devel] Bug#945587: ipa complains about a locale that is not set

[Timo Aaltonen]

On 29.11.2019 14.45, Harald Dunkel wrote:
> Its a pretty huge effort to roll out a wrapper around freeipa to +300
> Hosts and keep it maintained for 2 years until Bullseye is released.
> 
> I am using freeipa-client on Debian for several years now. This problem
> never came up before, even though it was Python 2 as well, so I wonder if
> there could be another solution?
I don't know of one, you can ask on the upstream list if they have an idea.

-- 
t

Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards

[Chris Knadle]

Alexander Ponyatikh:
> Thank you. I was expecting that there should be a separate procedure for
> this case, but I could not find it. I've modified this bug report in
> accordance with the Developers' Reference.

Cool.  Yeah the "salvaging" procedure is relatively new and it's gone through a
few revisions over time.  When I had to salvage a package (mumble) in 2014 there
was no process for salvaging a package, so it was a lot more effort to adopt it,
and it took months.  I found out (as I think you have) that sometimes we end up
needing to support software ourselves if we want it to function.

> I've already put the original maintainer's address into the X-Debbugs-Cc
> filed of this report, so he's got a copy of the initial message.
> 
> I'll ask Andrej about sponsorship later, when 21 days have passed.

The maintainer replied and he's not against it being adopted (the word "again"
was used, but the context makes it clear it was meant to be "against"), so you
can proceed at any time.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#945842: grdesktop: Debian patch for gsettings broken: wrong settings-name used

[Thomas Hooge]

Package: grdesktop
Version: 0.23+d040330-3+b1
Severity: normal

The current debian patch for gsettings uses different settings names:
rdp-protocol and rdp_protocol. So the setting ist never applied to
the gui. The selection stays at protocol "Windows 2000".



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

Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8), LANGUAGE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages grdesktop depends on:
ii  gconf-service 3.2.6-4+b1
ii  gconf23.2.6-4+b1
ii  libart-2.0-2  2.3.21-2
ii  libatk1.0-0   2.22.0-1
ii  libbonobo2-0  2.32.1-3+b1
ii  libbonoboui2-02.24.5-4
ii  libc6 2.24-11+deb9u4
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgconf-2-4  3.2.6-4+b1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2+deb9u1
ii  libgnome-2-0  2.32.1-5+b1
ii  libgnomecanvas2-0 2.30.3-3
ii  libgnomeui-0  2.24.5-3.1
ii  libgnomevfs2-01:2.24.4-6.1+b2
ii  libgtk2.0-0   2.24.31-2
ii  libice6   2:1.0.9-2
ii  liborbit-2-0  1:2.14.19-2+b1
ii  libpango-1.0-01.40.5-1
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  libpopt0  1.16-10+b2
ii  libsm62:1.2.2-1+b3
ii  rarian-compat [scrollkeeper]  0.8.1-6+b1
ii  rdesktop  1.8.6-2~deb9u1

grdesktop recommends no packages.

grdesktop suggests no packages.

-- no debconf information

Bug#945841: rakarrack FTCBFS: error: unrecognized command line option ‘-msse2’

[Helmut Grohne]

Source: rakarrack
Version: 0.6.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rakarrack fails to cross build from source, because it detects sse
support from the build machine and passes e.g. -msse2 to an armhf
compiler when building on amd64. Disabling autodetection of sse is
tricky. The only way I found was exporting a non-empty SSE variable.
After doing so, it is globally disabled, so to retain sse2 support where
we want it, we must explicitly --enable-sse2 it. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru rakarrack-0.6.1/debian/changelog 
rakarrack-0.6.1/debian/changelog
--- rakarrack-0.6.1/debian/changelog2018-09-04 03:22:52.0 +0200
+++ rakarrack-0.6.1/debian/changelog2019-11-29 16:18:24.0 +0100
@@ -1,3 +1,10 @@
+rakarrack (0.6.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't autodetect sse/sse2. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Nov 2019 16:18:24 +0100
+
 rakarrack (0.6.1-5) unstable; urgency=medium
 
   * Add debian/patches/05_fix_segfault.diff to fix a segfault on
diff --minimal -Nru rakarrack-0.6.1/debian/rules rakarrack-0.6.1/debian/rules
--- rakarrack-0.6.1/debian/rules2011-12-27 17:07:55.0 +0100
+++ rakarrack-0.6.1/debian/rules2019-11-29 16:18:24.0 +0100
@@ -10,17 +10,7 @@
 #export DH_VERBOSE=1
 export DH_OPTIONS
 
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
-
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-DEB_HOST_ARCH_CPU  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
-
+include /usr/share/dpkg/architecture.mk
 
 builddir= build
 builddir_sse= build-sse
@@ -47,13 +37,15 @@
 $(builddir)/config.status:
 $(builddir_sse)/config.status:EXTRA_CONFIG_FLAGS += --enable-sse
 
+# exporting a non-empty SSE variable disables sse autodetection
 %/config.status: configure
dh_testdir
mkdir -p $*
$(RM) src/config.h
-   cd $* && ../configure --host=$(DEB_HOST_GNU_TYPE)   \
+   cd $* && SSE=" " ../configure --host=$(DEB_HOST_GNU_TYPE)   \
  --build=$(DEB_BUILD_GNU_TYPE) \
  --prefix=/usr \
+ $(if $(filter $(DEB_HOST_ARCH_CPU),amd64 
i386),--enable-sse2) \
  $(EXTRA_CONFIG_FLAGS)
 
 build: build-arch

Bug#945839: arbitrary file write vulnerability in pari/gpo

[wilfried.pascault]

Hi Bill, 

Thanks for your quick answer.

My bug entry was just to inform you =)

Regards, 

Wil

From: Bill Allombert [ballo...@debian.org]
Sent: Friday, November 29, 2019 4:47 PM
To: PASCAULT Wilfried OBS/OCD; 945...@bugs.debian.org
Subject: Re: Bug#945839: arbitrary file write vulnerability in pari/gpo

On Fri, Nov 29, 2019 at 03:16:37PM +, wilfried.pasca...@orange.com wrote:
> Package: pari
> Version: 2.11.1-2
>
> Georgi Guninski disclosed on Nov 26 a vulnerability on Full Disclosure [1].
>
> He's saying that pari/gp packages are vulnerable to an arbitrary code
> execution ; and mainstream package versions are vulnerable on Stretch
> and Buster.

Hello Wilfried,

Georgi Guninski is mistaken.
gp is a language interpretor like bash, perl and python.
They all allow arbitrary code execution.
The ability to write files and run arbitrary code is a feature and not a bug.
GP is not documented as providing an environment with security
properties, so there cannot be a vulnerability.

Cheers,
--
Bill. 

Imagine a large red swirl here.

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards

[Chris Knadle]

Giacomo Catenazzi:
> Hello Chris,
> 
> Alexander already asked me about packages, and I have nothing again getting it
> adopted.  Just I had no time (and hardware) to handle the packages, and the 
> lack
> of upstream worries my a lot (e.g. security, but also upgrading support 
> libraries).
> 
> ciao
> cate

Hello cate.

I understand.  These situations happen.  Thanks for your reply.

For situations where the maintainer does not have time to deal with packages,
there's a procedure to follow for that described here in section 5.9.4 of the
Developer's Reference:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning

As the procedure describes, this could be filing RFA: bugs or orphaning
the packages.  Orphaning the packages would help others adopt the packages
without needing to contact you first.

Thanks
   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#742931: RFP: alaveteli -- free software to help citizens write Freedom of Information requests and automatically publish any responses

[Calum]

I don't know that this is software well-suited to packaging. It's server-side,
and intended to be highly customized: it appears that they are distributing a
basic outline for a FOI website, not a software that creates more FOI websites.
On Sat, 29 Mar 2014 03:51:27 +0200 Bob Bib  
wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name : alaveteli
> Version : 0.17
> Upstream Author : 
> http://www.alaveteli.org/contact/
> * URL : http://www.alaveteli.org/
> * License : AGPL
> Programming Lang: Ruby
> Description : free software to help citizens write Freedom of Information
> requests and automatically publish any responses
>
> Alaveteli is free Social Email software
>
> It’s a simple concept: citizens use Alaveteli to request information,
> and the replies are recorded for all to see on the website.
> The project’s initial focus is on making Freedom of Information requests,
> although it can easily be altered for other purposes. Funded by
> the Open Society Institute and the Hivos Foundation, in its first year
> the project aims to support the launch of dozens of FOI websites around
> the world.
>
> Historic requests, along with any resulting correspondence, are archived
> publicly online. This increases the availability of the requested information,
> and encourages transparency. Therefore, Alaveteli acts both as a useful tool
> for citizens, and as an advocacy tool for right-to-know campaigners.
>
> Stable releases can be found on GitHub:
> 
>https://github.com/mysociety/alaveteli/releases
>
> Wikipedia article:
> http://en.wikipedia.org/wiki/Alaveteli
>
> 
> Best wishes, Bob
>
>

Bug#945839: arbitrary file write vulnerability in pari/gpo

[Bill Allombert]

On Fri, Nov 29, 2019 at 03:16:37PM +, wilfried.pasca...@orange.com wrote:
> Package: pari
> Version: 2.11.1-2
> 
> Georgi Guninski disclosed on Nov 26 a vulnerability on Full Disclosure [1].
> 
> He's saying that pari/gp packages are vulnerable to an arbitrary code
> execution ; and mainstream package versions are vulnerable on Stretch
> and Buster.

Hello Wilfried,

Georgi Guninski is mistaken.
gp is a language interpretor like bash, perl and python.
They all allow arbitrary code execution.
The ability to write files and run arbitrary code is a feature and not a bug.
GP is not documented as providing an environment with security
properties, so there cannot be a vulnerability.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Kiko Piris]

Package: ledger
Version: 3.1.2+dfsg1-1
Severity: grave
Justification: renders package unusable

The subject really says it all. Invoking ledger fails with the mentioned error:

/usr/bin/ledger: error while loading shared libraries: 
libboost_python27.so.1.67.0: cannot open shared object file: No such file or 
directory

ldd shows the missing library:

$ ldd /usr/bin/ledger
linux-vdso.so.1 (0x7fffa1958000)
libledger.so.3 => /usr/lib/ledger/libledger.so.3 (0x7f745af4)
libboost_filesystem.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 (0x7f745af08000)
libboost_system.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f745af01000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 
(0x7f745ab95000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f745a9bc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f745a9a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f745a7e)
libmpfr.so.6 => /usr/lib/x86_64-linux-gnu/libmpfr.so.6 
(0x7f745a75e000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7f745a6db000)
libboost_iostreams.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f745a6bd000)
libboost_regex.so.1.67.0 => 
/usr/lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f745a587000)
libboost_python27.so.1.67.0 => not found
libicuuc.so.63 => /usr/lib/x86_64-linux-gnu/libicuuc.so.63 
(0x7f745a3b5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f745a27)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f745a24f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f745a232000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f745a22d000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f745a228000)
/lib64/ld-linux-x86-64.so.2 (0x7f745b54)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f745a213000)
libicui18n.so.63 => /usr/lib/x86_64-linux-gnu/libicui18n.so.63 
(0x7f7459f38000)
libicudata.so.63 => /usr/lib/x86_64-linux-gnu/libicudata.so.63 
(0x7f7458547000)

Please, reassign the bug to whatever package it belongs (if it’s not ledger).

Thanks.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER
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)

Versions of packages ledger depends on:
ii  libboost-filesystem1.67.0  1.67.0-15
ii  libboost-iostreams1.67.0   1.67.0-15
ii  libboost-python1.67.0  1.67.0-15
ii  libboost-regex1.67.0   1.67.0-15
ii  libboost-system1.67.0  1.67.0-15
ii  libc6  2.29-3
ii  libgcc11:9.2.1-20
ii  libgmp10   2:6.1.2+dfsg-4
ii  libicu63   63.2-2
ii  libmpfr6   4.0.2-1
ii  libpython2.7   2.7.17-1
ii  libstdc++6 9.2.1-20

ledger recommends no packages.

Versions of packages ledger suggests:
pn  elpa-ledger
pn  python-ledger  

-- no debconf information

Bug#945596: systemd module does not include the new systemd-volatile-root of systemd 242+

[Enrico Zini]

On Wed, Nov 27, 2019 at 05:43:25PM +0100, Thomas Lange wrote:

> If you add the parameter rootovl to the kernel cmdline, the initrd
> created by dracut will make a read only rootfs writable by putting a
> tmpfs on top. This also works when using an nfsroot.

I tried it and it works, although on the raspberry pi one also needs to
do something like this, or the overlay module doesn't end up in the
rootfs:

echo "filesystems+=overlay" > /etc/dracut.conf.d/overlay.conf

However, at boot I do quickly get this warning line: 

   dracut-pre-pivot: mount: /sysroot: mount point not mounted or bad option.

which can later also be seen in systemctl status:

   $ systemctl status dracut-pre-pivot.service
   ● dracut-pre-pivot.service - dracut pre-pivot and cleanup hook
  Loaded: loaded 
(/usr/lib/dracut/modules.d/98dracut-systemd/dracut-pre-pivot.service; static; 
vendor preset: enabled)
  Active: inactive (dead)
Docs: man:dracut-pre-pivot.service(8)
   
   Feb 14 11:12:01 himblick systemd[1]: Starting dracut pre-pivot and cleanup 
hook...
   Feb 14 11:12:01 himblick dracut-pre-pivot[258]: mount: /sysroot: mount point 
not mounted or bad option.
   Feb 14 11:12:01 himblick systemd[1]: Started dracut pre-pivot and cleanup 
hook.
   Feb 14 11:12:01 himblick systemd[1]: dracut-pre-pivot.service: Succeeded.
   Feb 14 11:12:01 himblick systemd[1]: Stopped dracut pre-pivot and cleanup 
hook.

It seems innocuous so far, but I couldn't track down what gives the
error, and I would at some point like to be able to suppress the noise.

I realise none of this is on topic with this issue, and I'm not sure
it's worth to open a new issue for this.


Enrico

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

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[Frank Doepper]

Hi.

Am 29.11.19 um 07:12 schrieb intrigeri:

> Carsten Schoenert:
> > Adding as a quick test a line
>
> > export DICPATH=/usr/share/hunspell
>
> > to the wrapper script /usr/bin/thunderbird brings back all the
> > dictionaries I've installed long ago.
>
> Note that the same issue in Firefox was fixed like this:
>
>   * debian/browser.links.in, debian/rules, debian/vendor.js: Use the
> spellchecker.dictionary_path pref to set the hunspell directory.
>
> I confirm that setting this pref fixes the problem with Thunderbird 68:
>
>   pref("spellchecker.dictionary_path", "/usr/share/hunspell");
>
> I'll let Carsten decide whether that's any better than setting
> $DICPATH :)

I tried both, and in my case only setting $DICPATH fixed the issue.
Setting the pref did nothing. I must note that I added that as user_pref
in the user profile, not in a system-wide pref.

Viele Grüße,
Frank

Bug#945542: [Pkg-rust-maintainers] Bug#945542: Bug#945542: debcargo -- Randomly adds and removes binary packages

[Bastian Blank]

On Fri, Nov 29, 2019 at 02:49:21PM +0100, Sylvestre Ledru wrote:
> Le 29/11/2019 à 14:07, Bastian Blank a écrit :
> > The output of debcargo breaks the Debian archive by increasing the
> > Package file much more then it needs to do.
> Breaks seems a strong word, no?

It adds bloat to the Packages file in a volume that is not longer
considered acceptable.

I assume you know the difference between doing something once or doing
something a thousand times.

> We have at least 680 rust source packages in the archive currently, we 
> shipped buster with more than 500 Rust packages.

So would setting a limit to 500 rust source packages in the archive
at the same time help?

> What solution would make you happy here? (or at least acceptable).

Stick to one binary package per source package.

The only point that shows up again and again are cycles, which don't
pose a problem in the dpkg world.

> > Plus it can create oversized Provides lines.
> This is extremely rare. Not sure it is deserve a serious severity.
> There are only 3 packages with Provides longer than 5k: oca-core, 
> librust-web-sys-dev, librust-winapi-dev

Sure, but the 256k example that showed up shows that the algorithm used
to generate it can produce problematic output.

Regards,
Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, "Errand of Mercy", stardate 3198.4

Bug#945839: arbitrary file write vulnerability in pari/gp

[wilfried.pascault]

Package: pari
Version: 2.11.1-2


Georgi Guninski disclosed on Nov 26 a vulnerability on Full Disclosure [1].

He's saying that pari/gp packages are vulnerable to an arbitrary code execution 
; and mainstream package versions are vulnerable on Stretch and Buster.

On DST pari/gp page [2] ; there is no information about this issue or any bugid.

Thanks in advance.

---
pari/gp on debian stable allow arbitrary file write

pari/gp is CAS (computer algebra system).
pari/gp version 2.9.1 on debian stretch and 2.11 on debian buster
allow arbitrary file write and hence arbitrary code execution.

poc:

\\ a.gp
\\ to run: \r a.gp
default("logfile","/tmp/a.txt");default("log",1);print("log(1)");


Of mathematical interest is pari was missing solutions
to Thue equations when assuming GRH (the fix changed polynomial
bound to exponential bound):
http://pari.math.u-bordeaux.fr/archives/pari-dev-1207/msg0.html
t=thue(thueinit(x^3+92*x+1,0),3^3);t

---

Regards,

Wil

[1] hxxps://seclists.org/fulldisclosure/2019/Nov/25
[2] hxxps://security-tracker.debian.org/tracker/source-package/pari



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#944243: logrotate fails with "Permission denied" on LXC guest

[Lukáš Jelínek]

Thanks very much for this workaround. It works well.

But I think it is a bug because it prevents Debian 10 in LXC containers
to work out-of-the-box in many cases and requires manual hardcore
intervention (in a file which is not intended to be "cut-and-dry"
modified by administrators).


> Le mercredi 06 novembre 2019 à 17:27:28+0100, Lukáš Jelínek a écrit :
>> journalctl -u logrotate:
>>
>> Nov 06 17:12:22 syslog systemd[1]: Starting Rotate log files...
>> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed to set up 
>> mount namespacing: Permission denied
>> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed at step 
>> NAMESPACE spawning /usr/sbin/logrotate: Permission denied
>> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Main process exited, 
>> code=exited, status=226/NAMESPACE
>> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Failed with result 
>> 'exit-code'.
>> Nov 06 17:12:22 syslog systemd[1]: Failed to start Rotate log files.
>>
>>
>> systemctl status logrotate
>>
>> ● logrotate.service - Rotate log files
>>Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor 
>> preset: enabled)
>>Active: failed (Result: exit-code) since Wed 2019-11-06 17:12:22 CET; 
>> 11min ago
>>  Docs: man:logrotate(8)
>>man:logrotate.conf(5)
>>   Process: 381 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf 
>> (code=exited, status=226/NAMESPACE)
>>  Main PID: 381 (code=exited, status=226/NAMESPACE)
>>
>> Nov 06 17:12:22 syslog systemd[1]: Starting Rotate log files...
>> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed to set up 
>> mount namespacing: Permission denied
>> Nov 06 17:12:22 syslog systemd[381]: logrotate.service: Failed at step 
>> NAMESPACE spawning /usr/sbin/logrotate: Permission denied
>> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Main process exited, 
>> code=exited, status=226/NAMESPACE
>> Nov 06 17:12:22 syslog systemd[1]: logrotate.service: Failed with result 
>> 'exit-code'.
>> Nov 06 17:12:22 syslog systemd[1]: Failed to start Rotate log files.
> The systemd service file for logrotate has hardening options[0] that can't
> run properly in an unprivileged container (and could also run badly in a
> privileged one).
>
> It's not really what I'd call a bug. It's more like a limitation for the
> current way things are designed.
>
> [0] cat /lib/systemd/system/logrotate.service
>
> [...]
> PrivateDevices=true
> PrivateTmp=true
> ProtectControlGroups=true
> ProtectKernelModules=true
> ProtectSystem=full
> [...]
>
> If you wish to have things work properly in your container, there are a
> couple of solutions. One of these is to systemctl edit logrotate.service
> and put this:
>
> [Service]
> PrivateDevices=false
> PrivateTmp=false
> ProtectControlGroups=false
> ProtectKernelModules=false
> ProtectSystem=false
>
> Save and then you should be good (may take a systemctl daemon-reload,
> though).
>
> It's plausible that you don't have to disable all hardening options, I'm
> merely pointing these, but maybe some work properly in your container.
> It's up to you to get which one is the problem.
>
> man systemd.exec to get the description of the effect of each these
> options.
>
> Cheers.
>



smime.p7s
Description: Elektronicky podpis S/MIME

Bug#945248: www.debian.org: 'How to download an image with jigdo' uses obsolete terms and references

[Steve McIntyre]

Hi Tom,

Thanks for reporting...

On Thu, Nov 21, 2019 at 01:45:24PM -0700, Tom Roche wrote:
>Package: www.debian.org
>Severity: important
>Tags: newcomer
>
>Dear Maintainer,
>
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>>* What led up to the situation?
>
>Preparing to install Debian on a PC, haven't done that for a few years. (Hence 
>the downlevel of this box.)
>
>>* What exactly did you do (or not do) that was effective (or ineffective)?
>
>I RTFMed, and found information about `jigdo`, which I had not previously 
>used. Specifically I looked @
>
>https://www.debian.org/CD/jigdo-cd/#how
>
>which currently has the following HTML:
>
>- How to download an image with jigdo
>- 
>-   Download a package containing jigdo-lite, which is
>-   available for GNU/Linux, Windows and Solaris from the
>-   http://atterer.org/jigdo/;>jigdo homepage. For FreeBSD,
>-   install from /usr/ports/net-p2p/jigdo or grab the package with pkg_add
>-   -r jigdo.
>-   
>
>There are 2 problems with this text:
>
>1. The current package name=`jigdo-file` (per, e.g., 
>https://packages.debian.org/search?keywords=jigdo), not `jigdo-lite`. This 
>error is repeated several times in subsequent text on that webpage.
>
>2. The current jigdo homepage=https://www.einval.com/~steve/software/jigdo/ 
>per the old homepage=http://atterer.org/jigdo/ cited above, which says (again, 
>HTML)
>
>> I have stopped development on this software long ago. But luckily, 
>> Steve McIntyre has taken over development - thanks Steve! 
>> Please head to > href="https://www.einval.com/~steve/software/jigdo/;>einval.com for a forked 
>> jigdo version with new features.

Right. That's literally just happened a few days (hours?) before you
reported. I'm just in the middle of making some major changes in the
jigdo world, and I'll be updating the Debian website text to match
shortly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.

Bug#945837: unattended-upgrades: packages kept back not listed in unattended-upgrades.log

[Ken Takusagawa]

Package: unattended-upgrades
Version: 1.15
Severity: normal

Dear Maintainer,

My motd currently reports:

7 updates could not be installed automatically. For more details,
see /var/log/unattended-upgrades/unattended-upgrades.log

(this is the output of
/usr/share/unattended-upgrades/update-motd-unattended-upgrades )

However, there is no useful information in that log file.  Here is the
result of two manual invocations of "sudo unattended-upgrade" with no
flags.  Note well, there is nothing reported in "Packages that are
kept back"

2019-11-29 09:09:45,219 INFO Initial blacklist: 
2019-11-29 09:09:45,222 INFO Initial whitelist: 
2019-11-29 09:09:45,222 INFO Starting unattended upgrades script
2019-11-29 09:09:45,223 INFO Allowed origins are: o=Debian,a=testing
2019-11-29 09:09:55,518 INFO Removing unused kernel packages: 
linux-image-5.2.0-2-amd64
2019-11-29 09:10:42,322 INFO Packages that were successfully auto-removed: 
linux-image-5.2.0-2-amd64
2019-11-29 09:10:42,323 INFO Packages that are kept back: 
2019-11-29 09:10:42,902 INFO Packages that will be upgraded: gir1.2-ibus-1.0 
libibus-1.0-5 libio-async-perl libv4l-0 libv4lconvert0 sensible-utils
2019-11-29 09:10:42,903 INFO Writing dpkg log to 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2019-11-29 09:11:41,873 INFO All upgrades installed
2019-11-29 09:14:19,581 INFO Initial blacklist: 
2019-11-29 09:14:19,584 INFO Initial whitelist: 
2019-11-29 09:14:19,585 INFO Starting unattended upgrades script
2019-11-29 09:14:19,585 INFO Allowed origins are: o=Debian,a=testing
2019-11-29 09:14:24,099 INFO Packages that will be upgraded: 


However, there are packages that are failing to install.  Here is "apt
full-upgrade -s"

NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  fuse
The following NEW packages will be installed:
  fuse3
The following packages will be upgraded:
  gvfs gvfs-backends gvfs-common gvfs-daemons gvfs-fuse gvfs-libs sshfs
7 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.


Only after manually running "sudo unattended-upgrade -d" do I get
useful information in the log file.  Here are some excerpts:

2019-11-29 09:14:52,719 DEBUG Checking: gvfs ([])
2019-11-29 09:14:52,957 DEBUG sanity check failed for: 
{'gvfs-daemons=1.42.1-3', 'gvfs-fuse=1.42.1-3', 'gnome=1:3.30+2', 
'gvfs-backends=1.42.1-3', 'gnome-core=1:3.30+2', 'gvfs-libs=1.42.1-3', 
'gvfs=1.42.1-3', 'task-gnome-desktop=3.55', 'gvfs-common=1.42.1-3'} : pkg 
gvfs-fuse is marked to be deleted
...
2019-11-29 09:14:54,563 DEBUG Checking: gvfs-fuse ([])
2019-11-29 09:14:54,780 DEBUG sanity check failed for: {'fuse=2.9.9-2', 
'gvfs-daemons=1.42.1-3', 'gvfs-fuse=1.42.1-3', 'gvfs-backends=1.42.1-3', 
'fuse3=3.7.0-1', 'gvfs-libs=1.42.1-3', 'gvfs=1.42.1-3', 'gvfs-common=1.42.1-3'} 
: pkg fuse is marked to be deleted

   * What outcome did you expect instead?

If packages are not being installed because other packages must be
deleted, that's fine.  But the log file should explicitly state so,
including listing the affected packages.

It seems it would be a fairly simple matter to simply print out into
the log file the contents of /var/lib/unattended-upgrades/kept-back .

I also suspect that if the only reason packages are being held back is
because a failing sanity check, then there is a bug in earlier in the
unattended-upgrade script.

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


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

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

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

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-135
ii  systemd-sysv243-8

Versions of packages unattended-upgrades suggests:
pn  bsd-mailx   
pn  default-mta | mail-transport-agent  
pn  needrestart 
ii  powermgmt-base  1.36
ii  python3-gi  3.34.0-3

-- Configuration Files:
/etc/logrotate.d/unattended-upgrades changed:

Bug#945836: zanshin does not built with new KDEPIM 19.08

[Sandro Knauß]

Package: zanshin
Version: 0.5.0-2+b1
Severity: normal
Tags: patch
Control: block 945619 by -1

Hey,

zanshin doesn't built with KDEPIM 19.08 (currently waiting in experimental).
Mostly because KCalCore got a cleanup and API change in order to move to KDE 
Frameworks.
I requested a merge request (!1) on salsa to fix that.

hefee

!1: https://salsa.debian.org/qt-kde-team/extras/zanshin/merge_requests/1


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

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

Versions of packages zanshin depends on:
ii  kio  5.62.1-2
ii  libc62.29-3
ii  libgcc1  1:9.2.1-19
pn  libkf5akonadicalendar5   
pn  libkf5akonadicalendar5-18.08 
ii  libkf5akonadicalendar5abi1   4:19.08.2-1~
ii  libkf5akonadicontact54:19.08.2-1~
pn  libkf5akonadicontact5-18.08  
pn  libkf5akonadicore5   
pn  libkf5akonadicore5-18.08 
ii  libkf5akonadicore5abi2   4:19.08.2-1~
ii  libkf5akonadinotes5  4:19.08.2-1~
pn  libkf5akonadinotes5-18.08
ii  libkf5akonadisearchpim5  4:19.08.2-1~
pn  libkf5akonadisearchpim5-18.08
pn  libkf5akonadiwidgets5
pn  libkf5akonadiwidgets5-18.08  
ii  libkf5akonadiwidgets5abi14:19.08.2-1~
pn  libkf5calendarcore5  
pn  libkf5calendarcore5-18.08
ii  libkf5calendarcore5abi2  4:19.08.2-1~
ii  libkf5codecs55.62.0-1
ii  libkf5completion55.62.0-1
ii  libkf5configcore55.62.0-1
ii  libkf5configgui5 5.62.0-1
ii  libkf5configwidgets5 5.62.0-1
ii  libkf5contacts5  4:19.08.2-1~
pn  libkf5contacts5-18.08
ii  libkf5coreaddons55.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libkf5identitymanagement519.08.2-1~
pn  libkf5identitymanagement5-18.08  
ii  libkf5itemmodels55.62.0-1
ii  libkf5itemviews5 5.62.0-1
ii  libkf5jobwidgets55.62.0-1
ii  libkf5kdelibs4support5   5.62.0-2
ii  libkf5kiocore5   5.62.1-2
ii  libkf5kontactinterface5  19.08.2-1~
pn  libkf5kontactinterface5-18.08
pn  libkf5ldap5  
pn  libkf5ldap5-18.08
ii  libkf5ldap5abi1  19.08.2-1~
pn  libkf5mime5  
pn  libkf5mime5-18.08
ii  libkf5mime5abi1  19.08.2-1~
ii  libkf5parts5 5.62.0-1
ii  libkf5runner55.62.0-1
ii  libkf5wallet-bin 5.62.0-1
ii  libkf5wallet55.62.0-1
ii  libkf5widgetsaddons5 5.62.0-1
ii  libkf5windowsystem5  5.62.0-2
ii  libkf5xmlgui55.62.0-1+b1
ii  libqt5core5a 5.12.5+dfsg-2
ii  libqt5dbus5  5.12.5+dfsg-2
ii  libqt5gui5   5.12.5+dfsg-2
ii  libqt5network5   5.12.5+dfsg-2
ii  libqt5widgets5   5.12.5+dfsg-2
ii  libstdc++6   9.2.1-19

zanshin recommends no packages.

zanshin suggests no packages.

Bug#945775: python-sponge: should this package be removed.

[Mattia Rizzolo]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: python-sponge -- RoQA; RC buggy, unmaintained, low 
popcon


On Thu, Nov 28, 2019 at 01:33:25PM +, peter green wrote:
> To me this adds up to a package that is not in a fit state to remain
> in Debian, if noone disagrees I will likely convert this bug to a
> removal request in the not too distant future.

Sure, let's do this already!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#945835: firewalld: New point release available with important bugfixes

[Wiebe Verweij]

Package: firewalld
Version: 0.6.3-5
Severity: important

Dear Maintainer,

Please consider updating this package to the latest point release firewalld, it 
includes numerous bugfixes.

For example, using ipsets with the nftables backend in the version packaged is 
broken because entries don't get added properly.
This is fixed by ipset: fix set apply if IndividualCalls=yes in the latest 
point release.

Also see the release notes: 
https://firewalld.org/2019/05/firewalld-0-6-4-release

Kind regards,

Wiebe Verweij.

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

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

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


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/3 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 firewalld depends on:
ii  dbus 1.12.16-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  init-system-helpers  1.56+nmu1
ii  iptables 1.8.3-2~bpo10+1
ii  policykit-1  0.105-25
ii  python3  3.7.3-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
ii  ipset  6.38-1.2

firewalld suggests no packages.

-- no debconf information

Bug#945834: ITP: trisycl -- Generic system-wide modern C++ for heterogeneous platforms with SYCL from Khronos Group

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: trisycl
  Version : x.y.z
  Upstream Author : Name 
* URL : https://github.com/triSYCL/triSYCL
* License : LLVM/UIUC
  Programming Lang: C++/SYCL
  Description : Generic system-wide modern C++ for heterogeneous platforms 
with SYCL from Khronos Group

Seemed to me that intel is going to use SYCL for both their FPGA and the
GPUs[1]. So I think it could be interesting the investigate the sycl
implementations.

An informative diagram about SYCL implementations:
https://github.com/illuhad/hipSYCL#why-use-hipsycl-over-raw-cudahip

This ITP means that I'm interested in investigating the SYCL
implementations. But it doesn't mean that I'll really begin the
debianization soon.

[1] https://github.com/intel/BaseKit-code-samples.git

Bug#945833: kguiaddons: kmodifierkey_xcb.so is not providev by .deb

[luca]

Source: kguiaddons
Version: 5.62
Severity: normal

Dear Maintainer,

there are several bugreport involving plasma_engine_keystate that after latest
updates stops working.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942429
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941505
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940872

sddm theme capslock alert, systemsettings numlocks on/off at start,
keyboardindicator and all plasmoids using keystate engine stop working.

Investigating it seems that kmodifierkey_xcb.so is missing.

on my system I've solved rebuilding kguiaddons-5.62 after add

usr/lib/*/qt5/plugins/kf5/kguiaddons/kmodifierkey/kmodifierkey_xcb.so
to
libkf5guiaddons5.install

Best, Luca.



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

Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Bug#945534: virtualbox-source: Module FTBFS on Linux 5.4 due to set_pages_x

[Kevin]

found 945534 6.0.14-dfsg-3
thanks

The changelog for 6.0.14-dfsg-3 mentions including rev 81586 and
81587.  Thanks for the fast action!  However, I don't see the changes
in the orig.tar.xz or in debian/patches and the build still fails for
me with the same error.  Can you confirm?

Thanks,
Kevin

Bug#945542: [Pkg-rust-maintainers] Bug#945542: Bug#945542: debcargo -- Randomly adds and removes binary packages

[Ximin Luo]

Bastian Blank:
> Hi Ximin
> 
> On Fri, Nov 29, 2019 at 12:24:38PM +, Ximin Luo wrote:
>>> On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
>>> Please stop fiddling with severities.
>> The maintainer of a package decides the severities and whether things are 
>> bugs or not. Neither have you provided a justification for "serious", it is 
>> not breaking anything.
> 
> The output of debcargo breaks the Debian archive by increasing the
> Package file much more then it needs to do.  Plus it can create
> oversized Provides lines.
> 
>> Manual cost, nobody is going to want to do this work. Do you want to do this 
>> work?
> 
> No idea what manual work you are talking about.  Of course I can modify
> debcargo and rip the code out to create the surplus packages.
> 
> I would have preferred it if you would do that yourself, but if you ask:
> yes, I will delete that code from debcargo.
> 

I don't understand what point you are making here. If you delete code from dpkg 
without thinking about the consequences, stuff is going to break.

Likewise, deleting code from debcargo like you're saying here, is going to 
break things. Fixing these breakages without simply undoing your deletion, will 
involve much more manual work.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#945832: iprange FTCBFS: help2man

[Helmut Grohne]

Source: iprange
Version: 1.0.4+ds-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

iprange fails to cross build from source, because it uses help2man. The
best way to avoid that is shipping a real manual page. The second best
way is building twice: Once for help2man and once for real. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru iprange-1.0.4+ds/debian/changelog 
iprange-1.0.4+ds/debian/changelog
--- iprange-1.0.4+ds/debian/changelog   2018-12-31 12:16:45.0 +0100
+++ iprange-1.0.4+ds/debian/changelog   2019-11-29 14:11:28.0 +0100
@@ -1,3 +1,10 @@
+iprange (1.0.4+ds-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build twice for help2man. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Nov 2019 14:11:28 +0100
+
 iprange (1.0.4+ds-2) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru iprange-1.0.4+ds/debian/rules iprange-1.0.4+ds/debian/rules
--- iprange-1.0.4+ds/debian/rules   2018-05-18 07:46:22.0 +0200
+++ iprange-1.0.4+ds/debian/rules   2019-11-29 14:11:28.0 +0100
@@ -9,4 +9,14 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-maintainer-mode
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure -- 
--enable-maintainer-mode
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+# help2man support. First build natively in maintainer mode, then build for
+# real keeping the manual page.
+override_dh_auto_build:
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build
+   dh_auto_clean
+   dh_auto_configure -- --disable-maintainer-mode
+   dh_auto_build
+endif

Bug#945542: [Pkg-rust-maintainers] Bug#945542: Bug#945542: debcargo -- Randomly adds and removes binary packages

[Sylvestre Ledru]

Le 29/11/2019 à 14:07, Bastian Blank a écrit :

Hi Ximin

On Fri, Nov 29, 2019 at 12:24:38PM +, Ximin Luo wrote:

On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
Please stop fiddling with severities.

The maintainer of a package decides the severities and whether things are bugs or not. 
Neither have you provided a justification for "serious", it is not breaking 
anything.


The output of debcargo breaks the Debian archive by increasing the
Package file much more then it needs to do. 

Breaks seems a strong word, no?

We have at least 680 rust source packages in the archive currently, we shipped 
buster with more than 500 Rust packages.
For now, I only seen a few ftpmasters complaining about the current packaging 
strategy (but maybe I missed users complaining about this).
Despite this, Thorsten and a few other (I saw some trainees) did an amazing job 
keeping up with the incoming flow of NEW rust packages.

What solution would make you happy here? (or at least acceptable).
To start with, we could trim the description in the library crates.


Plus it can create oversized Provides lines.

This is extremely rare. Not sure it is deserve a serious severity.
There are only 3 packages with Provides longer than 5k: oca-core, 
librust-web-sys-dev, librust-winapi-dev

Source:
$ grep-dctrl -FProvides -e '.{5000}' -sPackage < 
/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_binary-amd64_Packages

Cheers,
Sylvestre

Bug#945826: Server fails for missing boost library

[Stephen Kitt]

Control: severity -1 grave

Hi Lars,

Le 29/11/2019 11:10, Lars Dölle a écrit :

the package seems to be a victim of an upgrade of the boost libraries.

| $ ldd /usr/lib/freeorion/freeoriond
| ...
| libboost_python27.so.1.67.0 => not found
| ...


Thanks for filing this! Strictly speaking, freeorion is a victim of the 
removal of Python 2 support from the Boost packages: 
https://bugs.debian.org/936227


So this is effectively a duplicate of https://bugs.debian.org/936557 but 
I think it’s useful to keep it open separately, especially given that 
the severities are different (this bug is grave).


Regards,

Stephen

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Guillem Jover]

On Fri, 2019-11-22 at 10:12:06 -0800, Russ Allbery wrote:
> Ansgar  writes:
> > I think no option says we shouldn't use services that don't rely on
> > systemd as pid-1 (which also includes widely used things like udev).
> 
> I agree, but if, say, Sam's option 3 wins, we can directly incorporate
> this, whereas if, say, Ian's option wins, then we should have a
> conversation with the sysvinit maintainers to see if they believe they can
> adopt systemd-tmpfiles directly, and we should give them at least six
> months (obviously shortened if it happens sooner) to update the packaging
> and set up a mechanism to run systemd-tmpfiles (or a replacement of their
> choice) at boot.

As I mentioned on debian-devel, I think major parts of this and of
the sysuser stuff fall under dpkg realm. And my plan is to implement
this kind of functionality natively in dpkg, regardless of whatever
the outcome of that GR is.

Of course some parts of the functionality needed to manage/track
temporary pathnames requires integration or hooking into an init system
or chroot/container manager, but that's true regardless of the
implementation.

Thanks,
Guillem

Bug#945831: RFS: libonig/6.9.4-1 --

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: libonig
   Version : 6.9.4-1
   Upstream Author : K.Kosako 
   URL : https://github.com/kkos/oniguruma
   License : BSD-2-clause
   Section : libs

It builds those binary packages:

 libonig-dev - regular expressions library — development files
 libonig5- regular expressions library

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

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


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

 dget -x 
https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.4-1.dsc

or from

 git https://jff.email/cgit/libonig.git?h=release%2Fdebian%2F6.9.4-1


Changes since the last upload:

   * Neu upstream release.
 - Refresh symbols file and add Build-Depends-Package field.
 - Remove upstream applied patches:
   + 0105-CVE-2019-13224.patch
   + 0110-CVE-2019-13225.patch
 - Refresh debain/copyright.
 - Fixes CVE-2019-19204: heap-buffer-overflow in fetch_interval_quantifier
 due to double PFETCH (Closes: #945313).
 - Fixes CVE-2019-19203: heap-buffer-overflow in gb18030_mbc_enc_len
 (Closes: #945312).
 - Fixes CVE-2019-19012: Out of bounds read in mbc_to_code()
 (Closes: #944959).
 - Fixes CVE-2019-16163: Stack Exhaustion Problem (Closes: #939988).
 - Fixes CVE-2019-19246: heap-based buffer over-read in 
str_lower_case_match.
   * debian/watch:_Correct typo.
   * Declare compliance with Debian Policy 4.4.1.1 (No changes needed).
   * Switch to debhelper-compat:
 - debian/control: change to debhelper-compat (=12)
 - remove debian/compat
   * debian/control:
 - Add Rules-Requires-Root: binary-targets.

The build with sbuild and pdebuild and the tests with Lintian and
Piuparts are ok:

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 31932
Build-Time: 28
Distribution: sid
Host Architecture: amd64
Install-Time: 26
Job: /data/entwicklung/linux/debian/libonig/libonig_6.9.4-1.dsc
Lintian: info
Machine Architecture: amd64
Package: libonig
Package-Time: 154
Piuparts: pass
Source-Version: 6.9.4-1
Space: 31932
Status: successful
Version: 6.9.4-1

Finished at 2019-11-29T11:38:00Z
Build needed 00:02:34, 31932k disk space

Regards,

  Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

[Bastian Blank]

Hi Ximin

On Fri, Nov 29, 2019 at 12:24:38PM +, Ximin Luo wrote:
> > On Tue, Nov 26, 2019 at 10:25:51PM +, Ximin Luo wrote:
> > Please stop fiddling with severities.
> The maintainer of a package decides the severities and whether things are 
> bugs or not. Neither have you provided a justification for "serious", it is 
> not breaking anything.

The output of debcargo breaks the Debian archive by increasing the
Package file much more then it needs to do.  Plus it can create
oversized Provides lines.

> Manual cost, nobody is going to want to do this work. Do you want to do this 
> work?

No idea what manual work you are talking about.  Of course I can modify
debcargo and rip the code out to create the surplus packages.

I would have preferred it if you would do that yourself, but if you ask:
yes, I will delete that code from debcargo.

Regards,
Bastian

-- 
You're dead, Jim.
-- McCoy, "The Tholian Web", stardate unknown