Bug#913375: iotop FTCBFS: python build dependency not satisfiable

[Helmut Grohne]

Source: iotop
Version: 0.6-24-g733f3f8-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

iotop fails to cross build from source, because its dependency on the
host architecture python3 is not satisfiable. It really wants a build
architecture python, so annotating with :any seems like the solution.
However, pybuild doesn't recognize that dependency and insists that you
use python3-all:any instead. Even that fails as it's missing the
platform-specific modules, so adding libpython3-all-dev is necessary.
Finally, iotop cross builds. Please consider applying the attached patch
(or converting it to an arch:all package).

Helmut
diff --minimal -Nru iotop-0.6-24-g733f3f8/debian/changelog 
iotop-0.6-24-g733f3f8/debian/changelog
--- iotop-0.6-24-g733f3f8/debian/changelog  2018-04-27 14:56:38.0 
+0200
+++ iotop-0.6-24-g733f3f8/debian/changelog  2018-11-10 08:41:46.0 
+0100
@@ -1,3 +1,13 @@
+iotop (0.6-24-g733f3f8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix Build-Depends for cross. (Closes: #-1)
++ Annotate python3 with :any.
++ Replace python3:any with python3-all:any as pybuild insists.
++ Add libpython3-all-dev as pybuild needs that as well.
+
+ -- Helmut Grohne   Sat, 10 Nov 2018 08:41:46 +0100
+
 iotop (0.6-24-g733f3f8-1) unstable; urgency=medium
 
   * New upstream snapshot
diff --minimal -Nru iotop-0.6-24-g733f3f8/debian/control 
iotop-0.6-24-g733f3f8/debian/control
--- iotop-0.6-24-g733f3f8/debian/control2016-08-11 09:52:08.0 
+0200
+++ iotop-0.6-24-g733f3f8/debian/control2018-11-10 08:41:46.0 
+0100
@@ -5,7 +5,8 @@
 Build-Depends:
  debhelper (>= 11~),
  dh-python,
- python3,
+ python3-all:any,
+ libpython3-all-dev,
  python3-distutils,
 Standards-Version: 4.1.4
 Homepage: http://guichaz.free.fr/iotop/

Bug#856573: chromium: pulldown menus not working (not pulling down)

[Mark Carroll]

On 09 Nov 2018, Michael Gilbert wrote:

> control: reassign -1 src:twm
>
> On Sun, Nov 4, 2018 at 3:33 PM Mark Carroll wrote:
>> I see the problem even in Chromium 69 with both twm and ctwm.
>
> This seems like it should be considered a bug in twm.  The chromium
> upstream bug report includes a lightly tested patch to twm that fixes
> it.

It looks as if the patch works around a bug in Chromium which I guess
explains why I don't have trouble with other applications. But, thank
you for the pointer, I had carelessly missed the reference to the
upstream report. I now tried the current ctwm 4.0.2 which looks to
already have the patch and Chromium is working much better with it.
(Debian packages 3.7 so I built from git.)

-- Mark

Bug#913374: Subject: mate-control-center: Sound does not work properly after upgrading libasound2-plugins

[Soramichi Akiyama]

X-Debbugs-Cc: akiy...@m.soramichi.jp
Package: mate-control-center
Version: 1.20.3-1
Severity: important

Dear Maintainer,

I use MATE on Debian testing and the sound does work correctly after the 
libasound2-plugins package was upgraded from 1.1.6-1 to 1.1.7-2 via recent 
apt-get upgrade.
Especially, the "sound" utility included in mate-control-center seems not 
working, maybe because of the changes introduced in the alsa side.

What happens:
- The "sound" utility in mate-control-center cannot tweak settings for the 
sound cards, although all the cards are properly listed.
  - More precisely, the "Hardware" tab shows all installed sound cards, but the 
"Settings for the selected device" column does not show anything for any card 
selected.
- It also does not show some menus such as the one for testing the selected 
card, which used to be there.
- Some applications cannot play sound even when I manually modify 
/usr/share/alsa/alsa.conf to use the card I want to.
  - Totem and VLC (with the "default" sound card selected) work, but Firefox 
does not play sound.
- The "Applications" tab of the "sound" utility does not show anything even 
when sound is playing.

I guess the reason might be that alsa-plugins have installed new config files 
as shown in their change log
(https://metadata.ftp-master.debian.org/changelogs//main/a/alsa-plugins/alsa-plugins_1.1.7-2_changelog)
and MATE has to adapt to their changes in order to properly configure them.

Soramichi


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

Kernel: Linux 4.19.1 (SMP w/4 CPU cores)
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)

Versions of packages mate-control-center depends on:
ii  caja-common 1.20.2-5
ii  desktop-file-utils  0.23-4
ii  gsettings-desktop-schemas   3.28.1-1
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-8
ii  libcairo-gobject2   1.16.0-1
ii  libcairo2   1.16.0-1
ii  libcanberra-gtk3-0  0.30-6
ii  libcanberra00.30-6
ii  libdbus-1-3 1.12.10-1
ii  libdbus-glib-1-20.110-3
ii  libdconf1   0.30.0-1
ii  libfontconfig1  2.13.1-1
ii  libfreetype62.8.1-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libglib2.0-bin  2.58.1-2
ii  libgtk-3-0  3.24.1-2
ii  libice6 2:1.0.9-2
ii  libmarco-private1   1.20.2-1
ii  libmate-desktop-2-171.20.3-2
ii  libmate-menu2   1.20.1-1
ii  libmate-slab0   1.20.3-1
ii  libmate-window-settings11.20.3-1
ii  libmatekbd4 1.20.2-1
ii  libpango-1.0-0  1.42.4-3
ii  libpangocairo-1.0-0 1.42.4-3
ii  libsm6  2:1.2.2-1+b3
ii  libstartup-notification00.12-5
ii  libx11-62:1.6.7-1
ii  libxcursor1 1:1.1.15-1
ii  libxext62:1.3.3-1+b2
ii  libxi6  2:1.7.9-1
ii  libxklavier16   5.4-3
ii  libxml2 2.9.4+dfsg1-7+b1
ii  libxss1 1:1.2.3-1
ii  marco-common1.20.2-1
ii  mate-control-center-common  1.20.3-1
ii  mate-desktop1.20.3-2
ii  mate-icon-theme 1.20.2-1
ii  mate-menus  1.20.1-1
ii  mate-settings-daemon1.20.3-1

mate-control-center recommends no packages.

Versions of packages mate-control-center suggests:
ii  gconf2  3.2.6-5

-- no debconf information

Bug#912709: apt-show-versions: Max. recursion depth with nested structures exceeded at /usr/lib/x86_64-linux-gnu/perl/5.28/Storable.pm line 278, at /usr/bin/apt-show-versions line 271.

[Richard Lell]

Package: apt-show-versions
Version: 0.22.8
Followup-For: Bug #912709

Dear Maintainer,

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

   * What led up to the situation? Installing Webmin
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Purged apt-show-versions
   * What was the outcome of this action? repoted bug
   * What outcome did you expect instead? hopefully bug will be fixed

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


-- System Information: Debian Buster on ThinkCentre M92p Intel i7 16gb ram
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 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 apt-show-versions depends on:
ii  apt  1.7.0
ii  libapt-pkg-perl  0.1.34+b1
ii  perl [libstorable-perl]  5.28.0-3

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

Bug#913133: Acknowledgement (pulseaudio crashes (SIGSEGV) after failing to set 48000 sample rate in pcm_a52.c)

[ewe2]

Hi,

I just wanted to add that I'd been having this issue too and rolling
back libasound2 altogether, not just the plugins packages was
required. With the plugins packages rolled back I stopped having
segv's but the bigger issue was that nothing in a dbus session could
see the changes; alsa could see all devices yet pulseaudio was unable
to find or connect to anything but a secondary usb interface, indeed
it seemed to be trying to open non-existent devices under /dev/snd/. I
also rolled back the kernel upgrade just in case and rebooted and took
care to check with alsactl init and store. Only then did I recover
access to my internal sound card. I'm also wondering whether a recent
udisks2 upgrade may have also contributed, but it's very difficult to
pin down where exactly the breakdown is, I don't think it's pulseaudio
itself, it's what it depends on.

Bug#311188: RE,

[Miss Juliet Muhammad]

I have a deal for you, in your region.

Bug#612142: RE,

[Miss Juliet Muhammad]

I have a deal for you, in your region.

Bug#206536: RE,

[Miss Juliet Muhammad]

I have a deal for you, in your region.

Bug#913373: golang-github-miekg-dns: test failures except on 64-bit LE

[Steve Langasek]

Source: golang-github-miekg-dns
Version: 1.0.4+ds-1
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertag: origin-ubuntu disco

Dear maintainers,

As of version 1.0.4+ds-1, golang-github-miekg-dns consistently fails its
autopkgtests on s390x, armhf, and i386, as seen in Ubuntu:

[...]
=== RUN   TestParseDstFromOOB
--- FAIL: TestParseDstFromOOB (0.00s)
udp_test.go:82: failed to parse IPv4 in IPv6: 
udp_test.go:92: failed to parse IPv6: 
udp_test.go:102: failed to parse IPv4: 
=== RUN   TestCorrectSource
--- FAIL: TestCorrectSource (0.00s)
udp_test.go:115: unexpected oob for ipv4 address: []
udp_test.go:124: unexpected oob for IPv6 address: []
[...]
make: *** [debian/rules:7: build] Error 1
autopkgtest [00:34:33]: test command1: ---]
autopkgtest [00:34:33]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 2

(http://autopkgtest.ubuntu.com/packages/g/golang-github-miekg-dns/cosmic/s390x)

The exact errors are somewhat different between s390x and {armhf,i386}, but
the common denominator is that the architectures that pass (amd64, arm64,
ppc64el) are all 64-bit little-endian architectures, and the ones that fail
are not (either 64-bit big-endian, or 32-bit little-endian).

So the code in this package appears to be non-portable.

I have not looked to check whether the autopkgtests previously passed
because this is a new test or because this is a code regression.

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


signature.asc
Description: PGP signature

Bug#901967: CVE-2018-11723 is fixed in libpff 20180714.

[Aleksey Kravchenko]

The actual bug heap-buffer-overflow beneeth the
CVE-2018-11723 is described in the Issue #64 [1]
in the upstream bugtracker.

The bug is fixed in the version 20180714 by commit [2].

See also libpff author comments [3] on this CVE-2018-11723.

  [1] https://github.com/libyal/libpff/issues/64
  [2]
https://github.com/libyal/libpff/commit/7b92bcace7e743cc9417e3cc3e4eee29abb70cf5
  [3] https://github.com/libyal/libpff/issues/66

Bug#913350: chmod: changing permissions of '/.../body_neg100.so': Operation not permitted

[Noah Meyerhans]

Control: tags -1 + moreinfo
Control: severity -1 normal

On Fri, Nov 09, 2018 at 08:40:14PM +0100, Sebastian Ramacher wrote:
> > | chmod: changing permissions of 
> > '/var/lib/spamassassin/compiled/5.024/3.004001/auto/Mail/SpamAssassin/CompiledRegexps/body_neg100/body_neg100.so':
> >  Operation not permitted
> > | dpkg: error processing package sa-compile (--configure):
> > |  subprocess installed post-installation script returned error exit status 
> > 1
> > | Errors were encountered while processing:
> > |  sa-compile
> 
> This file is owned by root:root. After moving it away, installation succeeded.
> 
> The failing line of the postinst script is:
> 
> # Fixup perms -- group and other should be able to
> # read and execute, but never write.  Works around
> # sa-compile's failure to obey umask.
> runuser -u debian-spamd -- \
> chmod -R go-w,go+rX /var/lib/spamassassin/compiled

The file in question would have been generated with sa-compile. However,
sa-compile has been run as the debian-spamd user for a long time (at
least as far back as wheezy). The cron.daily script uses the following
invocation:

env -i LANG="$LANG" PATH="$PATH" start-stop-daemon \
--chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/sa-compile -- --quiet

So if there were any root-owned files in the compiled output, I don't
see how they could have been put there by the package.

It's possible that sa-compile had, at some point, been manually executed
as root, in which case this is #721648. If you're able to provide any
more info about where that file could have come from or whether
sa-compile had ever run as root on this system, that could help to more
clearly identify what happened.

noah



signature.asc
Description: PGP signature

Bug#913372: mgen-doc: No need to recommend rarian-compat, dww, etc.

[Jeremy Bicha]

From ee21335485217c056d1d990b1a6c35b655050c5d Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Fri, 9 Nov 2018 23:04:00 -0500
Subject: [PATCH] mgen-doc: Drop unneeded Recommends

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

diff --git a/debian/changelog b/debian/changelog
index ec3a6b6..6b7c2a1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+mgen (5.02.b+dfsg1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * mgen-doc: Drop unneeded Recommends: 
+dwww | dhelp | rarian-compat | doc-central
+(Closes: #913372)
+
+ -- Jeremy Bicha   Fri, 09 Nov 2018 22:53:51 -0500
+
 mgen (5.02.b+dfsg1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index e18bbd0..6bb17a7 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,6 @@ Description: packet generator for IP network performance tests
 Package: mgen-doc
 Architecture: all
 Section: doc
-Recommends: dwww | dhelp | rarian-compat | doc-central
 Depends: ${misc:Depends}
 Description: mgen user and reference guide
  This package contains the HTML documentation for MGEN, a packet generator
-- 
2.19.1

Bug#913372: mgen-doc: No need to recommend rarian-compat, dwww, etc.

[Jeremy Bicha]

Package: mgen-doc
Version: 5.02.b+dfsg1-2.1
Tags: pending patch

It is unnecessary for doc packages like mgen-doc to recommend dww, etc.

Maybe this used to be more common, but now there are only about 5
packages in Debian that recommend dwww.

I am uploading an NMU to fix this issue to the deferred/15 queue.
Please let me know if I should speed up or slow down the upload.

I am attaching a minimal diff of my changes in my followup to this email.

Thanks,
Jeremy Bicha

Bug#913371: gnat-gps fails to build on 32-bit kernels, address space exhaustion.

[peter green]

package: gnat-gps
version: 18-2

gnat-gps failed on armel, mips, and mipsel with the following error.


+===GNAT BUG DETECTED==+
| 8.2.0 (arm-linux-gnueabi) Storage_Error System.Memory.Realloc: heap exhausted|
| Error detected at gnatcoll-sql.adb:869:7 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

This looks like a case of address space being exhausted. On most 32-bit
systems the address space of any individual process is limited to 3GB.

armhf and powerpc succeeded but those builds were on 64-bit kernels
which allow nearly the full 4GB to be used by 32-bit programs.

We also ran into the issue over in raspbian, we have a mixture of
buildboxes with 32-bit and 64-bit hardware/kernels and it suceeded
on the box with a 64-bit kernel but failed on those with 32-bit kernels.

Other 32-bit architectures (i386, hppa, hurd-i386, kfreebsd-i386, m68k
, powerpcspe and sh4) have not tried to build the latest gnat-gps due
to uninstallable build-depends.

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277


"padsp mocp"  and 'mocp' works fine, no crash (even if not able to 
decrease/increase volume using mocp keybinding).
Now I see volume level (0%) + master in volume bar (master 00).

I am out of ideas. Not sure what more info I can give :)

Bug#818618: dpkg-genchanges: Please exclude packages disabled in unstaged builds

[Guillem Jover]

Hi!

On Thu, 2016-09-22 at 13:35:23 +0200, Johannes Schauer wrote:
> Quoting Guillem Jover (2016-03-29 00:39:01)
> > On Fri, 2016-03-18 at 23:05:26 +0100, Johannes Schauer wrote:
> > > I thus think it's reasonable for dpkg-genchanges to only include the 
> > > binary
> > > packages in the Binary field of the .changes file which were actually
> > > produced depending on the currently active profiles.
> > 
> > While that's all true, it unfortunately does not match reality. The
> > Binary field in the .changes file has always listed all packages
> > regardless of restrictions, including architectures ones.
> > 
> > So the bug report seems reasonable, but I hesitate to do the change as
> > it might break things expecting the field to list more packages than it
> > should. I'll bring it up on d-d to canvas possible problems.

It seem that ended up not eliciting any additional input, except for
Samuel's. :(

> I just made three uploads of src:botch to unstable:
> 
>  1. An upload of source and Arch:all but the Binary field only listing the
> Arch:all package botch-doc
> 
>  2. A source-only upload but the Binary field being empty
> 
>  3. A source-only upload without the Binary field
> 
> It seems that the first two instances resulted in successful uploads as one 
> can
> see here:
> 
>  1. https://tracker.debian.org/news/799443
> 
>  2. https://tracker.debian.org/news/799448
> 
> The third one resulted in:
> 
>   Subject: botch_0.18-6_source.changes REJECTED
>   
>   botch_0.18-6_source.changes: misses mandatory field Binary
> 
> Thus, I do not think that following policy and only putting package names of
> packages that are actually produced into the Binary field of the .changes file
> should pose any problem. Just take care to not remove the Binary field but
> leave it empty if no binary packages are being uploaded.

Thanks for these tests, much appreciated!

I've got now a patch locally which only includes binary names and
descriptions for binaries actually uploaded. I'm tempted to just apply
it, although it would first need for dak to not reject an upload when
the Binary field is missing. I've got a patch here for dak too, which
I'll send out tomorrow.

> This finding is also backed up by the dak source code which seems to only 
> check
> if the Binary field does *not* list some of the packages that are being
> uploaded. See the class BinaryCheck in daklib/checks.py.

Right, that's my reading too.


Samuel, the bad news, I'm afraid, is that even with that change, this
would not solve your original problem, because dak uses the
Package-List field from the .dsc which will include all possible
binary names. I think what you'd need is for dak itself to ignore
packages that are only built on specific profiles (this can be checked
from the Package-List field). At least that's what I'm reading from the
dak sources, but perhaps I've missed some code. You might want to try
the problematic upload but removing the entry only from the Package-List
field, keeping the entries in the .changes Binary field,  and see what
happens.

Thanks,
Guillem

Bug#913366: Now properly setting forwarded address

[Diederik de Haas]

Control: forwarded -1 https://github.com/micahflee/torbrowser-launcher/pull/360



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

Bug#913295: debian-policy: Update location of example init.d script

[Russ Allbery]

Dmitry Bogatov  writes:

> According to #913154, there is consensus, that `/etc/init.d/skeleton' is
> not suitable location for example init.d script, and actually duplicates
> information, provided by init-d-script(5) manpage.

> I attach tiny patch, that changes Policy.

Thank you!  Seconded.

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

Bug#913366: Acknowledgement (torbrowser-launcher: more apparmor fixes needed, otherwise fails to launch)

[Diederik de Haas]

Control: forwarded -1 https://github.com/micahflee/torbrowser-launcher/pull/
360

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

Bug#913370: gmrender-resurrect (build-)depends on cruft packages.

[peter green]

package: gmrender-resurrect
version: 0.0.7~git20180618.d0f46f5-2
severity: serious

gmrender-resurrect build-depends on libupnp1.8-dev and it's binary package 
gmrender depends on libupnp10. These packages are no longer built by pupnp-1.8. 
They appear to have been replaced by libupnp-dev and libupnp13.

Bug#913355: libuhd-dev: UHDConfig.cmake includes nonexisting UHDTargets.cmake

[A. Maitland Bottoms]

Before getting this bug report, I uploaded
uhd 3.13.0.2-3 which fixes this bug.

-Maitland

Bug#870394: libreoffice-writer: No screen reader notification that there is a comment

[Alex ARNAUD]

Hello Stéphane and all,

First of all, thanks for your involvement into Debian.

My name is Alex, I'm visual-impaired and I'm one of the member of the 
Hypra project. We're working everyday to improve free software, 
especially making it more user-friendly and also usable for elderly, 
beginners and visual-impaired people.


We're collaborating with different Debian team, especially 
Accessibility, LibreOffice, Mate, Firefox and Thunderbird and their 
upstream counterparts.


The bugs I've reopened are owned by Hypra and we're planning to work on 
on the next years.


We've sent a message to the debian-openoffice mailing list in 2017 to 
explain why we'd like to have our bugs reported in Debian.

You could find the response from Rene Engelhard here:
https://lists.debian.org/debian-openoffice/2017/07/msg00014.html

Let me know if you've any question.

Best regards,
Alex.

Le 05/11/2018 à 01:36, Debian Bug Tracking System a écrit :

Your message dated Mon, 5 Nov 2018 01:32:38 +0100
with message-id 
and subject line libreoffice-writer: No screen reader notification that there 
is a comment
has caused the Debian Bug report #870394,
regarding libreoffice-writer: No screen reader notification that there is a 
comment
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

I just realized that 'mocp' crashes with the message pasted at the beginning of 
this report
when there is another application playing sound.
Example: I run a youtube video on firefox. I start 'mocp' and it crashes.
 If I close the youtube video on firefox, 'mocp' starts fine.

I wonder why this issue started to happen just recently, and why now 'mocp' 
displays 'PCM' next
to the volume level in the volume bar (example: 50 PCM). I think it doesn't do 
that days ago.
According to dpkg.log, 'alsa-utils', 'libasound2', 'libasound2-data' and 
'libasound2-plugins'
have been upgraded a few days ago.
Not sure if there is a correlation between those upgrades and 'moc'...

Bug#913369: pluto-jpl-eph: Release to unstable

[Jeremy Bicha]

Source: pluto-jpl-eph
Version: 0.0~git20180228-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:pluto-lunar

pluto-lunar can't be built in unstable because it build-depends on
packages from pluto-jpl-eph which is only in experimental. Please
upload pluto-jpl-eph to fix this issue.

Thanks,
Jeremy Bicha

Bug#570623: Prognosis for integrating multiple version support into reprepro?

[John Goerzen]

Hi folks,

First of all, thanks to all of you for your work on reprepro.  I am
looking at a use case for which reprepro plus the profitbricks multiple
version support looks ideal.  However, as I want to set this up for
long-term success without a lot of fiddling, I'm wondering what the
prognosis is for getting this patch set integrated into reprepro
itself.  I don't see any comments in the bug log after either the 2017
or the 2018 patches, and am just wondering where things are?  Is there
something I could do to help move it along/

Thanks,

John

Bug#913367: tpm2-abrmd (build-)depends on cruft packages.

[peter green]

Package: tpm2-abrmd
Version: 1.3.1-1.1
Severity: serious

tpm2-abrmd build-depends on libsapi-dev and depends on libsapi0, these packages 
are no longer built by source package tpm2-tss. They appear to have been 
replaced by libtss2-dev and libtss2-esys0 .

Bug#913368: tpm2-pk11 (build-)depends on cruft packages.

[peter green]

Package: tpm2-pk11
Version: 0~git20180426-1
Severity: serious

tpm2-pk11 build-depends on libsapi-dev and depends on libsapi0, these packages 
are no longer built by source package tpm2-tss. They appear to have been 
replaced by libtss2-dev and libtss2-esys0 .

Bug#913366: torbrowser-launcher: more apparmor fixes needed, otherwise fails to launch

[Diederik de Haas]

Package: torbrowser-launcher
Version: 0.3.1-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

I had applied the patch before, but I guess it got overwritten with a
new version (which I thought wasn't supposed to happen without asking).
Applied the patch again and then torbrowser started again.

For completeness sake, this is the patch intrigeri submitted upstream,
but the upstream pull request is now already waiting more then a month
for approval/merge, so it's probably good to apply this patch to the
Debian package in the meantime.

  owner 
@{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/extensions/*.xpi 
r,
+ owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profiles.ini r,
+ owner 
@{torbrowser_home_dir}/TorBrowser/UpdateInfo/updates/[0-9]*/update.{status,version}
 r,
+ owner @{torbrowser_home_dir}/TorBrowser/UpdateInfo/updates/[0-9]/updater rw,
  owner 
@{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/startupCache/* r,

Cheers,
  Diederik

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20180409
ii  libdbus-glib-1-2  0.110-3
ii  python3   3.6.7-1
ii  python3-gpg   1.12.0-4
ii  python3-pyqt5 5.11.3+dfsg-1+b1
ii  python3-requests  2.20.0-2
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.4.9-5

Versions of packages torbrowser-launcher suggests:
ii  apparmor   2.13.1-3+b1
ii  python-pygame  1.9.4.post1+dfsg-2

-- Configuration Files:
/etc/apparmor.d/torbrowser.Browser.plugin-container changed:
@{torbrowser_firefox_executable} = 
/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox.real
profile torbrowser_plugin_container {
  #include 
  # Uncomment the following lines if you want Tor Browser
  # to have direct access to your sound hardware. You will also
  # need to remove, further bellow:
  #  - the "deny" word in the machine-id lines
  #  - the rules that deny reading /etc/pulse/client.conf
  #and executing /usr/bin/pulseaudio
  # #include 
  # /etc/asound.conf r,
  # owner 
@{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/tmp/mozilla-temp-*
 rw,
  signal (receive) set=("term") peer=torbrowser_firefox,
  deny /etc/host.conf r,
  deny /etc/hosts r,
  deny /etc/nsswitch.conf r,
  deny /etc/resolv.conf r,
  deny /etc/passwd r,
  deny /etc/group r,
  deny /etc/mailcap r,
  deny /etc/machine-id r,
  deny /var/lib/dbus/machine-id r,
  /etc/mime.types r,
  /usr/share/applications/gnome-mimeapps.list r,
  /dev/shm/ r,
  owner @{PROC}/@{pid}/environ r,
  owner @{PROC}/@{pid}/fd/ r,
  owner @{PROC}/@{pid}/mountinfo r,
  owner @{PROC}/@{pid}/stat r,
  owner @{PROC}/@{pid}/status r,
  owner @{PROC}/@{pid}/task/*/stat r,
  @{PROC}/sys/kernel/random/uuid r,
  owner @{torbrowser_home_dir}/*.dat r,
  owner @{torbrowser_home_dir}/*.manifest r,
  owner @{torbrowser_home_dir}/*.so mr,
  owner @{torbrowser_home_dir}/.cache/fontconfig/   rw,
  owner @{torbrowser_home_dir}/.cache/fontconfig/** rw,
  owner @{torbrowser_home_dir}/browser/** r,
  owner @{torbrowser_home_dir}/components/*.so mr,
  owner @{torbrowser_home_dir}/browser/components/*.so mr,
  owner @{torbrowser_home_dir}/defaults/pref/ r,
  owner @{torbrowser_home_dir}/defaults/pref/*.js r,
  owner @{torbrowser_home_dir}/dependentlibs.list r,
  owner @{torbrowser_home_dir}/fonts/   r,
  owner @{torbrowser_home_dir}/fonts/** r,
  owner @{torbrowser_home_dir}/omni.ja r,
  owner 
@{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/extensions/*.xpi 
r,
  owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profiles.ini r,
  owner 
@{torbrowser_home_dir}/TorBrowser/UpdateInfo/updates/[0-9]*/update.{status,version}
 r,
  owner @{torbrowser_home_dir}/TorBrowser/UpdateInfo/updates/[0-9]*/updater rw,
  owner 
@{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/startupCache/* r,
  owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/tmp/* rw,
  owner @{torbrowser_home_dir}/TorBrowser/Data/fontconfig/fonts.conf r,
  owner @{torbrowser_home_dir}/TorBrowser/Tor/ r,
  owner @{torbrowser_home_dir}/TorBrowser/Tor/*.so mr,
  owner @{torbrowser_home_dir}/TorBrowser/Tor/*.so.* mr,
  owner @{torbrowser_home_dir}/Downloads/ rwk,
  owner @{torbrowser_home_dir}/Downloads/** rwk,
  owner @{torbrowser_firefox_executable} ixmr -> torbrowser_plugin_container,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/present r,
  /sys/devices/system/node/ r,
  

Bug#856573: chromium: pulldown menus not working (not pulling down)

[Michael Gilbert]

control: reassign -1 src:twm

On Sun, Nov 4, 2018 at 3:33 PM Mark Carroll wrote:
> I see the problem even in Chromium 69 with both twm and ctwm.

This seems like it should be considered a bug in twm.  The chromium
upstream bug report includes a lightly tested patch to twm that fixes
it.

Best wishes,
Mike

Bug#616018: Updating flags and preparing to close

[Gabriel F. T. Gomes]

Control: tags -1 + unreproducible
Control: tags -1 - wontfix

According to Debian's webpage on PDFs [1], Adobe's Acrobat Reader
(acroread), can be installed from two different sources:

1. deb-multimedia.org

I downloaded the .deb files from this server and none of them contains
a completion file.

wget 
http://www.deb-multimedia.org/pool/non-free/a/adobereader-enu/acroread_9.5.5-dmo2_i386.deb
wget 
http://www.deb-multimedia.org/pool/non-free/a/adobereader-enu/acroread-data_9.5.5-dmo2_all.deb
wget 
http://www.deb-multimedia.org/pool/non-free/a/adobereader-enu/acroread-plugins_9.5.5-dmo2_i386.deb
wget 
http://www.deb-multimedia.org/pool/main/a/acroread-debian-files/acroread-debian-files_9.5.8_amd64.deb
wget 
http://www.deb-multimedia.org/pool/non-free/a/adobereader-enu/acroread-l10n-en_9.5.5-dmo2_all.deb

find . -maxdepth 1 -name "*acroread*" \
 -exec dpkg-deb --contents {} \; \
| grep completion
(no output)

2. Adobe's FTP server [2]

While the latest .deb file does contain a completion file, it is empty,
thus, installing it under /etc/bash_completion.d/ (yes, it was
installed in the obsolete directory), did not reproduce the problem.

wget 
ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/AdbeRdr9.5.5-1_i386linux_enu.deb

dpkg-deb --extract AdbeRdr9.5.5-1_i386linux_enu.deb expand/
cat expand/etc/bash_completion.d/acroread.sh 
(no output)

Since I cannot reproduce this bug, I'll add the unreproducible tag to
it and leave it open for some time.  Afterwards, I'll close the bug.

If you have more information about it, do not resitate to reopen the bug.


Michal,

Are you still able to reproduce this bug?
(I know it's been a very long time, sorry to bother, but I'm trying to
solve Debian's bash-completion problems, including very old ones)


[1] https://wiki.debian.org/PDF
[2] ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

I don't run moc remotly. I just access my X, my regular openbox user session, 
via wdm then I run mocp.
All other apps works just fine. I am using cmus now.
My user is member of all groups, sound included.

Bug#913332: debian-edu-artwork: Please add debian-edu-artwork-buster as new binary package

[Holger Levsen]

On Fri, Nov 09, 2018 at 10:08:00PM +, Mike Gabriel wrote:
> Why not add the d-e-a-buster package with copied over stretch artwork files?

because its good to recognize which are which.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#906548: chromium: Chromium crashes with SEGV on startup in Stable on RPI

[Michael Gilbert]

control: severity -1 important
control: fixed -1 70.0.3538.54-2
control: retitle -1 chromium: SEGV on startup in stretch on armhf

> the version in stable crashes after the security update on a Raspberry Pi
> on startup. The system ist mainly Debian stable with some Raspbian packages.
> I couldn't find the dbgsym package, so please point me to it. Until then
> this is the --debug output:

The upstream discussion indicates that this is fixed after the update
to gcc 8 in unstable, so it seems to be another problem specific to
gcc 6 on arm.  Since unstable now uses gcc 8, this only needs to be
fixed in stretch now.

Riku, do you have any ideas?

Best wishes,
Mike

Bug#889180: Different Bug

[Soren Stoutner]

I experienced this bug on multiple systems with rotating wallpapers.  It
has been fixed for quite some time.

However, there are new memory leak bugs in KDE.  For example, KMail
currently causes Akonadi to overwhelm a system (current testing
packages).  So much so that I had to delete my KMail IMAP account and
use Thunderbird if I wanted to keep a system on for more than 24 hours.

As such, you should probably file a new bug report that tries to isolate
as much as possible the symptoms you are experiencing.

-- 
Soren Stoutner
so...@stoutner.com
623-262-6169

Bug#887712: fixed in ftgl 2.3.0-1

[Manuel A. Fernandez Montecelo]

Hi,

Em qui, 8 de nov de 2018 às 11:59, IOhannes m zmölnig (Debian/GNU)
 escreveu:
>
> (resending)
>
> my packages are marked for AUTORM by end of november, because they B-D
> on ftgl.
> i would really like to avoid having them removed from testing.

Thanks for the ping, I certainly did miss the initial message, since
I'm not listed as maintainer and didn't get sent an email
automatically.


> On Wed, 31 Oct 2018 10:10:46 +0100 =?UTF-8?Q?IOhannes_m_zm=c3=b6lnig?=
>  wrote:
> > On Sat, 20 Oct 2018 14:49:43 + m...@debian.org (Manuel A. Fernandez
> > Montecelo) wrote:
> > > Source: ftgl
> > > Source-Version: 2.3.0-1
> >
> > thanks for doing an upload of ftgl-2.3 to "experimental".
> > do you have any plans, to also upload to "unstable" (so all those
> > reverse-dependencies that are marked AUTORM won't get kicked out of
> > Debian)? is a transition required?

So I had plans to upload to unstable, but then noticed that the new
upstream maintainer (in copy) changed the SOVERSION.  I don't know if
there's an actual break in ABI or it was just to set it and be the
same as the version of the library, but in fact this will cause a
transition, so it's what stopped me from uploading to unstable.

I think that I asked Frank about this but didn't get a reply yet, I
know that he's been busy with misc things.

I suppose that we can either upload to unstable and request a
transition slot, and everything will be fine, or check that the ABI
didn't change and patch to keep the old SOVERSION.

Would you like to help with that?  I've been kept busy and without a
continous stretch of time to review and deal with the issue properly,
also because of other Debian duties, so I'm not sure when I'll be able
to deal with that.


> > (btw, where is ftgl-2.3.0 upstream? is it the
> > https://github.com/ulrichard/ftgl fork?)

I don't know why it's so buried in github, but Richard was not
interested in being the main maintainer and as discussed in
https://github.com/ulrichard/ftgl/pull/9#issuecomment-428309601 the
de-facto maintainer is now Frank.

Also from https://github.com/ulrichard/ftgl/ main page/README:

  ftgl is currently hosted at:
  https://github.com/frankheckenbach/ftgl
  Current maintainer:
  Frank Heckenbach 


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#908288: chromium: minimize/maximize window buttons can be missing

[Michael Gilbert]

I looked into this.  It is caused by upstream's removal of the gtk2
window button implementation around version 64, which is why only
stretch is affected.  It still uses gtk2.  For anyone interested in
this, I am willing to accept a forward port of upstream's old
implementation.  However, this isn't something I'll be looking into
myself.

Best wishes,
Mike

Bug#913365: [reportbug-ng] ..silly wee typo in reportbug-ng --help output

[Arnt Karlsen]

Package: reportbug-ng
Version: 2.1
Severity: minor

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

..silly wee typo in reportbug-ng --help output:
reportbug-ng --help
Usage: reportbug-ng [Options] [Query]

Report a bug in Debian's BTS. The optional paremter QUERY behaves
   
   paremter should have been parameter 
   
Report a bug in Debian's BTS. The optional parameter QUERY behaves
exactly like the query inside the program. Supported queries are:
packagename, bugnumber, maintai...@foo.bar, src:package,
from:submit...@foo.bar, severity:foo and tag:bar.

Options:
  --version show program's version number and exit
  -h, --helpshow this help message and exit
  -l LEVEL, --loglevel=LEVEL
Which loglevel to use [default: warning]. Valid
loglevels are: critical, error, warning, info,
debug, notset


--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-0.bpo.1-rt-amd64

Debian Release: 9
  500 stable-updates  deb.devuan.org 
  500 stable-security deb.devuan.org 
  500 stable  deb.devuan.org 
  100 stable-proposed-updates deb.devuan.org 
  100 stable-backports deb.devuan.org 
  100 experimentaldeb.devuan.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-==
python:any(>= 2.7.5-5~) | 
python-debianbts   (>= 1.0) | 2.6.1
python-pyqt5| 5.7+dfsg-5
python-pyqt5.qtwebkit   | 5.7+dfsg-5
xdg-utils   | 1.1.1-1+deb9u1
xterm   | 327-2
python-apt  (>= 0.7.93) | 1.4.0~beta3


Package's Recommends field is empty.

Package's Suggests field is empty.




Hi,


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Bug#911808: upstream bug

[Jason Woofenden]

Hi Maintainer,

I found the upstream bug forthe "chain 'DNAT' does not exist" bug:

https://github.com/moby/moby/issues/38099

WORKAROUND:
update-alternatives --config iptables
choose iptables-legacy

-- 
Jason

Bug#913364: [atop] ..atop installs systemd cron job on non-systemd Devuan box...

[Arnt Karlsen]

Package: atop
Version: 2.2.6-4
Severity: normal

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

..on installing atop, I found things going at a glacial pace, a 
wee part of global climate change, and this fine new cron job:
root@box:~# cat /etc/cron.d/atop
PATH=/bin:/usr/bin:/sbin:/usr/sbin

# daily restart of atop at midnight
0 0 * * * root if [ -d "/run/systemd/system" ]; then systemctl restart
atop; else /usr/share/atop/atop.daily \& ; fi

..commenting it out, "brought back life."

..we need to keep an eye out for such systemd tricks causing such DOS,
one way is chk which init system is installed, and then install the
correct cron job file.
root@box:~# dpkg -l atop |grep atop |fmt -tu
ii atop 2.2.6-4 amd64 Monitor for system resources and process activity


--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-0.bpo.1-rt-amd64

Debian Release: 9
  500 stable-updates  deb.devuan.org 
  500 stable-security deb.devuan.org 
  500 stable  deb.devuan.org 
  100 stable-proposed-updates deb.devuan.org 
  100 stable-backports deb.devuan.org 
  100 experimentaldeb.devuan.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
libc6  (>= 2.14) | 2.24-11+deb9u3
libncurses5   (>= 6) | 6.0+20161126-1+deb9u2
libtinfo5 (>= 6) | 6.0+20161126-1+deb9u2
zlib1g  (>= 1:1.1.4) | 1:1.2.8.dfsg-5
init-system-helpers   (>= 1.18~) | 1.48+devuan2.0
lsb-base (>= 3.2-14) | 4.1+devuan2


Recommends   (Version) | Installed
==-+-===
cron   | 3.0pl1-128+deb9u1
 OR cron-daemon| 


Package's Suggests field is empty.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Bug#912633: Still Not Working

[Soren Stoutner]

My `TLS_TRUSTCERTS=` was blank.  Setting it to `/etc/ssl/certs` did not
resolve the problem.

The certificate I am using is generated by Let's Encrypt.  I use the
combined.pem, which includes the entire chain, so the `TLS_TRUSTCERTS`
shouldn't be needed in my case.

The certificate is also used for webmail at https://mail.stoutner.com. 
You can verify that it is current and doesn't otherwise have problems by
visiting the URL with a web browser.

-- 
Soren Stoutner
so...@stoutner.com
623-262-6169

Bug#913133: Acknowledgement (pulseaudio crashes (SIGSEGV) after failing to set 48000 sample rate in pcm_a52.c)

[Felipe Sateler]

On Thu, Nov 8, 2018 at 3:57 AM Haworth, David 
wrote:

> Here's the gdb backtrace from pulseaudio -vvv (the last few lines of the
> verbose output are at the top)


Looks like the crash is happening inside libasound2-plugins. Does the crash
go away if you downgrade that back to version 1.1.6-1?

-- 

Saludos,
Felipe Sateler

Bug#913335: qemu-system-i386: Display 'sdl' is not available.

[Michael Tokarev]

10.11.2018 00:34, Thorsten Glaser wrote:
> reopen 913336
> thanks
> 
> Michael Tokarev dixit:
> 
>>> pn  qemu-system-gui  
>>
>> Ditto as for #913336.
> 
> Nope.
> 
> 1. I still get “Display 'sdl' is not available.” if I select it.

*if* you select it, yes, because sdl display isn't being built.
Don't enable options which are not built.

> 2. qemu *still* runs a VNC server by default if the above package
>is not installed.
> 
> Additionally, GTK+3 is… problematic and has many dependencies
> it pulls in, so the standard X11 display with SDL should still
> work.

Should? Now you have 2 options: gui, with full support of various
modern options such as 3D acceleration, or no local gui display
and no X dependencies at all. If you run X, you'll get full support
of qemu local display abilities.

Seriously, come on, if you need custom set of dependencies, build
your own configuration of qemu, don't force maintainers to build
a thousand of different configurations for you.

Thanks,

/mjt

Bug#906658: gimp-gmic: Segmentation fault when attempting to apply filter

[Bernd Zeimetz]

Hi,

> "GIMP Message - Plug-in crashed: "gmic_gimp"
> (/usr/lib/gimp/2.0/plug-ins/gmic_gimp) The dying plug-in may have messed
> up GIMP's internal state. You may want to
> save your images and restart GIMP to be on the safe side.
wild guess, you are using the recent gimp version with gmic that was not
built for it, maybe even using libgimp from the old version.

Please update to the current version from unstable and see if it works
again.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#908678: Some more thoughts and some tests on the security-tracker git repo

[Antoine Beaupré]

On 2018-11-09 16:05:06, Antoine Beaupré wrote:
>  2. do a crazy filter-branch to send commits to the right
> files. considering how long an initial clone takes, i can't even
> begin to imagine how long *that* would take. but it would be the
> most accurate simulation.
>
> Short of that, I think it's somewhat dishonest to compare a clean
> repository with split files against a repository with history over 14
> years and thousands of commits. Intuitively, I think you're right and
> that "sharding" the data in yearly packets would help a lot git's
> performance. But we won't know until we simulate it, and if hit that
> problem again 5 years from now, all that work will have been for
> nothing. (Although it *would* give us 5 years...)

So I've done that crzy filter-branch, on a shallow clone (1000
commits). The original clone is about 30MB, but the split repo is only
4MB.

Cloning the original repo takes a solid 30+ seconds:

[1221]anarcat@curie:src130$ time git clone 
file://$PWD/security-tracker-1000.orig security-tracker-1000.orig-test
Clonage dans 'security-tracker-1000.orig-test'...
remote: Énumération des objets: 5291, fait.
remote: Décompte des objets: 100% (5291/5291), fait.
remote: Compression des objets: 100% (1264/1264), fait.
remote: Total 5291 (delta 3157), réutilisés 5291 (delta 3157)
Réception d'objets: 100% (5291/5291), 8.80 MiB | 19.47 MiB/s, fait.
Résolution des deltas: 100% (3157/3157), fait.
64.35user 0.44system 0:34.32elapsed 188%CPU (0avgtext+0avgdata 
200056maxresident)k
0inputs+58968outputs (0major+48449minor)pagefaults 0swaps

Cloning the split repo takes less than a second:

[1223]anarcat@curie:src$ time git clone 
file://$PWD/security-tracker-1000-filtered security-tracker-1000-filtered-test
Clonage dans 'security-tracker-1000-filtered-test'...
remote: Énumération des objets: 2214, fait.
remote: Décompte des objets: 100% (2214/2214), fait.
remote: Compression des objets: 100% (1190/1190), fait.
remote: Total 2214 (delta 936), réutilisés 2214 (delta 936)
Réception d'objets: 100% (2214/2214), 1.25 MiB | 22.78 MiB/s, fait.
Résolution des deltas: 100% (936/936), fait.
0.25user 0.04system 0:00.38elapsed 79%CPU (0avgtext+0avgdata 8200maxresident)k
0inputs+8664outputs (0major+3678minor)pagefaults 0swaps

So this is clearly a win, and I think it would be possible to rewrite
the history using the filter-branch command. Commit IDs would change,
but we would keep all commits and so annotate and all that good stuff
would still work.

The split-by-year bash script was too slow for my purposes: it was
taking a solid 15 seconds for each run, which meant it would have taken
9 *days* to process the entire repository.

So I tried to see if this could be optimized, so we could split the file
while keeping history without having to shutdown the whole system for
days. I first rewrote it in Python, which processed the 1000 commits in
801 seconds. This gives an estimate of 15 hours for the 68278 commits I
had locally. Concerned about the Python startup time, I then tried
golang, which processed the tree in 262 seconds, giving final estimate
of 4.8 hours.

Attached are both implementations, for those who want to reproduce my
results. Note that they differ from the original implementation in that
they have to (naturally) remove the data/CVE/list file itself otherwise
it's kept in history.

Here's how to call it:

git -c commit.gpgSign=false filter-branch --tree-filter 
'/home/anarcat/src/security-tracker/bin/split-by-year.py data/CVE/list' HEAD

Also observe how all gpg commit signatures are (obviously) lost. I have
explicitely disabled that because those actually take a long time to
compute...

I haven't tested if a graft would improve performance, but I suspect it
would not, given the sheer size of the repository that would effectively
need to be carried over anyways.

A.

-- 
Man really attains the state of complete humanity when he produces,
without being forced by physical need to sell himself as a commodity.
- Ernesto "Che" Guevara
package main

import (
	"bufio"
	"bytes"
	"io"
	"log"
	"os"
	"strconv"
	"strings"
)

func main() {
	file, err := os.Open("data/CVE/list")
	if err != nil {
		log.Fatal(err)
	}
	defer file.Close()

	var (
		line []byte
		cve  []byte
		year uint64
		year_str string
		target   *os.File
		header   bool
	)
	fds := make(map[uint64]*os.File, 20)
	scanner := bufio.NewReader(file)
	for {
		line, err = scanner.ReadBytes('\n')

		if bytes.HasPrefix(line, []byte("CVE-")) {

			cve = line
			year_str = strings.Split(string(line), "-")[1]
			year, _ = strconv.ParseUint(year_str, 0, 0)
			header = true
		} else {
			if target, ok := fds[year]; !ok {
target, err = os.OpenFile("data/CVE/list."+year_str, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
	log.Fatal(err)
}
fds[year] = target
			}
			if header {
target.Write(cve)
header = false
			}
			target.Write(line)
		}
		if err != nil {
			break
		}
	}

Bug#912916: mysql-connector-java: CVE-2018-3258: allows low privileged attacker to compromise it

[Markus Koschany]

Control: retitle -1 mysql-connector-java: removal from Debian
Control: block -1 by 913323 913354 913360 913343 913362

So here we go. The removal of mysql-connector-java is currently blocked
by five bugs. I have submitted patches for four of them and I will take
care of netbeans myself. I'm confident we can resolve this issue before
Buster freezes.

Status in a nutshell:

osmosis #913307 FIXED
igv #913323 PATCH
pegasus-wms FIXED
jameica FIXED
lucene-solr FIXED
sqlline FIXED
libreoffice-canzeley-client #913354 PATCH
libreoffice-base-drivers #913360 PATCH
jython FIXED
jclic #913343 PATCH
netbeans #913362 UNFIXED

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#913363: RFS: desktopfolder/1.0.10-1 [ITP]

[foss.freedom]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: desktopfolder
   Version : 1.0.10-1
   Upstream Author : José Amuedo Salmerón joseamu...@gmail.com
 * URL : https://github.com/spheras/desktopfolder
 * License : GPL-3+
   Section : x11

  It builds those binary packages:

desktopfolder - Organize your desktop with panels, notes and photos

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/desktopfolder/desktopfolder_1.0.10-1.dsc

  More information about desktopfolder can be obtained from
https://github.com/spheras/desktopfolder/blob/master/README.md

Notes:
I am the project lead of a Debian derivative called Ubuntu Budgie.  I
already maintain many Debian packages via my current Debian
Maintainers rights.

The reason for the request for this ITP is due to the current Nautilus
version in Debian.
We recognise that many budgie-desktop users expect a more traditional
desktop experience that includes the ability to place various files
and folders onto the desktop.  Budgie-Desktop had integrated with
Nautilus to provide that ability in the past.

But due to Nautilus 3.30 now in Buster, nautilus has removed the
desktop icons & folders support, Debian budgie users have had to use
strange workarounds such as running two File Managers - Nautilus and
Nemo where Nemo provides the desktop icons support.

This ITP provides an excellent alternative - a low memory usage
dedicated application that provides desktop icons & folders.

The application has been part of the ElementaryOS appcenter and
Elementary Pantheon.  I have been working with the maintainer to make
this application compatible with budgie-desktop.

As a project team Ubuntu Budgie have a direct interest in helping
support this application.  We now help the desktopfolder project to
provide translations for the project and we will be working with the
maintainer to provide additional capabilities in the future.

In terms of packaging I have worked with the maintainer to ensure
lintian issues such as code typos, mismatched copyright statements and
missing copyright statements on source files.  The maintainer has also
agreed to sign his tarballs which the package makes use of to provide
trust.

I have run check-all-the-things and helped resolve source matters in
consultation with the maintainer.

I have run lintian -i -I --pedantic on the built source.  One
Information lintian remains - missing autopkgtest.  I dont consider it
necessary for such a test to be defined.

I have built the debian/copyright via "cme update dpkg-copyright" and
manually checked that it has built the copyright file correctly.

The debian package contains one specific patch to revert two
ElementaryOS AppCenter specifics that doesn't make sense in the
context of Debian budgie-desktop.  This is explained in the dep3
header for the patch.  I have discussed this patch with the maintainer
and he is content with the approach.

If appropriate I would like to continue maintainership of this package
(assuming that it is acceptable to Debian) in a similar manner as my
current  packages (dak fossfree...@ubuntu.com)

  Changes since the last upload:

  * Initial Release (Closes: #913356)


  Regards,
   David Mohammed

Bug#913362: netbeans: please switch to libmariadb-java

[Markus Koschany]

Package: libnb-ide14-java
Version: 8.1+dfsg3-5
Severity: important

Hello,

we would like to remove libmysql-java from Debian because it is
frequently affected by security vulnerabilities which are not fully
disclosed. This makes it hard to determine the impact of such a flaw.[1]
However we also have libmariadb-java which is a drop-in replacement
and upstream is more transparent about security issues.

[1] https://bugs.debian.org/912916

Regards,

Markus

Bug#913361: checkbox-support: Don't include in Buster

[Jeremy Bicha]

Source: checkbox-support
Version: 0.22-1
Severity: serious
Tags: buster sid

I believe the checkbox stuff is no longer maintained. I expect someone
will file the RM bugs soon. Meanwhile, we can remove this package from
Testing with this RC bug.

Thanks,
Jeremy Bicha

Bug#903446: diffoscope: libarchive.exception.ArchiveError: Unrecognized archive format (via comparators.debian) with lie/2.2.2+dfsg-3

[Chris Lamb]

tags 903446 + pending
thanks

This is now fixed in Git, pending upload. I can confirm that (at
least) the previously-regressing rlib tests do not fail now.

The commit/diffstat is at:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/cd4c64234a7eebe71fb6bdea21850622f3f5c4c8

  diffoscope/comparators/elf.py|   2 ++
  diffoscope/comparators/utils/file.py |   4 
  tests/comparators/test_elf.py|   9 +
  tests/data/bug_903446.a  | Bin 0 -> 81069 bytes
  4 files changed, 15 insertions(+)


Regards,

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

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Markus Koschany]

Package: libreoffice-base-drivers
Version: 1:6.1.3-1
Severity: important
Tags: patch

Hello,

we would like to remove libmysql-java from Debian because it is
frequently affected by security vulnerabilities which are not fully
disclosed. This makes it hard to determine the impact of such a flaw.[1]
However we also have libmariadb-java which is a drop-in replacement
and upstream is more transparent about security issues.

Please find attached two patches that make the necessary changes to
the Debian packaging.

The 0001 patch can be applied for the Debian packaging. The 0002 patch must
be applied against the upstream sources. We have to replace the old
MySQL driver class with the new one from MariaDB. Except for that
libmariadb-java should just work.

[1] https://bugs.debian.org/912916

Regards,

Markus
>From 4fc33bd9b4969842bd092bbe62b4f119da749316 Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Fri, 9 Nov 2018 22:00:34 +0100
Subject: [PATCH] Switch from libmysql-java to libmariadb-java.

---
 control.in  | 4 ++--
 libreoffice-base.bug-control| 2 +-
 patches/jdbc-driver-classpaths.diff | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/control.in b/control.in
index a01b846b..3ee62c2c 100644
--- a/control.in
+++ b/control.in
@@ -581,7 +581,7 @@ Depends: libreoffice-core, ${shlibs:Depends}, 
${misc:Depends}
 Architecture: %OOO_BASE_ARCHS%
 Section: database
 Suggests: libreoffice-sdbc-postgresql | odbc-postgresql | libpg-java,
-  libreoffice-mysql-connector | libmyodbc | libmysql-java,
+  libreoffice-mysql-connector | libmyodbc | libmariadb-java,
   libsqliteodbc | tdsodbc | mdbtools,
   libjtds-java,
 Recommends: libreoffice-sdbc-hsqldb [%OOO_JAVA_ARCHS%], 
${base-firebird-recommends}
@@ -610,7 +610,7 @@ Description: Database connectivity drivers for LibreOffice
 - SQLite
 - MS SQL / Sybase SQL
 - *.mdb (JET / MS Access)
-  * libmysql-java | libpg-java | libjtds-java: JDBC Drivers
+  * libmariadb-java | libpg-java | libjtds-java: JDBC Drivers
 for:
 - MySQL
 - PostgreSQL
diff --git a/libreoffice-base.bug-control b/libreoffice-base.bug-control
index 67cfb8ba..26be7127 100644
--- a/libreoffice-base.bug-control
+++ b/libreoffice-base.bug-control
@@ -1,2 +1,2 @@
 report-with: libreoffice-core
-package-status: unixodbc libmyodbc odbc-postgresql libsqliteodbc tdsodbc 
mdbtools libmysql-java libpg-java libsapdbc-java
+package-status: unixodbc libmyodbc odbc-postgresql libsqliteodbc tdsodbc 
mdbtools libmariadb-java libpg-java libsapdbc-java
diff --git a/patches/jdbc-driver-classpaths.diff 
b/patches/jdbc-driver-classpaths.diff
index 1887772c..b3120667 100644
--- a/patches/jdbc-driver-classpaths.diff
+++ b/patches/jdbc-driver-classpaths.diff
@@ -8,9 +8,9 @@ index 9be30a2..59c87cb 100644

 +  
 +
-+  
++  
 +
-+  file:///usr/share/java/mysql.jar
++  file:///usr/share/java/mariadb-java-client.jar
 +
 +  
 +  
-- 
2.19.1

>From 1172166889764ae0e77488e5d173f33961b9859b Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Fri, 9 Nov 2018 23:06:15 +0100
Subject: [PATCH] mariadb

---
 connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java | 4 ++--
 .../mysql/org/openoffice/Office/DataAccess/Drivers.xcu| 2 +-
 connectivity/source/drivers/mysql/YDriver.cxx | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java 
b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
index a44f1b9d1..03a8293ef 100644
--- a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
+++ b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
@@ -59,7 +59,7 @@ public class JdbcLongVarCharTest extends ComplexTestCase
 
 String url = "jdbc:mysql://localhost:3306/mysql?user=root";
 com.sun.star.beans.PropertyValue prop[] = new PropertyValue[1];
-prop[0] = new PropertyValue("JavaDriverClass", 0, 
"com.mysql.jdbc.Driver", PropertyState.DIRECT_VALUE);
+prop[0] = new PropertyValue("JavaDriverClass", 0, 
"org.mariadb.jdbc.Driver", PropertyState.DIRECT_VALUE);
 
 // get the remote office component context
 XMultiServiceFactory xServiceManager = param.getMSF();
@@ -117,4 +117,4 @@ public class JdbcLongVarCharTest extends ComplexTestCase
 System.exit(0);
 }
 }
-}
\ No newline at end of file
+}
diff --git 
a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu 
b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
index 77988448f..acd8bfdaf 100644
--- a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
+++ b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
@@ -33,7 +33,7 @@
 
 
   
-com.mysql.jdbc.Driver
+org.mariadb.jdbc.Driver
   

Bug#913359: xkbcomp.pc requires libxkbfile-dev as dependency

[Mike Gabriel]

Package: x11-xkb-utils
Severity: normal
Version: 7.7+4

Hi,

we (NX upstream devs) did some experimenting today with "pkg-config  
--exists xkbcomp" and it failed on our build system.


The reason was that libxkbfile-dev was missing on the system.

Without libxkbfile-dev, "pkg-config --exists xkbcomp" exits with a  
non-zero exit code.


With libxkbfile-dev, "pkg-config --exists xkbcomp" exists with exit code 0.

Please consider adding libxkbfile-dev under Depends: of bin:pkg  
x11-xkb-utils. Thanks!


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgp1P5HmEp23N.pgp
Description: Digitale PGP-Signatur

Bug#913332: debian-edu-artwork: Please add debian-edu-artwork-buster as new binary package

[Mike Gabriel]

Hi,

On  Fr 09 Nov 2018 17:45:34 CET, Holger Levsen wrote:


On Fri, Nov 09, 2018 at 05:31:57PM +0100, Wolfgang Schweer wrote:

For now artwork could be based upon one of the proposed themes as available
here:  https://wiki.debian.org/DebianDesktop/Artwork/Buster
Once a decision has been taken, the theme could be replaced.


that. or we just write 'buster' in comic sans font over the stretch
artwork... :)


Why not add the d-e-a-buster package with copied over stretch artwork  
files? Upload to NEW, wait for ACK and then replace artwork files when  
ready.


?

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgpy2VUJ2uWJ3.pgp
Description: Digitale PGP-Signatur

Bug#842943: signap-desktop now built with electron

[Christopher Thompson]

I would like just voice my support for Debian going ahead with packaging
this project, if someone still has the interest (I do not have the
know-how myself).

An issue has been open since August 3 and continues to garner attention
from the community which is a bug preventing old-stable (and downstream
distros) from working AT ALL with current AND past Signal clients (as
the old versions have been blocked). It is my understanding this issue
is eminently addressable by packaging. There has so far been no response
from Signal maintainers, despite being directly addressed in the issue
multiple times. Additionally, arguments made by the Signal developers
not to have external packaging have now been proven incorrect, in large
part due to the existence/lack of attention to this issue.

I managed to get it working fine with the workaround by "scarf" - so, it
can be made to work by performing one of the suggested build or library
substitution procedures. In summary: no version available via packaging
works, or has worked for as much as three months now (I don't know how
recently the old versions stopped working).

Please see:
https://github.com/signalapp/Signal-Desktop/issues/2604

Thank you,
Chris

Bug#913351: man-db: lexgrog handles escaped hyphens after the first wrongly

[G. Branden Robinson]

At 2018-11-09T21:38:46+, Colin Watson wrote:
> Control: tag -1 fixed-upstream
> 
> On Fri, Nov 09, 2018 at 02:30:42PM -0500, G. Branden Robinson wrote:
> > $ for F in $(man -w tfmtodit hpftodit afmtodit); do lexgrog "$F"; zcat "$F" 
> > | sed -n '3,4 {/\\-/p}'; done
> > /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use 
> > with groff - Tdvi"
> > tfmtodit \- create font files for use with groff \-Tdvi
> > /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description 
> > files for use with groff - Tlj4"
> > hpftodit \- create font description files for use with groff \-Tlj4
> > /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use 
> > with groff - Tps and - Tpdf"
> > afmtodit \- create font files for use with groff \-Tps and \-Tpdf
> 
> Some day I may run across whoever decided that it was a good idea for
> man to have to parse a subset of *roff input in order to identify pages,
> and have some Stern Words with them about the wisdom of that design
> decision.

I'll contribute some stern words of my own; it is truly a layering
violation and a cruel one, at that.

> I think I've hacked this into shape:
> 
>   
> https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=95023279b69986a9c1fee841b2c626ae3973205c

Ah!  Had I bothered to find out you were maintaining man-db on Savannah,
I'd have gone straight there.  As you may know, I have an account there.
:)

>   $ for F in $(man -w tfmtodit hpftodit afmtodit); do src/lexgrog "$F"; done
>   /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use 
> with groff -Tdvi"
>   /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description 
> files for use with groff -Tlj4"
>   /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use 
> with groff -Tps and -Tpdf"

Looks good to me!  Thank you!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#913137: closed by Gianfranco Costamagna (Bug#913137: fixed in virtualbox 5.2.22-dfsg-1)

[Salvatore Bonaccorso]

Hi Gianfranco

Let's keep this open until it is confirmed that the changes 5.2.20 ->
5.2.22 are actually enough.

Did you got any confirmation on your query to upstream?

Regards,
Salvatore

Bug#845715: Required targets must not write outside of the source package tree

[Niels Thykier]

On Sat, 03 Nov 2018 12:38:55 -0700 Sean Whitton
 wrote:
> control: tag -1 +patch
> 
> Hello,
> 
> I reformatted and wordsmithed josch's patch, second it myself, and am
> seeking further seconds.
> 
> Given that whole archive rebuilds with use sbuild and already catch
> packages that violate this requirement, making this change would not
> declare any packages buggy that would not already be considered buggy,
> so we can make it right away.
> 
> [...]
> index dc80243..c486e7c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -291,6 +291,16 @@ For packages in the main archive, no required targets 
> may attempt
>  network access, except, via the loopback interface, to services on the
>  build host that have been started by the build.
> 
> +Required targets must not attempt to write outside of the unpacked
> +source package tree. An exception to this rule is the use of
> +``TMPDIR`` (or ``/tmp`` if that is not set) which is permitted as long
> +as temporary files are deleted by the end of the target, and not
> +reused by subsequent execution of the target.  This restriction is
> +intended to prevent source package builds creating and depending on
> +state outside of themselves, thus affecting multiple independent
> +rebuilds.  In particular, the required targets must not attempt to
> +write into ``HOME``.
> +
> [...]

I suspect we are missing an exception allowing the binary targets to
write the produced binaries in the parent directory of the unpacked
source tree.
  Otherwise pretty much all packages violate the policy when they
generate the actual .debs/.udebs. :)

Thanks,
~Niels

Bug#913351: man-db: lexgrog handles escaped hyphens after the first wrongly

[Colin Watson]

Control: tag -1 fixed-upstream

On Fri, Nov 09, 2018 at 02:30:42PM -0500, G. Branden Robinson wrote:
> $ for F in $(man -w tfmtodit hpftodit afmtodit); do lexgrog "$F"; zcat "$F" | 
> sed -n '3,4 {/\\-/p}'; done
> /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use with 
> groff - Tdvi"
> tfmtodit \- create font files for use with groff \-Tdvi
> /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description files 
> for use with groff - Tlj4"
> hpftodit \- create font description files for use with groff \-Tlj4
> /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use with 
> groff - Tps and - Tpdf"
> afmtodit \- create font files for use with groff \-Tps and \-Tpdf

Some day I may run across whoever decided that it was a good idea for
man to have to parse a subset of *roff input in order to identify pages,
and have some Stern Words with them about the wisdom of that design
decision.

I think I've hacked this into shape:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=95023279b69986a9c1fee841b2c626ae3973205c

  $ for F in $(man -w tfmtodit hpftodit afmtodit); do src/lexgrog "$F"; done
  /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use with 
groff -Tdvi"
  /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description files 
for use with groff -Tlj4"
  /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use with 
groff -Tps and -Tpdf"

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#913336: qemu-system-i386: Display 'gtk' is not available.

[Thorsten Glaser]

Michael Tokarev dixit:

>> pn  qemu-system-gui  
>
>Install this package (which is recommended and you're on your
>own if you don't install recommended packages) and you'll have
>gtk display.

Ah okay. The package is named unfortunately: I did look for
qemu-* packages with something like graphics in their name,
but skipped over qemu-system-* because I thought the * were
all systems.

Thanks for the heads-up!

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

Bug#913335: qemu-system-i386: Display 'sdl' is not available.

[Thorsten Glaser]

reopen 913336
thanks

Michael Tokarev dixit:

>> pn  qemu-system-gui  
>
>Ditto as for #913336.

Nope.

1. I still get “Display 'sdl' is not available.” if I select it.

2. qemu *still* runs a VNC server by default if the above package
   is not installed.

Additionally, GTK+3 is… problematic and has many dependencies
it pulls in, so the standard X11 display with SDL should still
work.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#741273: Add updated information

[Gabriel F. T. Gomes]

Control: tags -1 + upstream confirmed

The discussion mentioned in message 10 [1], and hosted on alioth
(decommissioned), has been migrated to the current upstream hosting and
bug tracking site as Issue #44 [2].

This bug is still reproducible in Debian *and* upstream, and a fix is
not available.  I will not work on it downstream nor upstream.


[1] https://bugs.debian.org/741273#10

[2] https://github.com/scop/bash-completion/issues/44

Bug#821397: ITP: sway -- i3-compatible Wayland compositor

[Sean Whitton]

Hello,

On Wed 07 Nov 2018 at 10:13PM -0500, Jeremy Bicha wrote:

> Sean, did you see the full email that added the pending tag?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821397;msg=56

I hadn't.  Thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Michael Biebl]

Am 09.11.18 um 21:01 schrieb Dmitry Bogatov:
> 
> [2018-11-08 19:06] Michael Biebl 
>> Am 08.11.18 um 18:54 schrieb Ian Jackson:
>>
>>> env(1) would be helpful here.  If your daemon is on /usr anyway then
>>> it doesn't matter that it isn't in /bin.
>>
>> /usr is mounted by the initramfs nowadays, so this wouldn't be an issue
>> in practice.
> 
> I made some experiments on FreeBSD-11 virtual image. I believe for
> puproses we discuss, it is as good, as Debian GNU/kFreeBSD.
> 
>  * Note in /etc/init.d/skeleton still holds true -- shell script can't
>be used as interpreter in #! of another script
>  * Trick with #!/usr/bin/env /path/to/script works.
> 
> As such, I will update init-d-script(5) and it will close this bug.

Just tried the
#!/usr/bin/env /lib/init/init-d-script
proposal.
Seem like this breaks the systemctl integration again.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826214

Regards,
Michael
-- 
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#906643: Bug#911832: Bug#906643: transition: php7.3

[Ondřej Surý]

Paul,

thank you for all the effort you have put into this. I understand and 
appreciate the effort.

I am basically not objecting to whatever solution there will be, it is 
ultimately that package maintainer’s decision, and I am sorry I can’t be more 
helpful, but my free time is limited and all I wanted was to clear the packages 
preventing faster migration of php-defaults to testing (which I failed anyway 
because of that last package...)

Thanks,
Ondřej 
--
Ondřej Surý 

> On 9 Nov 2018, at 21:12, Paul Gevers  wrote:
> 
> Hi,
> 
>> On 09-11-18 20:09, Ondřej Surý wrote:
>> But somehow for this simple package I would just prefer to just bite
>> the bullet once in a while, do binNMU and then suffer it through… My
>> experience tells me that “the simpler the better” even if it’s not
>> perfect. Perfect but complex tend to break in more mysterious way...
> 
> Yes, except that for regressions there may be more people watch (like
> me) that will not know these details and waste their time understanding.
> 
> I've just triggered the combination now, but I am not happy yet with the
> final outcome.
> 
> Paul
> 

Bug#913358: bash: should drop build-dependency on deprecated texi2html, override pkg-config Lintian Error

[Luca Boccassi]

Package: bash
Version: 5.0~alpha1-1
Severity: minor
Tags: patch

Dear Maintainer,

texi2html is deprecated. Removing the build dependency does not change
the bash-doc package content, I verified it with diffoscope. I think
it's already using makeinfo, which is the suggested alternative:

https://wiki.debian.org/Texi2htmlTransition

Upstream's pkg-config file includes 2 flags that Lintian doesn't like,
but I think they are valid as it's for building loadable modules.

Inlined a patch to fix both for 5.0, please kindly consider applying
it.

Thank you!

Lintian Errors:

 E: bash source: build-depends-on-obsolete-package build-depends: texi2html
 N: 
 N:The package build-depends on a package that has been superseded. If the
 N:superseded package is part of an ORed group, it should not be the first
 N:package in the group.
 N:
 N:Severity: important, Certainty: possible
 N:
 N:Check: fields, Type: binary, udeb, source
 N: 
 E: bash-builtins: pkg-config-bad-directive usr/lib/pkgconfig/bash.pc -fPIC
 N: 
 N:The pkg-config file contains a wrong directive.
 N:
 N:The following file includes a wrong directive. This could lead to FTBFS
 N:or leak private compile flags to another package.
 N:
 N:Severity: serious, Certainty: possible
 N:
 N:Check: files, Type: binary, udeb
 N: 
 E: bash-builtins: pkg-config-bad-directive usr/lib/pkgconfig/bash.pc 
-Wl,-soname,$@

-- 
Kind regards,
Luca Boccassi

--- /dev/null
+++ b/debian/bash-builtins.lintian-overrides
@@ -0,0 +1 @@
+bash-builtins: pkg-config-bad-directive
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: required
 Maintainer: Matthias Klose 
 Standards-Version: 4.2.1
 Build-Depends: autoconf, autotools-dev, bison, libncurses5-dev,
- texinfo, texi2html, debhelper (>= 9.20160115~), gettext, sharutils,
+ texinfo, debhelper (>= 9.20160115~), gettext, sharutils,
  locales , time ,
  xz-utils, dpkg-dev (>= 1.16.1), man2html
 Build-Depends-Indep: texlive-latex-base, ghostscript, texlive-fonts-recommended

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

Bug#913316: qtbase-opensource-src: Check why we are dlOpening() libGl instead of just linking it

[Dmitry Shachnev]

On Fri, Nov 09, 2018 at 11:22:05AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Check https://codereview.qt-project.org/#/c/245064/ and it's comments.
>
> The code seems to support linking, but somehow we don't do it.

Interesting that we *do* link to libGL:

  $ ldd 
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
 | grep libGL.so
  libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 
(0x7ffade5aa000)

Also the code does *not* support linking.

The code first tries dlopen(NULL, RTLD_LAZY). According to dlopen(3) manpage,
if filename is NULL, then the returned handle is for the main program.

This does not work when the main program is Python — python interpreter is
not linked against libGL.so.

When the first dlopen() call does not find the needed GL symbols, it tries to
dlopen() libGL.so, via the QLibrary wrapper. That almost always succeeds,
the patch in linked codereview should fix the remaining problems.

I think there is nothing for us to fix in *this* bug, and it can be closed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#908678: Some more thoughts and some tests on the security-tracker git repo

[Antoine Beaupré]

On 2018-09-26 14:56:16, Daniel Lange wrote:

[...]

> In any case, a repo with just the split files but no maintained history clones
> in ~12s in the above test setup. It also brings the (bare) repo down from 
> 3,3GB
> to 189MB. So the issue is really the data/CVE/list file.

So I've looked in that problem as well, four months ago:

https://salsa.debian.org/security-tracker-team/security-tracker/issues/2

In there I proposed splitting the data/CVE/list file into "one file per
CVE". In retrospect, that was a rather naive approach and yielded all
sorts of problems: there were so many files that it create problems even
for the shell (argument list too long).

I hadn't thought of splitting things in "one *file* per year". That
could really help! Unfortunately, it's hard to simulate what it would
look like *14 years* from now (yes, that's how old that repo is
already).

I can think of two ways to simulate that:

 1. generate commits to recreate all files from scratch: parse
data/CVE/list, split it up into chunks, and add each CVE in one
separate commit. it's not *exactly* how things are done now, but it
should be a close enough approximation

 2. do a crazy filter-branch to send commits to the right
files. considering how long an initial clone takes, i can't even
begin to imagine how long *that* would take. but it would be the
most accurate simulation.

Short of that, I think it's somewhat dishonest to compare a clean
repository with split files against a repository with history over 14
years and thousands of commits. Intuitively, I think you're right and
that "sharding" the data in yearly packets would help a lot git's
performance. But we won't know until we simulate it, and if hit that
problem again 5 years from now, all that work will have been for
nothing. (Although it *would* give us 5 years...)

> That said, data/DSA/list is 14575 lines. That seems to not bother git too much
> yet. Still if things get re-structured, this file may be worth a look, too.

Yeah, I haven't had trouble with that one yet either.

> To me the most reasonable path forward unfortunately looks like start a new 
> repo
> for 2019+ and "just" import the split files or single-record files as 
> mentioned
> by pabs but not the git/svn/cvs history. The old repo would - of course - stay
> around but frozen at a deadline.

In any case, I personally don't think history over those files is that
critical. We rarely dig into that history because it's so
expensive... Any "git annotate" takes forever in this repo, and running
*that* it over data/CVE/list takes tens of minutes.

That said, once we pick a solution, we *could* craft a magic
filter-branch that *would* keep history. It might be worth eating that
performance cost then. I'll run some tests to see if I can make sense of
such a filter.

> Corsac also mentioned on IRC that the repo could be hosted outside of Gitlab.
> That would reduce the pressure for some time.
> But cgit and other git frontends (as well as backends) we tested also struggle
> with the repo (which is why my company, Faster IT GmbH, used the 
> security-tracker
> repo as a very welcome test case in the first place).
> So that would buy time but not be a solution long(er) term.

Agreed. I think the benefits of hosting on gitlab outweigh the trouble
in rearchitecturing our datastore. As I said, it's not just gitlab
that's struggling with a 17MB text file: git itself has trouble dealing
with it as well, and I am often frustrated by that in my work...

A.

-- 
You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
- Theo de Raadt

Bug#913352: bs1770gain: Concern about white supremacist statements in bs1770gain 0.5.1

[daniel]

Hi Steve,I asked the upstream author about this. I don't know if Debian has a 
policy against neo-Nazi hashtags but it's not what I expect to find in an 
operating system meant to be for everyone.I would support patching this 
package, but the offensive text would remain in the source package I 
guess.Cheers!Daniel
null

Bug#913300: gmrender-resurrect: fails to autobuild because of libupnp transition

[Uwe Kleine-König]

Hello Tobi,

On 11/9/18 7:57 PM, Tobias Frost wrote:
> Go ahead with the NMU ( you can also do a teamupload, as the package is in 
> the Debian group of salsa... At least I think it is, but I can't check due to 
> weak internet here))

I interpreted that as an Ack to upload to delayed/0. I kept it the way I
announced here (i.e. NMU, no team upload) because I had everything in
place already. I pushed my changes (including a tag) to master on salsa now.

Thanks for your feedback
Uwe



signature.asc
Description: OpenPGP digital signature

Bug#913357: [php-redis] Missing support for default PHP version

[Adrien CLERC]

Package: php-redis
Version: 4.2.0~rc2-1
Severity: normal

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

Hi,

Along with #911670 and #911719, the php-redis package lacks support for
the current default PHP version in buster (7.2), and is only built with 7.3.

I'm sorry to open new bug reports, but even if I saw that we are in a
middle of 7.2 to 7.3 transition
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911670#11), it seems
difficult to completely ignore this, either in changelog.Debian or
NEWS.Debian. And as long as the default PHP version is 7.2, all modules
should be at least built with this one, along with 7.3 to ease the
transition.

What's the plan for buster anyway? Having the default version to 7.3
seems fine, but removing supports for all older versions would likely
break some applications.

Adrien


--- System information. ---
Architecture:
Kernel: Linux 4.18.0-2-amd64

Debian Release: buster/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.fr.debian.org
500 testing download.jitsi.org
1 experimental ftp.fr.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#913045: [Pkg-alsa-devel] Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Pedro Silva]

On Fri, 9 Nov 2018 06:29:49 +0100 Elimar Riesebieter 
wrote:
> * Pedro Silva  [2018-11-08 22:25 +]:
>
> [...]
> >
> > This is getting weird.
> >
> > Even with the $HOME/.asoundrc file, I've nailed it down to not being
> > able to play two sound sources at the same time.
>
> Could you please add:
>
> ###
> ctl.snd_card {
> type hw
> card 2
> device 2
> }
> ###
>
> to your .asoundrc and try again?
>
> Thanks
> Elimar
> --
> Alles, was viel bedacht wird, wird bedenklich!;-)
> Friedrich Nietzsche

No difference.

Reboot, login, start game, sound ok. Start browser, play youtube video,
playback hangs until game is closed.

cat ~/.asoundrc
###
pcm.!default {
    type hw
    card 2
}
###
ctl.snd_card {
    type hw
    card 2
    device 2
}
###

Best regards,
Pedro Silva

Bug#913356: ITP:desktopfolder - Bring your Desktop Back to Life

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed (fossfree...@ubuntu.com)

Package name : desktopfolder
Version : 1.0.10
Upstream Author : joseamu...@gmail.com
URL : https://github.com/spheras/desktopfolder
License : GPL-3+
Programming Lang: Vala
Description : Organize your desktop with panels, notes and photos.

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Michael Biebl]

Am 09.11.18 um 20:22 schrieb Holger Levsen:
> On Fri, Nov 09, 2018 at 07:56:27PM +0100, Michael Biebl wrote:

>>> │ │ │ ├── ./usr/lib/systemd/tests/test-hexdecoct
>> ...
>>> │ │ │ │ │0x0878 48415245 44002f6c 69622f73 79737465 HARED./lib/syste
>>> │ │ │ │ │ -  0x0888 6d640068 61726564 00md.hared.
>>> │ │ │ │ │ +  0x0888 6d640068 61726564 3a244f52 4947494e md.hared:$ORIGIN
>>> │ │ │ │ │ +  0x0898 2f2e2e2f 2e2e2f2e 2e2f2e2e 2f6c6962 /../../../../lib
>>> │ │ │ │ │ +  0x08a8 2f783836 5f36342d 6c696e75 782d676e /x86_64-linux-gn
>>> │ │ │ │ │ +  0x08b8 7500   
>  
> That's due to usrmerge? (and not rebuilding in a different path?)
> There's no "usr/bin" in that diffoscope output anywhere?

Yeah, somehow meson get's confused on a usr-merged system and then
embeds such a bogus RUNPATH
See
https://github.com/mesonbuild/meson/issues/4392
and
https://github.com/systemd/systemd/issues/10430

regards,
Michael


-- 
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#913355: libuhd-dev: UHDConfig.cmake includes nonexisting UHDTargets.cmake

[Adrian Bunk]

Package: libuhd-dev
Version: 3.13.0.2-2
Severity: serious
Control: affects -1 src:gnuradio  src:soapyuhd

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

...
--   Enabling gr-trellis support.
--   Override with -DENABLE_GR_TRELLIS=ON/OFF
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/uhd/UHDConfig.cmake:111 
(include):
  include could not find load file:

/UHDTargets.cmake
Call Stack (most recent call first):
  cmake/Modules/FindUHD.cmake:43 (find_package)
  gr-uhd/CMakeLists.txt:25 (find_package)

Bug#913344: Bug#913345: Video seek causes video track to lag when the "Hurry up" setting is not enabled in VLC 3.X

[bakhelit]

As requested I reported both issues to VLC upstream. Links are:
https://trac.videolan.org/vlc/ticket/21440
https://trac.videolan.org/vlc/ticket/21439

I also added the output of "vlc -vvv" to the issue where at least 
something relevant to the bug report seemed to be in the VLC output.


Regards,
Bakhelit

Bug#913354: libreoffice-canzeley-client: please switch to libmariadb-java

[Markus Koschany]

Package: libreoffice-canzeley-client
Version: 0.5.1-1
Severity: important
Tags: patch

Hello,

we would like to remove libmysql-java from Debian because it is
frequently affected by security vulnerabilities which are not fully
disclosed. This makes it hard to determine the impact of such a flaw.[1]
However we also have libmariadb-java which is a drop-in replacement
and upstream is more transparent about security issues.

Please find attached a patch that make the necessary changes to
the Debian packaging.

[1] https://bugs.debian.org/912916

Regards,

Markus
>From e92546baa42ffa32db69d4ae2e35fa446b0e7622 Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Fri, 9 Nov 2018 21:18:56 +0100
Subject: [PATCH] Switch from libmysql-java to libmariadb-java.

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

diff --git a/debian/changelog b/debian/changelog
index 5a583c9..a493a34 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libreoffice-canzeley-client (0.5.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from libmysql-java to libmariadb-java.
+
+ -- Markus Koschany   Fri, 09 Nov 2018 21:19:16 +0100
+
 libreoffice-canzeley-client (0.5.1-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 764b1a9..2e16ba9 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Browser: 
https://anonscm.debian.org/cgit/collab-maint/libreoffice-canzeley-c
 
 Package: libreoffice-canzeley-client
 Architecture: all
-Depends: libmysql-java | libreoffice-mysql-connector,
+Depends: libmariadb-java | libreoffice-mysql-connector,
libreoffice-base,
libreoffice-common,
libreoffice-writer,
-- 
2.19.1

Bug#912573: Remove postgresql-10 from testing (also, will fail to binNMU)

[Christoph Berg]

Control: clone -1 -2
Control: severity -2 normal
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: postgresql-10 -- ROM; superseded by postgresql-11

Re: To Debian Bug Tracking System 2018-11-01 
<20181101123712.ga32...@msg.df7cb.de>
> postgresql-10 should be removed from testing, as postgresql-11 has
> already transitioned.
> 
> Dependency problems are currently:

All the reverse depends have been updated, so postgresql-10 can be
removed from unstable now.

Thanks,
Christoph

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Paul Gevers]

Hi,

On 09-11-18 20:09, Ondřej Surý wrote:
> But somehow for this simple package I would just prefer to just bite
> the bullet once in a while, do binNMU and then suffer it through… My
> experience tells me that “the simpler the better” even if it’s not
> perfect. Perfect but complex tend to break in more mysterious way...

Yes, except that for regressions there may be more people watch (like
me) that will not know these details and waste their time understanding.

I've just triggered the combination now, but I am not happy yet with the
final outcome.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#913288: netcat-openbsd: udptest returns false positives

[Guilhem Moulin]

On Fri, 09 Nov 2018 at 19:16:39 +, Mendelmunkis wrote:
>> Which error(s) do you have in mind?
> 
> “destination unreachable” comes to mind.
> Right now it only checks for connection refused

I'm confused, if write(2) returns -1 and sets errno to ‘ECONNREFUSED’,
it might be *because* an ICMP “Destination unreachable” message was just
received on the socket.

E.g, for the following trace

$ strace -e trace=write nc -vuN 127.0.0.1 12345
write(3, "X", 1)= 1
write(3, "X", 1)= -1 ECONNREFUSED (Connection 
refused)
+++ exited with 1 +++

I captured these UDP & ICMP packets on the loopback interface:

21:04:31.475446 IP 127.0.0.1.55080 > 127.0.0.1.12345: UDP, length 1
21:04:31.475469 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 12345 
unreachable, length 37

(using `tcpdump -n -i lo "icmp or udp dst portrange 12345"`).  The
received ICMP packet is what caused the second write to fail with
‘ECONNREFUSED’.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#910939: dds: Fails to build on i386

[Christoph Berg]

Re: Jeremy Bicha 2018-10-13 

> dds fails to build on i386, in the build test stage:
> 
> 
> LD_LIBRARY_PATH=src examples/DealerPar
> terminate called after throwing an instance of 'std::length_error'
>   what():  vector::_M_default_append
> Aborted

Fwiw, I'm investigating, but haven't found the bug yet. "-flto" binaries
are special beasts to debug.

Christoph

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Dmitry Bogatov]

[2018-11-08 19:06] Michael Biebl 
> Am 08.11.18 um 18:54 schrieb Ian Jackson:
> 
> > env(1) would be helpful here.  If your daemon is on /usr anyway then
> > it doesn't matter that it isn't in /bin.
> 
> /usr is mounted by the initramfs nowadays, so this wouldn't be an issue
> in practice.

I made some experiments on FreeBSD-11 virtual image. I believe for
puproses we discuss, it is as good, as Debian GNU/kFreeBSD.

 * Note in /etc/init.d/skeleton still holds true -- shell script can't
   be used as interpreter in #! of another script
 * Trick with #!/usr/bin/env /path/to/script works.

As such, I will update init-d-script(5) and it will close this bug.

Bug#913352: Link to source code

[Steven Peters]

Here is a link to the offending source code:

https://salsa.debian.org/multimedia-team/bs1770gain/blob/41b7092d7e65b52f329dd45b55b45f152e29eedf/bs1770gain/bs1770gain.c#L61-72

Bug#912937: runit: Can't shutdown or reboot when using single user mode

[Dmitry Bogatov]

control: reopen -1

[2018-11-09 01:09] alecfeld...@disroot.org

> Glancing over the changes, changing the runsvdir is a bad idea, since
> now stage 3 won't stop t he correct services.
> 
> sv force-stop /etc/service/*
> sv exit /etc/service/*

Good catch. It need to be changed too. But I consider not stopping
`sulogin` a very minor issue.

> You set the service directory to /etc/runit/runsvdir/single if
> "single" kernel paramter is use d, so sulogin won't be properly
> stopped when shutting down.

Yeah, /etc/runit/3 need to be adjusted.

> Instead, the runsvchdir command addresses this problem. Just have
> /etc/service symlinked to /etc/runit/runsvdir/current. current is then
> symlinked to default (sorry for not being clearer on this matter). So,
> in simplistic terms: /etc/sv/ --> /etc/service -->
> /etc/runit/runsvdir/current --> /etc/runit/runsv dir/default
> (relative). When using "single", runsvchdir will switch the current
> symlink to /etc/runit/runsvdir/single.

And when it will be restored to point to default? And what about sudden
power outage? And what about /etc/runit/runsvdir/{foo,bar}, maintained
by local system administrator? Too many questions, too many corner
cases, too many moving parts.

> I'm not sure what you mean by virtual filesystems?

Everything under /proc, /sys and /dev. While I use Linux kernel, I
prefer to tie myself as little as possible to its features, unless
strictly necessery.

Bug#703010: (no subject)

[Dmitry Bogatov]

control: tag -1 +moreinfo

On my laptop, there is no VxID in /proc/self/status:

$ cat /proc/self/status
Name:   cat
Umask:  0022
State:  R (running)
Tgid:   11990
Ngid:   0
Pid:11990
PPid:   11989
TracerPid:  0
Uid:1000100010001000
Gid:1000100010001000
FDSize: 64
Groups: 24 25 27 29 30 44 46 108 109 111 116 999 1000 
NStgid: 11990
NSpid:  11990
NSpgid: 11570
NSsid:  2243
VmPeak: 4172 kB
VmSize: 4172 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:   744 kB
VmRSS:   744 kB
RssAnon:  64 kB
RssFile: 680 kB
RssShmem:  0 kB
VmData:  312 kB
VmStk:   136 kB
VmExe:28 kB
VmLib:  1424 kB
VmPTE:48 kB
VmSwap:0 kB
HugetlbPages:  0 kB
CoreDumping:0
Threads:1
SigQ:   0/15123
SigPnd: 
ShdPnd: 
SigBlk: 
SigIgn: 
SigCgt: 
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 003f
CapAmb: 
NoNewPrivs: 0
Seccomp:0
Speculation_Store_Bypass:   vulnerable
Cpus_allowed:   f
Cpus_allowed_list:  0-3
Mems_allowed:   ,0001
Mems_allowed_list:  0
voluntary_ctxt_switches:0
nonvoluntary_ctxt_switches: 0


pgpGCk6p_KYu7.pgp
Description: PGP signature

Bug#913154: Please move /etc/init.d/skeleton

[Dmitry Bogatov]

[2018-11-08 18:52] Michael Biebl 
> Am 08.11.18 um 12:48 schrieb Dmitry Bogatov:
> > 
> > [2018-11-07 18:39] Michael Biebl 
> >> please consider moving the skeleton init script from /etc/init.d to a
> >> different place. My proposal would be
> >> /usr/share/doc/initscripts/examples/
> >>
> >> Being installed in /etc/init.d has several undesirable consequences
> >> a/ it's marked as a conffile when it really isn't
> >> b/ it clutters tab completion
> >> c/ it clutters /etc/init.d/
> > 
> > I do support this proposal. But this location is mentioned in Policy[1].
> > 
> > https://sources.debian.org/src/debian-policy/4.2.1.4/policy/ch-opersys.rst/?hl=631#L631
> 
> fwiw, I'd be fine if /etc/init.d/skeleton was dropped completely given
> there is a init-d-script man page with a ready to use example that can
> be copy easily.

Then it will be done. BTW, I opened #913295 about it aganist
debian-policy.

Bug#889180: plasma: memory leak

[Stefano Forli]

The bug seems to be still alive with the recent framework version
(5.49.0-1) with plasma-desktop/-workspace 4:5.13.5-1+b1.
On my workstation (5 days uptime, at the moment), the OOM's kill pretty
much everything, including Kwin.
I can recover the system by restarting plasma, but not everything can be
recovered.

I have no screensavers and the screen turns off after 2 minutes.


On Wed, 21 Feb 2018 17:05:08 -0300 Alex Henry  wrote:
> Yes, about every 5 minutes with a large slideshow collection too. However,
> if I sit on KSysGuard I can see the memory usage creeping up after Plasma
> has been started, probably before any image has actually changed.
>
> Also, I have the same configuration and pretty much exactly the same
> wallpaper collection on my desktop computer and I don't have a memory leak
> there.
>
> (I had made this message days ago but replied to Lisandro only and not to
> the bug address.)
>
> I have since also determined that my desktop computer suffers from the
same
> issue. At one point it may be using as little as a couple hundred
> megabytes, and then later on, not necessarily many hours apart, it'll be
> well on its way to 2 gigabytes of RAM being consumed. It seems to be
pretty
> much random how much it grows except that it tends to definitely grow over
> time. Logging out and logging in again from KDE resets the memory usage.
>
> On 6 February 2018 at 16:00, Lisandro Damián Nicanor Pérez Meyer <
> perezme...@gmail.com> wrote:
>
> > Hi Alex! Would you mind if I reply to the bug number too and not just
you?
> >
> > On 6 February 2018 at 12:08, Alex Henry  wrote:
> > > Yes, about every 5 minutes with a large slideshow collection too.
> > However,
> > > if I sit on KSysGuard I can see the memory usage creeping up after
Plasma
> > > has been started, probably before any image has actually changed.
> > >
> > > Also, I have the same configuration and pretty much exactly the same
> > > wallpaper collection on my desktop computer and I don't have a memory
> > leak
> > > there.
> > >
> > > On 3 February 2018 at 14:38, Lisandro Damián Nicanor Pérez Meyer
> > >  wrote:
> > >>
> > >> On 3 February 2018 at 13:37, Lisandro Damián Nicanor Pérez Meyer
> > >>  wrote:
> > >> > Control: tag -1 moreinfo
> > >> >
> > >> > On 2 February 2018 at 23:54, Alex Henry  wrote:
> > >> >> I checked on my dekstop and plasmashell sits at around 350MB of
> > memory
> > >> >> use
> > >> >> there - but that's after over 6 hours uptime, not a mere 10
minutes
> > or
> > >> >> so.
> > >> >> Even then, it's using double that amount in my laptop, even when
both
> > >> >> have
> > >> >> largely default configurations and the same version being used so
it
> > >> >> definitely seems something's amiss here.
> > >> >
> > >> > Do you have your background image changing from time to time?
> > >>
> > >> I mean, the wallpaper.
> > >>
> > >> --
> > >> Lisandro Damián Nicanor Pérez Meyer
> > >> http://perezmeyer.com.ar/

Bug#913352: bs1770gain: Concern about white supremacist statements in bs1770gain 0.5.1

[Steve Peters]

Source: bs1770gain
Version: 0.5.1
Severity: normal

Dear Maintainer,

I noticed the bs1770gain software package has white supremacist political
statements on the project website, which were added to the website in January
2017, after the release of version 0.4.12 of the software.

* http://bs1770gain.sourceforge.net/#political

Some of these statements have been added to to the source code in version 0.5.1
and are displayed with the usage information (see line 62 of bs1770gain.c).

I don't think Debian should distribute software containing these statements.
Perhaps it could be removed with a patch or by rolling back to 0.4.12.

Regards,
Steve Peters



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

Kernel: Linux 4.4.0-135-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#747646: netcat-openbsd: UDP connections start with "XXXXX" junk

[Guilhem Moulin]

On Fri, 09 Nov 2018 at 13:17:11 -0500, Moshe Piekarski wrote:
> Performing this test with blank packets still works without the server seeing 
> anything.
> […]
> - if ((write(s, "X", 1) != 1) && (errno == ECONNREFUSED))
> + if ((write(s, "", 1) != 1) && (errno == ECONNREFUSED))

That makes the server see a bunch of ‘\0’s instead of ‘X’s; I'd argue
that writing control characters is more confusing than writing something
visible.

OTOH, ‘write(fd, buf, 0)’ has an undefined behavior; in practice an
empty message is sent (as for ‘send(s, NULL, 0, 0)’), but receiving an
empty buffer is what terminates the poll loop, so if the listening side
is `nc -u -l` (without ‘-k’), it closes the socket and exit() before the
client has a chance to perform further write()s.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#913350: chmod: changing permissions of '/.../body_neg100.so': Operation not permitted

[Sebastian Ramacher]

On 2018-11-09 20:27:03, Sebastian Ramacher wrote:
> Package: sa-compile
> Version: 3.4.2-1~deb9u1
> Severity: grave
> 
> Upgrading sa-compile to the version in stretch-proposed-updates fails with
> | Setting up sa-compile (3.4.2-1~deb9u1) ...
> | Running sa-compile (may take a long time)
> | chmod: changing permissions of 
> '/var/lib/spamassassin/compiled/5.024/3.004001/auto/Mail/SpamAssassin/CompiledRegexps/body_neg100/body_neg100.so':
>  Operation not permitted
> | dpkg: error processing package sa-compile (--configure):
> |  subprocess installed post-installation script returned error exit status 1
> | Errors were encountered while processing:
> |  sa-compile

This file is owned by root:root. After moving it away, installation succeeded.

The failing line of the postinst script is:

# Fixup perms -- group and other should be able to
# read and execute, but never write.  Works around
# sa-compile's failure to obey umask.
runuser -u debian-spamd -- \
chmod -R go-w,go+rX /var/lib/spamassassin/compiled

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#913351: man-db: lexgrog handles escaped hyphens after the first wrongly

[G. Branden Robinson]

Package: man-db
Version: 2.8.4-2+b1
Severity: normal
Tags: upstream

$ for F in $(man -w tfmtodit hpftodit afmtodit); do lexgrog "$F"; zcat "$F" | 
sed -n '3,4 {/\\-/p}'; done
/usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use with 
groff - Tdvi"
tfmtodit \- create font files for use with groff \-Tdvi
/usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description files 
for use with groff - Tlj4"
hpftodit \- create font description files for use with groff \-Tlj4
/usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use with 
groff - Tps and - Tpdf"
afmtodit \- create font files for use with groff \-Tps and \-Tpdf

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

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

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  groff-base 1.22.3-10
ii  libc6  2.27-8
ii  libgdbm6   1.18.1-1
ii  libpipeline1   1.5.0-2
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13.1-3+b1
ii  chromium [www-browser] 70.0.3538.67-2
ii  firefox-esr [www-browser]  60.3.0esr-1
ii  groff  1.22.3-10
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  w3m [www-browser]  0.5.3-36+b1

-- debconf information:
* man-db/install-setuid: false
  man-db/auto-update: true

Bug#911364: firefox-esr: Master password lost after update from ESR v52.9.0 to ESR v60.2.2 (along with all user certificates and saved passwords)

[Andreas Stempfhuber]

Package: firefox-esr
Version: 60.3.0esr-1~deb8u1
Followup-For: Bug #911364

Dear Maintainer,

what could possibly go wrong when updating Firefox ESR to the next major 
release?


This issue now arrived in Debian Jessie. I can confirm and reproduce it 
with this steps. Prerequisite is that a master password is used:


1. Delete ~/.mozilla directory and restore it from a backup that was 
made from Firefox ESR 52

2. Start Firefox ESR 60
3. Close Firefox ESR 60
4. Start Firefox ESR 60 again

-> All saved passwords are permanently gone!


The issue can be avoided by entering the master password on the very 
first start of Firefox ESR 60. Reproduction steps:


1. Delete ~/.mozilla directory and restore it from a backup that was 
made from Firefox ESR 52

2. Start Firefox ESR 60
3. Unlock the password store by entering the master password
4. Close Firefox ESR 60
5. Start Firefox ESR 60 again

-> Saved passwords are intact.


The key issue is that the key3.db file is not properly migrated to the 
new version and during the migration it is even destroyed. The key3.db 
is therefore required from a backup to restore the saved passwords. This 
can be even an older backup. That way, it is possible to restore 
recently saved passwords by using a key3.db file from an older backup:


1. Delete key4.db file from the Firefox ESR 60 profile (e.g. 
~/.mozilla/firefox/.default/key4.db)

2. Replace key3.db file from an older backup
3. Start Firefox ESR 60
4. Unlock the password store by entering the master password
5. Close Firefox ESR 60
6. Start Firefox ESR 60 again

-> Saved passwords are restored.


On affected systems both key3.db and key4.db files exist. Where on a 
properly migrated installation, only key4.db file exists. It should be 
therefore possible to detect if a user was affected by this issue.


Thanks

Andreas


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.9.0-0.bpo.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox-esr depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u10
ii  libcairo-gobject2 1.14.0-2.1+deb8u2
ii  libcairo2 1.14.0-2.1+deb8u2
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+deb8u1
ii  libffi6   3.1-2+deb8u1
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u2
ii  libgcc1   1:4.9.2-10+deb8u1
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u7
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk-3-03.14.5-1+deb8u1
ii  libpango-1.0-01.36.8-3
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10+deb8u1
ii  libx11-6  2:1.6.2-3+deb8u2
ii  libx11-xcb1   2:1.6.2-3+deb8u2
ii  libxcb-shm0   1.10-3+b1
ii  libxcb1   1.10-3+b1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+deb8u1
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9+deb8u1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages firefox-esr recommends:
ii  libavcodec56  6:11.12-1~deb8u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u4
ii  libgtk2.0-02.24.25-3+deb8u2
pn  pulseaudio 

-- no debconf information

Bug#913350: chmod: changing permissions of '/.../body_neg100.so': Operation not permitted

[Sebastian Ramacher]

Package: sa-compile
Version: 3.4.2-1~deb9u1
Severity: grave

Upgrading sa-compile to the version in stretch-proposed-updates fails with
| Setting up sa-compile (3.4.2-1~deb9u1) ...
| Running sa-compile (may take a long time)
| chmod: changing permissions of 
'/var/lib/spamassassin/compiled/5.024/3.004001/auto/Mail/SpamAssassin/CompiledRegexps/body_neg100/body_neg100.so':
 Operation not permitted
| dpkg: error processing package sa-compile (--configure):
|  subprocess installed post-installation script returned error exit status 1
| Errors were encountered while processing:
|  sa-compile

Cheers

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

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


signature.asc
Description: PGP signature

Bug#912900: perl: Storable stack recursion limit probe in 5.28 seems overly sensitive

[Niko Tyni]

Control: clone -1 -2
Control: retitle -2 perl: needs to Break older apt-show-versions versions

On Sun, Nov 04, 2018 at 09:23:15PM +0200, Niko Tyni wrote:
> Package: perl
> Version: 5.28.0-3
> Severity: important
> Tags: upstream
> 
>   % perl -MStorable=nstore -e '$h->{$i}{a}{b}{c} = 0 while $i++<1; 
> nstore($h, "testfile")'
>   Max. recursion depth with nested structures exceeded at 
> /usr/lib/x86_64-linux-gnu/perl/5.28/Storable.pm line 278, at -e line 1.
> 
> The documentation states
> 
>   Since Storable 3.05 we probe for the stack recursion limit for
>   references, arrays and hashes to a maximal depth of ~1200-35000,
>   otherwise we might fall into a stack-overflow.
> 
> but there's no recursion involved here, so it looks like the probe
> heuristic is not quite working?
> 
> This broke apt-show-versions (#912695) and is sort of a regression,
> not quite sure if we should consider it release critical or not.

As Christoph Martin pointed out in 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912695#43
it doesn't seem right that the limits differ between architectures
and are determined by the build hosts.

In any case, apt-show-versions 0.22.9 worked around this by raising the
Storable limits inside the script. There's some indication in the bug
that the limits are still too low, so things may still change.

We should add a Breaks on the perl side at least temporarily to unbreak
partial upgrades where perl is upgraded but apt-show-versions isn't.
Cloning a separate bug about that.
-- 
Niko

Bug#873075: backuppc-xs must be rebuilt after perl-base upgrade from 5.26 ---> 5.28

[sixerjman]

Recent testing updates installed perl-base 5.28 which breaks the unofficial
backuppc-xs.deb
on https://github.com/backuppc/backuppc/wiki/Build-Your-Own-Packages. The
solution
is to uninstall backuppc-xs, install the perl updates, then build a new
backuppc-xs.deb
using the instructions on the page.

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Holger Levsen]

On Fri, Nov 09, 2018 at 07:56:27PM +0100, Michael Biebl wrote:
> Thanks!
> Looks like this did indeed trigger a failure:
> https://tests.reproducible-builds.org/debian/dbdtxt/unstable/amd64/systemd_239-11.diffoscope.txt.gz
> 
> I do see the expected RUNPATH related diffs like e.g. in:
> 
> > │ │ │ ├── ./usr/lib/systemd/tests/test-hexdecoct
> ...
> > │ │ │ │ │0x0878 48415245 44002f6c 69622f73 79737465 HARED./lib/syste
> > │ │ │ │ │ -  0x0888 6d640068 61726564 00md.hared.
> > │ │ │ │ │ +  0x0888 6d640068 61726564 3a244f52 4947494e md.hared:$ORIGIN
> > │ │ │ │ │ +  0x0898 2f2e2e2f 2e2e2f2e 2e2f2e2e 2f6c6962 /../../../../lib
> > │ │ │ │ │ +  0x08a8 2f783836 5f36342d 6c696e75 782d676e /x86_64-linux-gn
> > │ │ │ │ │ +  0x08b8 7500   
 
That's due to usrmerge? (and not rebuilding in a different path?)
There's no "usr/bin" in that diffoscope output anywhere?

> Now we just need an archive rebuild and a before and after to see which
> new failures we get because of merged-usr :-)

should be done in 3-4 weeks for amd64 and arm64, on buster and sid. i386
and armhf will follow 1-2 weeks later.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913348: Locale "i18n" has possibly a wrong value in LC_ADDRESS category

[bakhelit]

Package: locales
Version: 2.24-11

Locale "i18n" may have a bug in LC_ADDRESS category as it has the value:

"/
/
/
/
"

that gives "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z %T%N%c%N"
instead of "%n%N%a%N%f%N%d%N%b%N%s %h %e %r%N%l%N%C-%z %T%N%S%N%c%N"
which I found in ISO/IEC TR 14652:2002 at
"http://www.open-std.org/jtc1/sc22/wg20/docs/n972-14652ft.pdf;
(on page 55). Missing fields seems to be "%n%N", "%l%N" and "%S%N".

Probably this should be verified with the current version of the 
standard full text which I did not find easily available. But it seems 
logical that an address begins with "Person's name" ("%n%N") and 
contains also the "%l%N" and "%S%N" fields.


Also the "locales" package from Debian unstable (version 2.27-8) has the 
same and possibly wrong value "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z 
%T%N%c%N" in the LC_ADDRESS category in the 
"/usr/share/i18n/locales/i18n" file.


Anyway I am not sure if any software on my Debian systems actually uses 
the LC_ADDRESS category, so I probably cannot test what problems this 
causes (if any). I just noticed this problem by accident when fighting 
an uphill battle with Mozilla Thunderbird about formating dates and 
times using a clear ISO way instead of crazy ambiguous formats in 
various locales (e.g. en_US or cs_CZ etc.). Well maybe when the Borg 
assimilate us we will finally be able to agree on doing basic things in 
one standard and most efficient way:D. Until then lets enjoy arguing 
about miles vs kilometers, AM/PM vs 24H, date formats, timezones, 
languages and other nonsense:).


Regards,
Bakhelit

Bug#906643: Bug#911832: Bug#906643: transition: php7.3

[Ondřej Surý]

Well, it’s either making the package binNMUable (using generic php-fpm test 
dependency) or recording the exact dependencies (using php7.3-fpm) or 
dynamically generating debian/tests/control like I do for php-defaults (which 
requires much more complex system).

But somehow for this simple package I would just prefer to just bite the bullet 
once in a while, do binNMU and then suffer it through… My experience tells me 
that “the simpler the better” even if it’s not perfect. Perfect but complex 
tend to break in more mysterious way...

If you can come up with something smarter, then I am sure the maintainer of the 
package would be all ears.

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 9 Nov 2018, at 19:33, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
> On 09-11-18 18:39, Ondřej Surý wrote:
>> The versioned depends is needed only for autopkgtests and not for the 
>> package itself. So, I think the dependency is useless there.
> 
> I misunderstood you then. Still, if a test case of a package requires a
> different specific (minimum) version of some other package than the
> package itself, the debian/tests/control file could (and in my opinion
> should) document that. How could our migration software add the right
> triggers otherwise?
> 
> Paul
> 
>> 
>> Ondrej
>> --
>> Ondřej Surý 
>> 
>>> On 9 Nov 2018, at 10:37, Paul Gevers  wrote:
>>> 
>>> Hi,
>>> 
>>> Hmm, I should read my backlog before replying.
>>> 
 On 08-11-18 22:53, Ondřej Surý wrote:
 But php-defaults and rss-bridge needs to go together.
>>> 
>>> That is ok, but where is this coded in the dependencies?
>>> 
 I thought that runtime detection of default PHP version in autopkgtest 
 would be overkill, so the socket path is hardcoded at the build-time.
>>> 
>>> I don't consider runtime detection an issue here. The issue is that the
>>> dependency system isn't notified of the relation AFAICT. Options I see
>>> are that either rss-bridge needs to tell which version of php it needs,
>>> or php-defaults needs to add a versioned breaks on rss-bridge.
>>> 
>>> Paul
>>> 
>> 
> 

Bug#913347: perl: $^X is empty in 5.28 when /proc is not mounted

[Niko Tyni]

Package: perl
Version: 5.28.0-3
Severity: normal
Tags: upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition

As reported by Holger Levsen, after upgrading perl to 5.28 the munin
package started to FTBFS when /proc is not mounted.

The underlying reason is that $^X is now empty in those circumstances.

This bisects to v5.27.5-43-gfca5fb9612:

  
https://perl5.git.perl.org/perl.git/commitdiff/fca5fb9612a125f48173bedf2c079778d7bc54dd

which was apparently supposed to be a non-op, but missed the fact that
the branches used to fall through to the fallback case when the result
was otherwise empty.

This should ideally be fixed upstream and backported to our 5.28 packages.
-- 
Niko Tyni   nt...@debian.org

Bug#913300: gmrender-resurrect: fails to autobuild because of libupnp transition

[Tobias Frost]

Am 9. November 2018 14:07:51 GMT+02:00 schrieb "Uwe Kleine-König" 
:
>Hello,
>
>On Fri, Nov 09, 2018 at 11:20:28AM +0100, Uwe Kleine-König wrote:
>> Source: gmrender-resurrect
>> Version: 0.0.7~git20180618.d0f46f5-2
>> Severity: serious
>> Justification: broken build depends
>> 
>> pupnp-1.8 provides since its last upload libupnp-dev but not
>> libupnp1.8-dev any more. This makes the binnmu that is part of the
>> libupnp transition fail to complete with BD-Uninstallable.
>
>I intend to upload an NMU for gmrender-resurrect with the following
>diff
>compared to 0.0.7~git20180618.d0f46f5-2:
>
>diff -Nru gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/changelog
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/changelog
>---
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/changelog  2018-10-19
>22:16:46.0 +0200
>+++
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/changelog  2018-11-09
>11:28:41.0 +0100
>@@ -1,3 +1,11 @@
>+gmrender-resurrect (0.0.7~git20180618.d0f46f5-2.1) unstable;
>urgency=medium
>+
>+  * Non-maintainer upload.
>+  * Set B-D back to libupnp-dev given that pupnp-1.8 now provides this
>package
>+but not libupnp1.8-dev and more. (Closes: #913300)
>+
>+ -- Uwe Kleine-König   Fri, 09 Nov 2018 11:28:41
>+0100
>+
>gmrender-resurrect (0.0.7~git20180618.d0f46f5-2) unstable;
>urgency=medium
> 
>* Fix "FTBFS against upnp 1.8", thanks to Uwe Klein-König for the
>patch.
>diff -Nru gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/control
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/control
>---
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/control2018-10-19
>21:31:52.0 +0200
>+++
>gmrender-resurrect-0.0.7~git20180618.d0f46f5/debian/control2018-11-09
>11:10:15.0 +0100
>@@ -7,7 +7,7 @@
>debhelper (>= 11),
>libgstreamer1.0-dev,
>libtool,
>-   libupnp1.8-dev
>+   libupnp-dev
> Rules-Requires-Root: no
> Standards-Version: 4.2.1
> Homepage: https://github.com/hzeller/gmrender-resurrect
>
>Once I found out what I have to do exactly I will upload this to
>delayed/5. Note I also send a merge request on salsa for this change.
>
>Best regards
>Uwe

Go ahead with the NMU ( you can also do a teamupload, as the package is in the 
Debian group of salsa... At least I think it is, but I can't check due to weak 
internet here))

Bug#901473: [Qa-jenkins-dev] Bug#901473: jenkins.debian.org: Vary merged-usr in reproducibility testing?

[Michael Biebl]

Am 09.11.18 um 15:12 schrieb Holger Levsen:
> On Fri, Nov 09, 2018 at 03:09:01PM +0100, Michael Biebl wrote:
>> Another test case should be src:systemd
>> When built in a merged-usr environment, meson will embed a wrong RUNPATH
>> into the test-binaries.
>> This should show up in the diffoscope output.
> 
> triggered as well. 

Thanks!
Looks like this did indeed trigger a failure:
https://tests.reproducible-builds.org/debian/dbdtxt/unstable/amd64/systemd_239-11.diffoscope.txt.gz

I do see the expected RUNPATH related diffs like e.g. in:

> │ │ │ ├── ./usr/lib/systemd/tests/test-hexdecoct
...
> │ │ │ │ │0x0878 48415245 44002f6c 69622f73 79737465 HARED./lib/syste
> │ │ │ │ │ -  0x0888 6d640068 61726564 00md.hared.
> │ │ │ │ │ +  0x0888 6d640068 61726564 3a244f52 4947494e md.hared:$ORIGIN
> │ │ │ │ │ +  0x0898 2f2e2e2f 2e2e2f2e 2e2f2e2e 2f6c6962 /../../../../lib
> │ │ │ │ │ +  0x08a8 2f783836 5f36342d 6c696e75 782d676e /x86_64-linux-gn
> │ │ │ │ │ +  0x08b8 7500   


Now we just need an archive rebuild and a before and after to see which
new failures we get because of merged-usr :-)

Michael



-- 
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#904302: Call for vote on disallowing the use dpkg's vendor series in the archive

[Niko Tyni]

On Mon, Nov 05, 2018 at 07:44:21PM +0100, Tollef Fog Heen wrote:
 
> A: Approve resolution, disallowing the use of dpkg's vendor series
> F: Further Discussion

I vote: A > F

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature