Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Johannes Schauer]

Hi,

Quoting Michael Biebl (2020-02-05 19:16:03)
> Am 05.02.20 um 18:15 schrieb Michael Biebl:
> > Am 05.02.20 um 13:28 schrieb Michael Biebl:
> >> Am 05.02.20 um 13:22 schrieb Michael Biebl:
> >>> Am 05.02.20 um 10:47 schrieb Andrey Rahmatullin:
>  Attached.
> >>>
> >>>
>  Running create action for entry a /var/log/journal
>  Detected unsafe path transition /var/log → /var/log/journal during 
>  canonicalization of /var/log/journal.
>  Running create action for entry a /var/log/journal
> >>>
> >>> It appears this problem happens, if / is not owned by root:root and
> >>> doesn't have 755. Since you said that all your files/directories were
> >>> owned by sbuild:sbuild, it is likely that those messed up permissions
> >>> tripped up systemd-tmpfiles.
> >>
> >> https://github.com/systemd/systemd/issues/11282
> > 
> > Sorry, should have read the bug report and your error message more
> > closely. It's obviously /var/log (and not /) which has the wrong
> > permissions. Otherwise the error message would have been different.
> > 
> > The reason why systemd-tmpfiles is complaining here, is that an
> > unprivileged user (sbuild) has access over subdirectories with higher
> > privileges and can fiddle with them (making it susceptible to a variety
> > of symlink attacks)
> > 
> > Now, the question: How should systemd postinst behave in this case?
> > Personally, I think throwing an error and letting the admin fix the
> > situation is probably not the worst solution.
> > Automatically fixing up the permissions in postinst is icky and I'd
> > rather not do that.
> > Simply ignore the error? Not sure, doesn't sound compelling either.
> > 
> > WDYT?
> > 
> > I have to add, that I just installed sbuild and created a sid chroot
> > which did not have those permissions for /var/log.
> > Maybe this was a bug in older versions of sbuild.
> > 
> 
> Johannes, could you chime in here?
> Do you have some insight why /var/log might have these permissions?

Unfortunately, I have never heard of a problem where directories in the chroot
were owned by sbuild:sbuild instead of root:root. If you can reproduce the
issue, please file a bug against sbuild.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950768: cluster3: missing Build-Depends: dh-python

[Andreas Tille]

Hi Andreas,

thanks for the bug report and all your QA work.  It is really
appreciated.

On Thu, Feb 06, 2020 at 02:31:12AM +0100, Andreas Beckmann wrote:
> Furthermore, cluster3 is in non-free and not whitelisted for
> autobuilding, so it needs source+binary uploads.  You should
> investigate whether it is possible to enable autobuilding [1]
> for that package s.t. this gets easier in the future.

Besides that the bug you reported will be fixed probably soon one remark
about this.  There is an old discussion without upstream how to free
cluster3 in general.  Only the GUI is non-free and we might consider
just droping this.  Unfortunately the discussion is a bit stalled but
probably should be revived now.  So my motivation to change anything
on the availablility for other architectures and get autobuilding done
is limited.

Thanks again
Andreas.

-- 
http://fam-tille.de

Bug#950776: "Took 213503982334601d 7h 0min 15s" due to typo bug inftparchive/apt-ftparchive.cc

[Trent W. Buck]

Package: apt-utils
Version: 1.8.2
Severity: minor
File: /usr/bin/apt-ftparchive
Tags: patch

I'm pretty sure this is a simple typo:

diff --git a/ftparchive/apt-ftparchive.cc b/ftparchive/apt-ftparchive.cc
index 077701c..51d492c 100644
--- a/ftparchive/apt-ftparchive.cc
+++ b/ftparchive/apt-ftparchive.cc
@@ -973,7 +973,7 @@ static bool Generate(CommandLine )
struct timeval NewTime = GetTimevalFromSteadyClock();
std::chrono::duration Delta =
   std::chrono::seconds(NewTime.tv_sec - StartTime.tv_sec) +
-  std::chrono::microseconds(NewTime.tv_sec - StartTime.tv_usec);
+  std::chrono::microseconds(NewTime.tv_usec - StartTime.tv_usec);
c1out << "Done. " << SizeToStr(Stats.Bytes) << "B in " << Stats.Packages
  << " archives. Took " << TimeToStr(llround(Delta.count())) << 
endl;

Without that patch, "apt-ftparchive generate /dev/null" often returns a very 
large "Took Ad Bh Cmin Ds" instead of "Took 0s".
With this patch, I seem to get "Took 0s" consistently.

AFAICT this landed in

79b61ae 2018-05-26 17:36 +0200 DKa ∙ Use a steady clock source for progress 
reporting

and it still present in git master (1.9.9).

PS: I just noticed my patch only fixed ONE instance of this code, but it's 
copy-pasted into several places, so all of them need fixing.

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

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

Versions of packages apt-utils depends on:
ii  apt 1.8.2
ii  libapt-inst2.0  1.8.2
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.29-9
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  9.2.1-23

apt-utils recommends no packages.

apt-utils suggests no packages.

-- no debconf information

Bug#950777: FTBFS on s390x (and others)

[Christian Ehrhardt]

Package: memcached
Version: 1.5.22-1

FTFBS on s390x.
I have seen the same in Ubuntu and filed/discussed this issue [1]
I have also filed a salsa MR [2] but it seems the MR was missed when
uploading 1.5.22-1 recently (I assume we raced each other working on this).

>From the logs on the buildds it seems my fix also fixes the sparc, powerpc,
hppa, ppc64 build issues that you have right now.

[1]:
https://github.com/memcached/memcached/commit/0ffde456cb21a7a03ee263f026edd565bb0f2123
[2]: https://salsa.debian.org/lamby/pkg-memcached/merge_requests/1

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#950775: RFP: boringtun -- userspace WireGuard implementation in Rust

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-rust-maintain...@lists.alioth.debian.org

   Package name: boringtun
Version: 0.2.0
Upstream Author: Cloudflare, Inc.
License: BSD-3-Clause
URL: https://github.com/cloudflare/boringtun
Description: userspace WireGuard implementation in Rust



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

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Steven Robbins]

On Thursday, February 6, 2020 12:51:23 A.M. CST YunQiang Su wrote:
> Steven Robbins  于2020年2月6日周四 下午1:23写道：
> 
> > On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su  wrote:
> > > Package: src:gmp
> > > Version: 6.2.0+dfsg-3
> > > 
> > > Since binutils/gcc meet some problem due to 2GB/3GB memory limitation
> > > on 32bit system.
> > 
> > Since GMP has built on all architectures, so I don't understand what
> > problem you are trying to solve.   Please enlighten me?
> 
> The 32bit system has 2GiB/3GiB virtual memory space limitation.
> When a big object file need to compile/link, the ld/gcc/cc1 may need lots of
> memory, which may be more than 2GiB/3GiB.

I understand that.  I know that some packages have trouble to build.  But gmp 
is not one of them -- it has already built on all architectures.  So I don't 
understand why gmp needs a patch.

-Steve


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

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[YunQiang Su]

Steven Robbins  于2020年2月6日周四 下午3:05写道：
>
> On Thursday, February 6, 2020 12:51:23 A.M. CST YunQiang Su wrote:
> > Steven Robbins  于2020年2月6日周四 下午1:23写道：
> >
> > > On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su  wrote:
> > > > Package: src:gmp
> > > > Version: 6.2.0+dfsg-3
> > > >
> > > > Since binutils/gcc meet some problem due to 2GB/3GB memory limitation
> > > > on 32bit system.
> > >
> > > Since GMP has built on all architectures, so I don't understand what
> > > problem you are trying to solve.   Please enlighten me?
> >
> > The 32bit system has 2GiB/3GiB virtual memory space limitation.
> > When a big object file need to compile/link, the ld/gcc/cc1 may need lots of
> > memory, which may be more than 2GiB/3GiB.
>
> I understand that.  I know that some packages have trouble to build.  But gmp
> is not one of them -- it has already built on all architectures.  So I don't
> understand why gmp needs a patch.

Because gcc builddeps it.

>
> -Steve



-- 
YunQiang Su

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[YunQiang Su]

Steven Robbins  于2020年2月6日周四 下午1:23写道：
>
> On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su  wrote:
> > Package: src:gmp
> > Version: 6.2.0+dfsg-3
> >
> > Since binutils/gcc meet some problem due to 2GB/3GB memory limitation
> > on 32bit system.
>
> Since GMP has built on all architectures, so I don't understand what problem
> you are trying to solve.   Please enlighten me?

The 32bit system has 2GiB/3GiB virtual memory space limitation.
When a big object file need to compile/link, the ld/gcc/cc1 may need lots of
memory, which may be more than 2GiB/3GiB.

So, we need a toolchain which in fact is running on 64bit env,
while output 32bit object by default.
That's what multilib can help us.

>
> Thanks,
> -Steve
>


-- 
YunQiang Su

Bug#950092: Build & test fail both

[Xavier]

Hi,

build & test fail for node-base64url. At least this has to be fixed:

--- a/debian/patches/2001_shared_types.patch
+++ b/debian/patches/2001_shared_types.patch
@@ -13,7 +13,7 @@ This patch header follows DEP-3:
http://dep.debian.net/deps/dep3/
 +"target": "es5",
 +"types": ["node"],
 +"typeRoots": [
-+  "/usr/lib/nodejs/@types"
++  "/usr/share/nodejs/@types"
 +]
},
"files": [

Bug#922420: got an unexpected keyword argument 'bg'

[Ben Finney]

Control: summary -1 This may be fixed already, need submitter to re-test.

Howdy Enrico,

On 15-Feb-2019, Enrico Zini wrote:

> It looks like --background has been added to the command line parser,
> but not to the function arguments to which the command line parser
> result is sent.

The code changes from version “1.2” → “1.4” includes a bunch of
changes related to the ‘--background’ option. The change log
unfortunately does not describe what behaviour change this is meant to
have.

So maybe, though upstream has not described any change to this effect,
the bug has been fixed? Can you try again with version “1.5-1”, now in
Debian?

-- 
 \ “No wonder I'm all confused; one of my parents was a woman, the |
  `\ other was a man.” —Ashleigh Brilliant |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature

Bug#950774: opensubdiv FTCBFS: stringify missing

[Helmut Grohne]

Source: opensubdiv
Version: 3.4.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

opensubdiv fails to cross build from source, because the build misses a
stringify tool. This tool is built during a native build and should be
provided for cross builds. It is installed into the opensubdiv-tools
package, so all we need to do here is pass the tool into a cross build.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru opensubdiv-3.4.0/debian/changelog 
opensubdiv-3.4.0/debian/changelog
--- opensubdiv-3.4.0/debian/changelog   2020-01-14 01:02:39.0 +0100
+++ opensubdiv-3.4.0/debian/changelog   2020-02-06 06:03:50.0 +0100
@@ -1,3 +1,10 @@
+opensubdiv (3.4.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Supply stringify to cross build. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 06 Feb 2020 06:03:50 +0100
+
 opensubdiv (3.4.0-6) unstable; urgency=medium
 
   * Upload to unstable
diff --minimal -Nru opensubdiv-3.4.0/debian/control 
opensubdiv-3.4.0/debian/control
--- opensubdiv-3.4.0/debian/control 2020-01-09 20:52:52.0 +0100
+++ opensubdiv-3.4.0/debian/control 2020-02-06 06:03:49.0 +0100
@@ -15,6 +15,7 @@
  libxrandr-dev,
  libxxf86vm-dev,
  opencl-headers,
+ opensubdiv-tools ,
  zlib1g-dev
 Build-Depends-Indep:
  doxygen,
diff --minimal -Nru opensubdiv-3.4.0/debian/rules opensubdiv-3.4.0/debian/rules
--- opensubdiv-3.4.0/debian/rules   2020-01-09 11:47:11.0 +0100
+++ opensubdiv-3.4.0/debian/rules   2020-02-06 06:03:50.0 +0100
@@ -20,7 +20,8 @@
-DNO_EXAMPLES=ON \
-DNO_GLTESTS=ON \
-DNO_OPENCL=ON \
-   -DNO_TUTORIALS=ON
+   -DNO_TUTORIALS=ON \
+   $(if $(filter 
cross,$(DEB_BUILD_PROFILES)),-DSTRINGIFY_LOCATION=/usr/bin/stringify)
 
 override_dh_auto_install:
dh_auto_install \

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp

[Steven Robbins]

On Tue, 4 Feb 2020 09:23:34 +0100 Christoph Berg  wrote:

> Hi,
> 
> the new gmp version makes postgresql-pgmp crash on arm64:
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/
4173638/log.gz
> (linked from https://packages.qa.debian.org/g/gmp.html)

...etc.  Thanks, that's useful to know.  I don't know the postgresql-pgmp code 
at all.  Can you help me understand what the linked web pages are telling us?

Thanks,
-Steve


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

Bug#950773: buster-pu: package node-dot-prop/4.1.1-1+deb10u1

[Xavier Guimard]

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

Hi,

node-dot-prop is vulnerable to a prototype pollution. This upstream
patch fixes the problem.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 84868fc..f7509b9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-dot-prop (4.1.1-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Add fix for prototype pollution (Closes: CVE-2020-8116)
+
+ -- Xavier Guimard   Thu, 06 Feb 2020 06:33:11 +0100
+
 node-dot-prop (4.1.1-1) unstable; urgency=low
 
   * Initial release (Closes: #868441)
diff --git a/debian/patches/CVE-2020-8116.diff 
b/debian/patches/CVE-2020-8116.diff
new file mode 100644
index 000..b7d34f1
--- /dev/null
+++ b/debian/patches/CVE-2020-8116.diff
@@ -0,0 +1,90 @@
+Description: Prevent setting/getting some problematic path components
+ Fixes CVE-2020-8116
+Author: Sindre Sorhus 
+Origin: upstream, https://github.com/sindresorhus/dot-prop/commit/3039c8c0
+Bug: https://hackerone.com/reports/719856
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-02-06
+
+--- a/index.js
 b/index.js
+@@ -1,6 +1,14 @@
+ 'use strict';
+ const isObj = require('is-obj');
+ 
++const disallowedKeys = [
++  '__proto__',
++  'prototype',
++  'constructor'
++];
++
++const isValidPath = pathSegments => !pathSegments.some(segment => 
disallowedKeys.includes(segment));
++
+ function getPathSegments(path) {
+   const pathArr = path.split('.');
+   const parts = [];
+@@ -15,6 +23,9 @@
+ 
+   parts.push(p);
+   }
++  if (!isValidPath(parts)) {
++  return [];
++  }
+ 
+   return parts;
+ }
+@@ -26,6 +37,9 @@
+   }
+ 
+   const pathArr = getPathSegments(path);
++  if (pathArray.length === 0) {
++  return;
++  }
+ 
+   for (let i = 0; i < pathArr.length; i++) {
+   if (!Object.prototype.propertyIsEnumerable.call(obj, 
pathArr[i])) {
+@@ -57,6 +71,9 @@
+   }
+ 
+   const pathArr = getPathSegments(path);
++  if (pathArray.length === 0) {
++  return;
++  }
+ 
+   for (let i = 0; i < pathArr.length; i++) {
+   const p = pathArr[i];
+@@ -79,6 +96,9 @@
+   }
+ 
+   const pathArr = getPathSegments(path);
++  if (pathArray.length === 0) {
++return;
++}
+ 
+   for (let i = 0; i < pathArr.length; i++) {
+   const p = pathArr[i];
+--- a/readme.md
 b/readme.md
+@@ -79,6 +79,8 @@
+ 
+ Use `\\.` if you have a `.` in the key.
+ 
++The following path components are invalid and results in `undefined` being 
returned: `__proto__`, `prototype`, `constructor`.
++
+  value
+ 
+ Type: `any`
+--- a/test.js
 b/test.js
+@@ -193,3 +193,10 @@
+   t.is(m.has({'foo.baz': {bar: true}}, 'foo\\.baz.bar'), true);
+   t.is(m.has({'fo.ob.az': {bar: true}}, 'fo\\.ob\\.az.bar'), true);
+ });
++
++test('prevent setting/getting `__proto__`', t => {
++  dotProp.set({}, '__proto__.unicorn', 'x');
++  t.not({}.unicorn, 'x'); // eslint-disable-line 
no-use-extend-native/no-use-extend-native
++
++  t.is(dotProp.get({}, '__proto__'), undefined);
++});
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..3100f1e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2020-8116.diff

Bug#950645: src:gmp, add lib64 for i386 x32 mipsel etc

[Steven Robbins]

On Tue, 4 Feb 2020 21:20:59 +0800 YunQiang Su  wrote:
> Package: src:gmp
> Version: 6.2.0+dfsg-3
> 
> Since binutils/gcc meet some problem due to 2GB/3GB memory limitation
> on 32bit system.

Since GMP has built on all architectures, so I don't understand what problem 
you are trying to solve.   Please enlighten me?

Thanks,
-Steve



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

Bug#950402: pinot ftbfs with libexiv2-27

[peter green]

tags 950402 +patch
thanks

This build failure is fixed by upstream commit 
faaa552de9ec099184d131c08b76ae0b1ce4f5ec , I adapted it to apply to the debian 
package and was able to sucessfully build the patched package in a raspbian 
bullseye-staging environment.

I have uploaded the fixed package to raspbian, a debdiff should appear soon at 
https://debdiffs.raspbian.org/main/p/pinot No intent to NMU in debian.

Bug#950743: satpy: autopkgtest failures

[Sebastiaan Couwenberg]

On 2/5/20 10:02 PM, Antonio Valentino wrote:
> indeed the problem is related to xarray, but IMHO the problem is in the
> latest version of the xarray package which seems to be broken.
> The xarray.core subpackage (wihic is also used in xarray/__init__.py)
> seems to be totally missing.
> 
> I'm going to ressign to python-xarray.

Sounds good, thanks for looking into this.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#950755: zookeeper: Please make another source-only upload to allow testing migration

[tony mancill]

On Wed, Feb 05, 2020 at 03:31:28PM -0500, Boyuan Yang wrote:
> Source: zookeeper
> Version: 3.4.13-4
> Severity: important
> X-Debbugs-CC: ebo...@apache.org tmanc...@debian.org
> 
> Dear zookeeper maintainers,
> 
> The latest upload of package zookeeper introduced the new binary package
> (python3-zookeeper) thus it was not a source-only upload. Please make another
> source-only upload at your convenience to ensure that the python3 migration is
> reflected in Testing.

Uploaded.  Thank you for the reminder.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Felipe Sateler]

On Mon, Feb 3, 2020 at 3:50 PM Felipe Sateler  wrote:

>
>
> On Sun, Feb 2, 2020, 17:04 Zbigniew Jędrzejewski-Szmek 
> wrote:
>
>> On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
>> > On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl  wrote:
>> >
>> > > Hi Felipe
>> > >
>> > > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
>> > > >
>> > > >
>> > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl > > > > > wrote:
>> > > >
>> > > > Am 28.01.20 um 17:27 schrieb Ansgar:
>> > > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
>> > > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
>> > > > >>> I tried linking systemd-{sysusers,tmpfiles} statically
>> against
>> > > > >>> systemd's private library earlier this month.  It increases
>> the
>> > > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2
>> MB of
>> > > > >>> systemd that is just one percent).
>> > > > >>
>> > > > >> Is that 100K per binary?
>> > > > >
>> > > > > I checked my notes at it was 100 kB per binary: they are 212
>> kB
>> > > larger
>> > > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested
>> with
>> > > > > systemd 243-8.
>> > > > >
>> > > > > It might be possible to make it a bit smaller if one was to
>> somehow
>> > > > > link libsystemd0 for functions available there
>> (libsystemd-shared
>> > > > > currently duplicates those).
>> > > >
>> > > >
>> > > > That is not possible. There is global state that is not to be
>> shared.
>> > > > See
>> https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
>> > >
>> > > What's your thought on how to solve this libsystemd-shared issue
>> should
>> > > we consider splitting out systemd-{sysusers,tmpfiles}
>> > >
>> > > - link statically (and carry a downstream patch for eternity)
>> > > - move libsystemd-shared to systemd-utils and risk the breakage that
>> can
>> > > result from a partial/aborted upgrade
>> > > - copy, instead of move, the binaries + libsystemd-shared and make the
>> > > resulting systemd-utils package Conflict with systemd (instead of
>> having
>> > > systemd depend on systemd-utils)
>> > > - something else?
>> > >
>> >
>> > I tried linking statically the "can run without systemd-pid1 tools" with
>> > the attached patch.
>> >
>> > Disk usage appears to increase by about 400 kb:
>> > % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
>> >
>> >  Installed-Size: 13908
>> > % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
>> >  Installed-Size: 14319
>> >
>> > Maybe upstream can be persuaded to merge something like this?
>> >
>> > --
>> >
>> > Saludos,
>> > Felipe Sateler
>>
>> > diff --git a/meson.build b/meson.build
>> > index b8dff8cd94..39cef6b301 100644
>> > --- a/meson.build
>> > +++ b/meson.build
>> > @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py =
>> find_program('tools/make-autosuspend-rules.py')
>> >
>> >  
>> >
>> > +
>> > +libutil = static_library(
>> > +'util',
>> > +[
>> > +'src/shared/acl-util.c',
>> > +'src/shared/enable-mempool.c',
>> > +'src/shared/id128-print.c',
>> > +'src/shared/pager.c',
>> > +'src/shared/path-lookup.c',
>> > +'src/shared/pretty-print.c',
>> > +'src/shared/spawn-ask-password-agent.c',
>> > +'src/shared/spawn-polkit-agent.c',
>> > +'src/shared/specifier.c',
>> > +'src/shared/sysctl-util.c',
>> > +'src/shared/sysctl-util.h',
>> > +'src/shared/tmpfile-util-label.c',
>> > +'src/shared/uid-range.c',
>> > +'src/shared/verbs.c',
>> > +] + id128_sources,
>> > +link_with: [libbasic, libsystemd_static],
>> > +include_directories: includes
>> > +)
>>
>> Is creating a separate static library actually necessary?  What would
>> the results be if those binaries were linked to the static version of
>> libshared that we already provide support for? I hope the compiler
>> would be able to drop any unused objects and achieve the same size,
>> without having to maintain yet another list of files.
>>
>
> I'd have to recheck, but that was my first idea and didn't pan out (at
> least with the flags we use for the debian package).
>

It appears I messed up earlier. Indeed using libshared_static (plus
libbasic and libsystemd_static) does the job as well.


-- 

Saludos,
Felipe Sateler

Bug#950172: gpscorrelate ftbfs with libexiv2-27

[peter green]

tags 950172 +patch
thanks

This build failure was a simple case of a missing #include "exiv2/error.hpp" , 
I fixed it in raspbian, a debdiff should appear soon at 
https://debdiffs.raspbian.org/main/g/gpscorrelate no intent to NMU in debian.

Bug#949440:

[Lovejan Janlove]

Rt

Bug#950310: nomacs ftbfs with libexiv2-27

[peter green]

tags 950310 +patch
thanks

This build failure is caused by missing "#include " in a couple of 
files. I would guess that in the past the header was pulled in indirectly.

I fixed this in raspbian, a debdiff should appear soon at 
https://debdiffs.raspbian.org/main/n/nomacs

Bug#950772: swupdate: FTBFS during separate arch/indep builds

[Andreas Beckmann]

Source: swupdate
Version: 2019.04+git20190903.c3ef374-1~exp1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

swupdate/experimental FTBFS during separate arch and indep builds (as
done on the buildds). But it builds fine if both are being done within
one build process.

binary-arch fails with:

   dh_installman -a
dh_installman: error: Cannot find (any matches for) "doc/build/man/swupdate.1" 
(tried in ., debian/tmp)

dh_installman: error: Aborting due to earlier error
make: *** [debian/rules:28: binary-arch] Error 25


binary-indep fails with:

   dh_auto_test -i
make -j3 test
make[1]: Entering directory '/build/swupdate-2019.04+git20190903.c3ef374'
  CC  test/test_crypt.o
make[2]: *** No rule to make target 'test/test_crypt.lnk', needed by 'tests'.  
Stop.
make[2]: *** Waiting for unfinished jobs
  CC  test/test_hash.o
make[1]: *** [Makefile:481: test] Error 2
make[1]: Leaving directory '/build/swupdate-2019.04+git20190903.c3ef374'
dh_auto_test: error: make -j3 test returned exit code 2
make: *** [debian/rules:28: build-indep] Error 25


Andreas


swupdate_2019.04+git20190903.c3ef374-1~exp1_arch.log.gz
Description: application/gzip


swupdate_2019.04+git20190903.c3ef374-1~exp1_indep.log.gz
Description: application/gzip

Bug#950771: mount: unexpected behaviour with "-f" option

[Simon]

Package: mount
Version: 2.33.1-0.1
Severity: minor

-- Additional info:
Using mount with '-f' will write to /run/mount/utab.
I think the '-n' option should be included implicitly since it is just a 
simulation?

When the root user does a mount with '-f' on a device previously mounted by 
another user granted with option 'user' specified in an entry of /etc/fstab,
an umount by the original user will cause a 'umount failed: Operation not 
permitted'

-- Comments/feeback/question:
Not sure how and if namespaces/context option can help alter user/group during 
a mount by root user.
Is there a way to restict which user/group can mount a device using 
user=XXX,group=xxx option in /etc/fstab since that is how /run/mount/utab is 
recorded?

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

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

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

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

Bug#950770: RM: swift-im -- RoQA; FTBFS, obsolete libraries, unmaintained, RC-buggy, not in testing

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal


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

RC-buggy, uses qt4 / openssl 1.0 / boost signals library that no longer
exists / not in testing.

I don't see any reverse depends or build-depends, please remove from unstable.

Regards,

Dimitri.

Bug#915805: NMU of swift-im

[Dimitri John Ledkov]

On Mon, 20 May 2019 15:34:34 +0200 Mattia Rizzolo  wrote:
> On Mon, May 20, 2019 at 03:32:26PM +0200, Dominik George wrote:
> > as I needed libswiften to build something, I went fixing the most important
> > bugs in the package so it at least builds again in current sid.
> >
> > Would you want me to upload these fixes as NMU, so the package is usable
> > until you get everything else solved?
>
> I'd suggest yes.
> I haven't heard from Kevin since the last time I wrote in this bug
> report, so I don't know how things are going, I suggest you go ahead
> with your NMU, and Kevin will merge your work back in then.
>

swift-im can no longer build against boost1.71 as signals library is removed.

swift-im is no longer part of testing.

I will request FTP masters to remove swift-im from Debian.

If and when you have updated swift-im that can use uptodate libraries
and dependencies it can be reintroduced in debian.

Regards,

Dimitri.

Bug#950769: pingus: FTBFS with new boost1.71 as signals library is removed

[Dimitri John Ledkov]

Package: pingus
Version: 0.7.6-5
Severity: serious
Tags: upstream
Justification: ftbfs

Dear Maintainer,

pingus ftbfs against the new boost1.71 as signals library is removed.

There has been a lot of development since 0.7.6 at
https://gitlab.com/pingus/pingus and it almost builds fine with only
minor issues.

Please either remove this package from Debian, or package a new
snapshot from gitlab (taking care to remove included copies of code
via git submodules).

Regards,

Dimitri.

Bug#950768: cluster3: missing Build-Depends: dh-python

[Andreas Beckmann]

Source: cluster3
Version: 1.59-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

cluster3 does FTBFS in a minimal buildd chroot:

 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
dh: error: unable to load addon python3: Can't locate 
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 14) line 
1.
BEGIN failed--compilation aborted at (eval 14) line 1.

make: *** [debian/rules:16: clean] Error 25

That should be a missing B-D: dh-python.

Furthermore, cluster3 is in non-free and not whitelisted for
autobuilding, so it needs source+binary uploads.  You should
investigate whether it is possible to enable autobuilding [1]
for that package s.t. this gets easier in the future.

[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd


Andreas


cluster3_1.59-1.log.gz
Description: application/gzip

Bug#947759: Configuration optimizations for the cloud variant

[Josh Triplett]

On Wed, Feb 05, 2020 at 04:27:23PM -0500, Noah Meyerhans wrote:
> On Tue, Feb 04, 2020 at 03:48:32PM -0800, Josh Triplett wrote:
> > I would suggest testing on a c5.large. t2 and t3 have shared CPUs, so
> > they have less consistent boot time. c5.large is about the same cost as
> > t3.large, but will have far more consistent performance.
> 
> Performance definitely seems to vary quite a bit.  Here are a few
> samples from c5.large instances in us-west-2:
> 
> 5.5 "generic" kernel:
> $ systemd-analyze 
> Startup finished in 4.323s (kernel) + 11.189s (userspace) = 15.513s 
> graphical.target reached after 9.865s in userspace
> 
> 5.5 "cloud" with optimizations:
> $ systemd-analyze 
> Startup finished in 7.273s (kernel) + 21.984s (userspace) = 29.258s 
> graphical.target reached after 19.811s in userspace
> 
> $ systemd-analyze 
> Startup finished in 4.319s (kernel) + 13.684s (userspace) = 18.003s 
> graphical.target reached after 12.321s in userspace
> 
> $ systemd-analyze 
> Startup finished in 3.327s (kernel) + 9.846s (userspace) = 13.174s 
> graphical.target reached after 8.831s in userspace
> 
> The optimized timings are all taken from the initial boot of newly
> launched instances.
> 
> It's certainly possible that things will look better with more data, but
> it's not clear yet that this change is an improvement in all cases.

That's strange. I've gotten very consistent boot-time results from c5
instances, and nowhere near those values. Certainly none of these
changes should introduce anywhere near that much variability in boot
time.

At the moment, I'm focused on the kernel time, not userspace time, since
the latter depends greatly on what you have installed. Would you mind
adding `initcall_debug` to the kernel command line, and providing
(compressed) dmesg logs for a few boots where you're observing that much
variability? That should make it relatively easy to diagnose where the
time is going.

(Also, you may want to make sure your kernel isn't configured to send
all its messages to the (virtual) serial port, which can slow down boot
time.)

> > > I'll post a WIP MR on salsa next.  Some cleanup is needed still.
> > 
> > Thank you for working on this!
> > 
> 
> The MR is here: https://salsa.debian.org/kernel-team/linux/merge_requests/206
> 
> I'm happy to share binary and/or source .debs and/or AMIs if you'd like
> to run some of your own tests.
> 
> > Have you confirmed that with the optimizations, you can boot without
> > needing an initramfs?
> 
> I've confirmed that the kernel can boot on c5 and t3 instances without
> an initramfs present at all.  However, the Xen backed EC2 instance types
> would also need to statically link (at least) ATA_PIIX, ATA_GENERIC, and
> XEN_BLKDEV_FRONTEND if we wanted to provide kernels that could be
> generally useful in EC2 without an initramfs.

For initramfs-less boot, I would suggest focusing on AWS's new
Nitro-based instances, rather than the Xen-based instances. I don't
think there's value in trying to build in enough drivers to boot without
an initramfs on older cloud hardware as well.

Bug#950171: libextractor ftbfs with libexiv2-27

[peter green]

tags 950171 +patch
tags 950171 +fixed-upstream
thanks


exiv2 started a transition and I scheduled binNMUs. However, your
package failed. Please investigate.


Upstream fixed this in commit 1ecee9a47717e36cb8a3925d011d1a6de11d631c

I applied that commit (minus the changes to the upstream changelog) to the 
debian package as a quilt patch and was able to get a succesfull build in 
raspbian bullseye-staging. A debdiff should appear soon at 
https://debdiffs.raspbian.org/main/libe/libextractor

Bug#950170: sorry, wrong bug number in changelog.

[Peter Green]

reopen 950172
close 950170 0.2.4-1.1
thanks

Sorry I copy/pasted the wrong bug number into the changelog.

Bug#950170: gimplensfun ftbfs with libexiv2-27

[peter green]

I think this is fixed 
byhttps://github.com/seebk/GIMP-Lensfun/commit/ca4511c1a4dd8edabe86e4a943861fda07b7e86c

Feel free to 0day NMU, I don't have much time right now.

I did a test build with that commit added as a quilt patch and it built 
successfully, so I went ahead with the 0-day NMU. Debdiff is attatched.

diff -Nru gimplensfun-0.2.4/debian/changelog gimplensfun-0.2.4/debian/changelog
--- gimplensfun-0.2.4/debian/changelog  2016-04-16 17:49:36.0 +
+++ gimplensfun-0.2.4/debian/changelog  2020-02-05 23:52:20.0 +
@@ -1,3 +1,11 @@
+gimplensfun (0.2.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch to add a missing #include and hence 
+fix build with new exiv2 (Closes: 950172).
+
+ -- Peter Michael Green   Wed, 05 Feb 2020 23:52:20 +
+
 gimplensfun (0.2.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gimplensfun-0.2.4/debian/patches/02-add-missing-header.patch 
gimplensfun-0.2.4/debian/patches/02-add-missing-header.patch
--- gimplensfun-0.2.4/debian/patches/02-add-missing-header.patch
1970-01-01 00:00:00.0 +
+++ gimplensfun-0.2.4/debian/patches/02-add-missing-header.patch
2020-02-05 23:51:42.0 +
@@ -0,0 +1,18 @@
+commit ca4511c1a4dd8edabe86e4a943861fda07b7e86c
+Author: Neil Mayhew 
+Date:   Fri Jul 5 13:37:39 2019 -0600
+
+Add missing header file
+
+diff --git a/src/gimplensfun.cpp b/src/gimplensfun.cpp
+index da2a94c..8e9e12e 100644
+--- a/src/gimplensfun.cpp
 b/src/gimplensfun.cpp
+@@ -31,6 +31,7 @@
+ #include 
+ #include 
+ 
++#include 
+ #include 
+ #include 
+ 
diff -Nru gimplensfun-0.2.4/debian/patches/series 
gimplensfun-0.2.4/debian/patches/series
--- gimplensfun-0.2.4/debian/patches/series 2015-12-26 19:45:21.0 
+
+++ gimplensfun-0.2.4/debian/patches/series 2020-02-05 23:51:59.0 
+
@@ -1 +1,2 @@
 01-debian-cflags-ldflags.patch
+02-add-missing-header.patch

Bug#950763: ITP: braillefont -- Prints a bitmapped version of a text using Unicode Braille symbols

[Judit Foglszinger]

Version : 0~20161007~14b2b1a


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

Bug#950763: ITP: braillefont -- Prints a bitmapped version of a text using Unicode Braille symbols

[Judit Foglszinger]

s/Version : git/Version : 0.0.20161007~14b2b1a/


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

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Adam D. Barratt]

On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
>  wrote:
> > Because this changes the versioning scheme from kernel releases
> > (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> > version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> > believe.
> 
> I had this doubt but 5.4.13-1 is the linux source version, and
> libbpf0 has the version of 0.0.5. And since there is no separate
> source for libbpf so will this not be  considered as a new package
> rather than a version change?

No. There is currently a libbpf0 binary package. After the source
package split, there will still be a libbpf0 binary package. The
version of that binary package cannot go backwards.

(The source package will indeed be NEW, but that's not the issue under
discussion here.)

Regards,

Adam

Bug#950767: postgresql-11-python3-multicorn: Underlinked when built with Python3.8 as default

[Stefano Rivera]

Package: postgresql-11-python3-multicorn
Version: 1.3.4-31-g9ff7875-2
Severity: normal
Tags: upstream patch
User: debian-pyt...@lists.debian.org
Usertags: python3.8

FYI: The multicorn.so PostgreSQL plugin will not be linked to libpython
when built under Python 3.8, without this patch:

https://github.com/Kozea/Multicorn/pull/242

https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
 says:

> To embed Python into an application, a new --embed option must be
> passed to python3-config --libs --embed to get -lpython3.8 (link the
> application to libpython). To support both 3.8 and older, try
> python3-config --libs --embed first and fallback to python3-config
> --libs (without --embed) if the previous command fails.

SR

Bug#950766: pgl-ddl-deploy FTBFS with PostgreSQL 12

[Adrian Bunk]

Source: pgl-ddl-deploy
Version: 1.5.1-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/pgl-ddl-deploy.html

...
 fakeroot debian/rules clean
pg_buildext checkcontrol
--- debian/control  2019-01-15 05:04:16.0 -1200
+++ debian/control.TAJCat   2020-01-30 11:57:39.029747995 -1200
@@ -8,9 +8,8 @@
 Vcs-Browser: https://github.com/enova/pgl_ddl_deploy
 Vcs-Git: https://github.com/enova/pgl_ddl_deploy.git
 
-Package: postgresql-11-pgl-ddl-deploy
+Package: postgresql-12-pgl-ddl-deploy
 Architecture: any
-Depends: postgresql-11, postgresql-11-pglogical, ${shlibs:Depends}, 
${misc:Depends}
+Depends: postgresql-12, postgresql-12-pglogical, ${shlibs:Depends}, 
${misc:Depends}
 Description: Transparent DDL replication for PostgreSQL
- Automated DDL deployment using PgLogical for PostgreSQL 11.
-
+ Automated DDL deployment using PgLogical for PostgreSQL 12.
Error: debian/control needs updating from debian/control.in. Run 'pg_buildext 
updatecontrol'.
If you are seeing this message in a buildd log, a sourceful upload is required.
make: *** [/usr/share/postgresql-common/pgxs_debian_control.mk:9: 
debian/control] Error 1

Bug#950765: buster-pu: package nvidia-settings-legacy-340xx/340.108-1~deb10u1

[Andreas Beckmann]

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

Hi,

I just realized that the 340.108 release of nvidia-settings contained
not only version number bumping (therefore I initially planned to not
update nvidia-settings-legacy-340xx along with
nvidia-graphics-drivers-legacy-340xx), but actual code changes: an
upstream fix for Xorg Xserver 1.20 (which is in buster) was backported
from 390.xx. Upstream changelog (in src:nvidia-graphics-drivers) only
mentioned that for nvidia-xconfig, but the same fix was applied upstream
to nvidia-settings.
I'm not aware of any bug reports regarding this issue, but rebuilding
the package from sid was easy ;-)

The package is already uploaded.
There is no need to rush this update to go along with the updated
driver packages sitting in buster-pu, nvidia-settings-legacy-340xx can
well wait for a subsequent point release.


Andreas
diff -Nru nvidia-settings-legacy-340xx-340.107/debian/changelog 
nvidia-settings-legacy-340xx-340.108/debian/changelog
--- nvidia-settings-legacy-340xx-340.107/debian/changelog   2019-02-06 
17:02:18.0 +0100
+++ nvidia-settings-legacy-340xx-340.108/debian/changelog   2020-02-05 
23:25:44.0 +0100
@@ -1,3 +1,18 @@
+nvidia-settings-legacy-340xx (340.108-1~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Wed, 05 Feb 2020 23:25:44 +0100
+
+nvidia-settings-legacy-340xx (340.108-1) unstable; urgency=medium
+
+  * New upstream release 340.108.
+- Fixed a bug that could prevent nvidia-xconfig from disabling the X
+  Composite extension on version 1.20 of the X.org X server.  (390.116-1)
+  * Bump Standards-Version to 4.5.0. No changes needed.
+
+ -- Andreas Beckmann   Wed, 05 Feb 2020 22:56:48 +0100
+
 nvidia-settings-legacy-340xx (340.107-2) unstable; urgency=medium
 
   * Synchronize packaging with nvidia-settings-legacy-390xx 390.87-1.
diff -Nru nvidia-settings-legacy-340xx-340.107/debian/control 
nvidia-settings-legacy-340xx-340.108/debian/control
--- nvidia-settings-legacy-340xx-340.107/debian/control 2019-02-06 
17:02:18.0 +0100
+++ nvidia-settings-legacy-340xx-340.108/debian/control 2020-02-05 
23:25:44.0 +0100
@@ -22,7 +22,7 @@
 Build-Conflicts:
  libxnvctrl-dev,
 Rules-Requires-Root: no
-Standards-Version: 4.3.0
+Standards-Version: 4.5.0
 Homepage: https://download.nvidia.com/XFree86/nvidia-settings/
 Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-settings
 Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-settings.git -b 
340xx/master
diff -Nru nvidia-settings-legacy-340xx-340.107/debian/copyright 
nvidia-settings-legacy-340xx-340.108/debian/copyright
--- nvidia-settings-legacy-340xx-340.107/debian/copyright   2019-02-06 
17:02:18.0 +0100
+++ nvidia-settings-legacy-340xx-340.108/debian/copyright   2020-02-05 
23:25:44.0 +0100
@@ -98,7 +98,7 @@
 Files: debian/*
 Copyright: © 2004-2010 Randall Donald 
© 2009-2010 Fathi Boudra 
-   © 2011-2018 Andreas Beckmann 
+   © 2011-2020 Andreas Beckmann 
© 2017  Luca Boccassi 
 License: GPL-2
 
diff -Nru nvidia-settings-legacy-340xx-340.107/doc/version.mk 
nvidia-settings-legacy-340xx-340.108/doc/version.mk
--- nvidia-settings-legacy-340xx-340.107/doc/version.mk 2018-05-25 
07:53:29.0 +0200
+++ nvidia-settings-legacy-340xx-340.108/doc/version.mk 2019-12-12 
00:31:04.0 +0100
@@ -1 +1 @@
-NVIDIA_VERSION = 340.107
+NVIDIA_VERSION = 340.108
diff -Nru nvidia-settings-legacy-340xx-340.107/samples/version.mk 
nvidia-settings-legacy-340xx-340.108/samples/version.mk
--- nvidia-settings-legacy-340xx-340.107/samples/version.mk 2018-05-25 
07:53:29.0 +0200
+++ nvidia-settings-legacy-340xx-340.108/samples/version.mk 2019-12-12 
00:31:04.0 +0100
@@ -1 +1 @@
-NVIDIA_VERSION = 340.107
+NVIDIA_VERSION = 340.108
diff -Nru nvidia-settings-legacy-340xx-340.107/src/XF86Config-parser/Generate.c 
nvidia-settings-legacy-340xx-340.108/src/XF86Config-parser/Generate.c
--- nvidia-settings-legacy-340xx-340.107/src/XF86Config-parser/Generate.c   
2018-05-25 07:53:29.0 +0200
+++ nvidia-settings-legacy-340xx-340.108/src/XF86Config-parser/Generate.c   
2019-12-12 00:31:05.0 +0100
@@ -1322,7 +1322,8 @@
int *isModular,
int *autoloadsGLX,
int *supportsExtensionSection,
-   int *xineramaPlusCompositeWorks)
+   int *xineramaPlusCompositeWorks,
+   const char **compositeExtensionName)
 {
 #define XSERVER_VERSION_FORMAT_1 "X Window System Version"
 #define XSERVER_VERSION_FORMAT_2 "X.Org X Server"
@@ -1412,6 +1413,18 @@
 } else {
 *xineramaPlusCompositeWorks = TRUE;
 }
+
+/*
+ * With X.Org xserver version 1.20, the name of the 

Bug#950764: pg-fact-loader FTBFS with PostgreSQL 12

[Adrian Bunk]

Source: pg-fact-loader
Version: 1.5.2-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pg-fact-loader.html

...
 fakeroot debian/rules clean
pg_buildext checkcontrol
--- debian/control  2018-11-29 04:36:36.0 -1200
+++ debian/control.NsdMOY   2021-02-28 19:18:35.619089892 -1200
@@ -7,9 +7,8 @@
 Homepage: https://github.com/enova/pg_fact_loader
 Vcs-Git: https://github.com/enova/pg_fact_loader.git
 
-Package: postgresql-11-pg-fact-loader
+Package: postgresql-12-pg-fact-loader
 Architecture: any
-Depends: postgresql-11, ${shlibs:Depends}, ${misc:Depends}
+Depends: postgresql-12, ${shlibs:Depends}, ${misc:Depends}
 Description: Build fact tables asynchronously with Postgres
- Use queue tables to build fact tables asynchronously for PostgreSQL 11.
-
+ Use queue tables to build fact tables asynchronously for PostgreSQL 12.
Error: debian/control needs updating from debian/control.in. Run 'pg_buildext 
updatecontrol'.
If you are seeing this message in a buildd log, a sourceful upload is required.
make: *** [/usr/share/postgresql-common/pgxs_debian_control.mk:9: 
debian/control] Error 1

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Sudip Mukherjee]

On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
 wrote:
>
> Because this changes the versioning scheme from kernel releases
> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> believe.

I had this doubt but 5.4.13-1 is the linux source version, and libbpf0 has the
version of 0.0.5. And since there is no separate source for libbpf so will this
not be  considered as a new package rather than a version change?


-- 
Regards
Sudip

Bug#950763: ITP: braillefont -- Prints a bitmapped version of a text using Unicode Braille symbols

[Judit Foglszinger]

Package: wnpp
Owner: Judit Foglszinger 
Severity: wishlist

* Package name: braillefont
  Version : git
  Upstream Author : Adam Borowski 
* URL : https://github.com/kilobyte/braillefont
* License : Public Domain (CC0)
  Programming Lang: C
  Description : Prints a bitmapped version of a text using Unicode Braille 
symbols

braillefont runs interactively on the console - one can enter a (short) text,
that will be converted into a bitmapped version
and printed using the Braille range of Unicode.

I consider the package to be useful, because it's fun to play around with it
and it can make nice mail signatures.
I use it. Not every day, considered the limited scope,
but from time to time, if I get bored.

For now, I plan to maintain it alone.  It's a very small package
needing nothing outside the standard C library,
so should be doable by one person.


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

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Christian Barcenas]

Because this changes the versioning scheme from kernel releases
(libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
believe.

CC'ing debian-devel for discussion/consensus, per Debian Policy Manual 5.6.12.

Christian

On Wed, Feb 5, 2020 at 12:57 PM Sudip Mukherjee
 wrote:
>
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "libbpf"
>
>  * Package name: libbpf
>Version : 0.0.6-1
>Upstream Author : NA
>  * URL : https://github.com/libbpf/libbpf
>  * License : LGPL-2.1
>  * Vcs : https://github.com/sudipm-mukherjee/libbpf
>Section : libs
>
> It builds those binary packages:
>
>   libbpf-dev - eBPF helper library (development files)
>   libbpf0 - eBPF helper library (shared library)
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/libbpf
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libb/libbpf/libbpf_0.0.6-1.dsc
>
> Changes since the last upload:
>
>* Package from github. (Closes: #948041)
>
> Note:
> I think this should be done after 
> https://salsa.debian.org/kernel-team/linux/merge_requests/207
> has been merged.
>
>
> --
> Regards
> Sudip
>

Bug#950751: SyntaxWarning: "is" with a literal. Did you mean "=="

[eamanu]

Package: wifite
Version: 2.5.0~git20191114-2

Hi,

I've just prepare a MR [1] to fix this issue.

Please consider apply it.


[1] https://salsa.debian.org/pkg-security-team/wifite/merge_requests/1

Cheers,
eamanu

Bug#922583: FTBFS against opencv 4.0.1 (exp)

[Gianfranco Costamagna]

control: tags -1 pending

ongoing the following as NMU

On Mon, 3 Feb 2020 18:13:07 +0100 Gianfranco Costamagna 
 wrote:
> control: tags -1 patch
> 
> Author: Gianfranco Costamagna 
> Last-Update: 2020-02-03
> 
> --- gst-plugins-bad1.0-1.16.2.orig/configure.ac
> +++ gst-plugins-bad1.0-1.16.2/configure.ac
> @@ -1845,7 +1845,7 @@ AG_GST_CHECK_FEATURE(OPENCV, [opencv plu
>HAVE_OPENCV="yes"
>  fi
>], [
> -PKG_CHECK_MODULES([OPENCV], [opencv4 >= 4.0.0 opencv4 < 4.2.0] , [
> +PKG_CHECK_MODULES([OPENCV], [opencv4 >= 4.0.0 opencv4 < 4.3.0] , [
>  AC_PROG_CXX
>  AC_LANG([C++])
>  OLD_CPPFLAGS=$CPPFLAGS
> 
> 
> this does the trick
> (inspired form upstream commit a2cfd93891376f74cc877e633aa70933b17200d9)
> 
> G.
> On Mon, 18 Feb 2019 06:36:30 + Mo Zhou  wrote:
> > Source: gst-plugins-bad1.0
> > Version: 1.14.4-1
> > Severity: important
> > 
> > Failed due to missing files
> 
> 
diff -Nru gst-plugins-bad1.0-1.16.2/debian/changelog 
gst-plugins-bad1.0-1.16.2/debian/changelog
--- gst-plugins-bad1.0-1.16.2/debian/changelog  2019-12-09 11:03:37.0 
+0100
+++ gst-plugins-bad1.0-1.16.2/debian/changelog  2020-02-05 22:46:23.0 
+0100
@@ -1,3 +1,10 @@
+gst-plugins-bad1.0 (1.16.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Upload patch to fix build with newer opencv (Closes: #922583)
+
+ -- Gianfranco Costamagna   Wed, 05 Feb 2020 
22:46:23 +0100
+
 gst-plugins-bad1.0 (1.16.2-2) unstable; urgency=medium
 
   * Source-only re-upload.
diff -Nru gst-plugins-bad1.0-1.16.2/debian/patches/opencv.patch 
gst-plugins-bad1.0-1.16.2/debian/patches/opencv.patch
--- gst-plugins-bad1.0-1.16.2/debian/patches/opencv.patch   1970-01-01 
01:00:00.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/patches/opencv.patch   2020-02-05 
22:46:10.0 +0100
@@ -0,0 +1,14 @@
+Author: Gianfranco Costamagna 
+Last-Update: 2020-02-03
+
+--- gst-plugins-bad1.0-1.16.2.orig/configure.ac
 gst-plugins-bad1.0-1.16.2/configure.ac
+@@ -1845,7 +1845,7 @@ AG_GST_CHECK_FEATURE(OPENCV, [opencv plu
+   HAVE_OPENCV="yes"
+ fi
+   ], [
+-PKG_CHECK_MODULES([OPENCV], [opencv4 >= 4.0.0 opencv4 < 4.2.0] , [
++PKG_CHECK_MODULES([OPENCV], [opencv4 >= 4.0.0 opencv4 < 4.3.0] , [
+ AC_PROG_CXX
+ AC_LANG([C++])
+ OLD_CPPFLAGS=$CPPFLAGS
diff -Nru gst-plugins-bad1.0-1.16.2/debian/patches/series 
gst-plugins-bad1.0-1.16.2/debian/patches/series
--- gst-plugins-bad1.0-1.16.2/debian/patches/series 2019-12-04 
14:32:00.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/patches/series 2020-02-05 
22:46:10.0 +0100
@@ -1,3 +1,4 @@
 01_fix-modplug-linking.patch
 02_opencv-data-path.patch
 03_default-soundfont.patch
+opencv.patch

Bug#947759: Configuration optimizations for the cloud variant

[Noah Meyerhans]

On Tue, Feb 04, 2020 at 03:48:32PM -0800, Josh Triplett wrote:
> I would suggest testing on a c5.large. t2 and t3 have shared CPUs, so
> they have less consistent boot time. c5.large is about the same cost as
> t3.large, but will have far more consistent performance.

Performance definitely seems to vary quite a bit.  Here are a few
samples from c5.large instances in us-west-2:

5.5 "generic" kernel:
$ systemd-analyze 
Startup finished in 4.323s (kernel) + 11.189s (userspace) = 15.513s 
graphical.target reached after 9.865s in userspace

5.5 "cloud" with optimizations:
$ systemd-analyze 
Startup finished in 7.273s (kernel) + 21.984s (userspace) = 29.258s 
graphical.target reached after 19.811s in userspace

$ systemd-analyze 
Startup finished in 4.319s (kernel) + 13.684s (userspace) = 18.003s 
graphical.target reached after 12.321s in userspace

$ systemd-analyze 
Startup finished in 3.327s (kernel) + 9.846s (userspace) = 13.174s 
graphical.target reached after 8.831s in userspace

The optimized timings are all taken from the initial boot of newly
launched instances.

It's certainly possible that things will look better with more data, but
it's not clear yet that this change is an improvement in all cases.

> > I'll post a WIP MR on salsa next.  Some cleanup is needed still.
> 
> Thank you for working on this!
> 

The MR is here: https://salsa.debian.org/kernel-team/linux/merge_requests/206

I'm happy to share binary and/or source .debs and/or AMIs if you'd like
to run some of your own tests.

> Have you confirmed that with the optimizations, you can boot without
> needing an initramfs?

I've confirmed that the kernel can boot on c5 and t3 instances without
an initramfs present at all.  However, the Xen backed EC2 instance types
would also need to statically link (at least) ATA_PIIX, ATA_GENERIC, and
XEN_BLKDEV_FRONTEND if we wanted to provide kernels that could be
generally useful in EC2 without an initramfs.

noah

Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces

[Andreas Beckmann]

Package: ksh,ksh93
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks
Control: found -1 2020.0.0-5
Control: found -1 93u+20120801-6

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install ksh
  # (1)
  apt-get install ksh93
  apt-get remove ksh93
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /etc/skel/.kshrc

(also happens with both packages swapped)

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

Since you obviously want the two packages to be co-installable,
* either move /etc/skel/.kshrc to a separate packages, and let both depend on it
* or let only one (ksh) ship it and the other (ksh93) depend on it.

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

1m14.7s DEBUG: Modified(user, group, mode, size, target): 
/var/lib/dpkg/info/ksh.list expected(root, root, - 100644, 1012, None) != 
found(root, root, - 100644, 995, None)
1m14.7s ERROR: FAIL: After purging files have disappeared:
  /etc/skel/.kshrc   owned by: ksh93

1m14.7s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/ksh.listnot owned


cheers,

Andreas


ksh=2020.0.0-5_ksh93=93u+20120801-6.gz
Description: application/gzip

Bug#932081: sogo: Unable to connect to a remote IMAP server.

[Gerald Turner]

FWIW, I rebuilt 4.1.1 sogo and sope packages from bullseye modified
slightly to link against OpenSSL instead of GnuTLS, installed on a
production buster system, success!

Thank you Adi Kriegisch for pointing this out.

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#950761: ipmitool: CVE-2020-5208

[Salvatore Bonaccorso]

Source: ipmitool
Version: 1.8.18-8
Severity: important
Tags: security upstream
Control: found -1 1.8.18-6
Control: found -1 1.8.18-3

Hi,

The following vulnerability was published for ipmitool.

CVE-2020-5208[0]:
| It's been found that multiple functions in ipmitool before 1.8.19
| neglect proper checking of the data received from a remote LAN party,
| which may lead to buffer overflows and potentially to remote code
| execution on the ipmitool side. This is especially dangerous if
| ipmitool is run as a privileged user. This problem is fixed in version
| 1.8.19.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-5208
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5208
[1] https://github.com/ipmitool/ipmitool/security/advisories/GHSA-g659-9qxw-p7cp
[2] 
https://github.com/ipmitool/ipmitool/commit/e824c23316ae50beb7f7488f2055ac65e8b341f2

Regards,
Salvatore

Bug#950743: satpy: autopkgtest failures

[Antonio Valentino]

Dear Bas,
indeed the problem is related to xarray, but IMHO the problem is in the
latest version of the xarray package which seems to be broken.
The xarray.core subpackage (wihic is also used in xarray/__init__.py)
seems to be totally missing.

I'm going to ressign to python-xarray.


kind regards
antonio

On Wed, 05 Feb 2020 17:19:38 +0100 Bas Couwenberg 
wrote:
> Source: satpy
> Version: 0.19.1-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
> 
> Dear Maintainer,
> 
> The update of python3-xarray breaks autopkgtest:
> 
>  === python3.8 ===
>  satpy (unittest.loader._FailedTest) ... ERROR
>  
>  ==
>  ERROR: satpy (unittest.loader._FailedTest)
>  --
>  ImportError: Failed to import test module: satpy
>  Traceback (most recent call last):
>File "/usr/lib/python3.8/unittest/loader.py", line 154, in 
> loadTestsFromName
>  module = __import__(module_name)
>File "/usr/lib/python3/dist-packages/satpy/__init__.py", line 53, in 
> 
>  from satpy.writers import available_writers  # noqa
>File "/usr/lib/python3/dist-packages/satpy/writers/__init__.py", line 29, 
> in 
>  import xarray as xr
>File "/usr/lib/python3/dist-packages/xarray/__init__.py", line 1, in 
> 
>  from . import testing, tutorial, ufuncs
>File "/usr/lib/python3/dist-packages/xarray/testing.py", line 7, in 
> 
>  from xarray.core import duck_array_ops, formatting
>  ModuleNotFoundError: No module named 'xarray.core'
>  
>  
>  --
>  Ran 1 test in 0.000s
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/4199620/log.gz
> 
> Kind Regards,
> 
> Bas
> 
> 

-- 
Antonio Valentino

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

Hi All,

On Fri, Jan 31, 2020 at 04:28:34PM +, Sudip Mukherjee wrote:
> On Fri, Jan 31, 2020 at 4:11 PM Ben Hutchings  wrote:
> >
> > On Wed, 2020-01-15 at 12:50 +, Sudip Mukherjee wrote:
> > > Hi Jonathan,
> > >

> 
> >
> > So on balance I support moving libbpf out to a separate source package.
> 
> Thanks Ben.
> 
> As discussed, I will raise a merge request on the kernel repo to
> remove libbpf building bits. And then use this bug to deliver the new
> source package.

https://salsa.debian.org/kernel-team/linux/merge_requests/207 has been
opened to remove libbpf from kernel.
#950760 is the RFS for the new upload which has been packaged from github.

--
Regards
Sudip

Bug#950731: FTBFS on ppc64el :

[Steve Robbins]

Thanks!   Do you know why only ppc64el fails?

On February 5, 2020 7:19:17 a.m. CST, "Frédéric Bonnard"  
wrote:
>Package: src:digikam
>Version: 4:6.4.0+dfsg-1
>Control: tags -1 ftbfs patch
>
>--
>
>Dear maintainer,
>latest 4:6.4.0+dfsg-1 fails to build on ppc64el here :
>https://buildd.debian.org/status/fetch.php?pkg=digikam=ppc64el=4%3A6.4.0%2Bdfsg-1=1580716901=0
>
>Opencv undefines vector, bool and pixel on purpose (
>https://en.wikipedia.org/wiki/AltiVec#Issues )
>
>I wrote a patch to fix this :
>https://salsa.debian.org/debian/digikam/merge_requests/1
>
>Regards,
>
>
>F.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#949187: transition: python3.8

[Rene Engelhard]

On Wed, Feb 05, 2020 at 01:26:31PM +, Simon McVittie wrote:
> On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote:
> > Thanks, yes, that prevents the install of the "old"
> > gobject-introspection with the new python3 from experimental.
> 
> Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That
> isn't actually what you need if you want to port to python3.8

Actually, no, I just wanted to prevent it FTBFSing when the default
changes and gobject-introspection wasn't yet rebuilt.

LibreOffice also only builds dor the default. (With a shitload of
hackery it is possible to build pyuno twice/thrice etc. but given
there*s a LO part of it this will not be coinstallable, defeating the
purpose.)

Regards,

Rene

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: libbpf
   Version : 0.0.6-1
   Upstream Author : NA
 * URL : https://github.com/libbpf/libbpf
 * License : LGPL-2.1
 * Vcs : https://github.com/sudipm-mukherjee/libbpf
   Section : libs

It builds those binary packages:

  libbpf-dev - eBPF helper library (development files)
  libbpf0 - eBPF helper library (shared library)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libb/libbpf/libbpf_0.0.6-1.dsc

Changes since the last upload:

   * Package from github. (Closes: #948041)

Note:
I think this should be done after 
https://salsa.debian.org/kernel-team/linux/merge_requests/207
has been merged.


-- 
Regards
Sudip

Bug#950759: hardened systemd configuration

[Antoine Beaupre]

Package: prometheus
Severity: wishlist

I'm working with the Puppet community to maintain a Prometheus Puppet
module that's available here:

https://github.com/voxpupuli/puppet-prometheus/

We recently introduced a new feature where the systemd unit file is
hardened. I think it would be a great addition to the Debian package
as well, considering that it seems to work for us. Here's the magic
incantation that was added:

NoNewPrivileges=true
ProtectHome=true
ProtectSystem=full
ProtectHostname=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
LockPersonality=true
RestrictRealtime=yes
RestrictNamespaces=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
CapabilityBoundingSet=

This was brought in from Arch Linux, where those settings are
apparently in place as well:

https://github.com/voxpupuli/puppet-prometheus/pull/415

-- System Information:
Debian Release: 10.2
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.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 prometheus depends on:
ii  adduser  3.118
ii  daemon   0.6.4-1+b2
ii  debconf [debconf-2.0]1.5.71
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-1
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libjs-bootstrap  3.4.1+dfsg-1
pn  libjs-bootstrap4 
pn  libjs-eonasdan-bootstrap-datetimepicker  
ii  libjs-jquery 3.3.1~dfsg-3
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2
ii  libjs-moment 2.24.0+ds-1
pn  libjs-moment-timezone
pn  libjs-mustache   
pn  libjs-popper.js  
pn  libjs-rickshaw   
ii  systemd-sysv 241-7~deb10u2

Versions of packages prometheus recommends:
ii  prometheus-node-exporter  0.17.0+ds-3+b11

prometheus suggests no packages.

Bug#950758: namecheap: Please make another source-only upload to allow Testing migration

[Boyuan Yang]

Source: namecheap
Version: 0.0.3-2
Severity: important

Dear namecheap maintainer,

Your package namecheap in Debian only saw the very first initial upload. As a
result, this upload will not migrate to Testing.

Please make another source-only upload to allow Testing migration. You may
find more information about source-only upload at 
https://wiki.debian.org/SourceOnlyUpload . Since you are a DM, you may handle
the upload by yourself. Feel free to let me know if you have special needs
(e.g., package sponsorship).

-- 
Thanks,
Boyuan Yang


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

Bug#950757: python-django-rest-framework-guardian: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: python-django-rest-framework-guardian
Version: 0.3.0-1
Severity: important
X-Debbugs-CC: fl...@debian.org

Dear python-django-rest-framework-guardian maintainer,

The package python-django-rest-framework-guardian you maintain in Debian saw
only the initial upload back in December. As a result, this upload was not a
source-only upload. Please consider making another source-only upload to allow
the package to migrate to Debian Testing. You may find more details about
source-only upload at https://wiki.debian.org/SourceOnlyUpload .

-- 
Thanks,
Boyuan Yang


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

Bug#950755: zookeeper: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: zookeeper
Version: 3.4.13-4
Severity: important
X-Debbugs-CC: ebo...@apache.org tmanc...@debian.org

Dear zookeeper maintainers,

The latest upload of package zookeeper introduced the new binary package
(python3-zookeeper) thus it was not a source-only upload. Please make another
source-only upload at your convenience to ensure that the python3 migration is
reflected in Testing.

Thanks,
Boyuan Yang


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

Bug#950756: plover: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: plover
Version: 4.0.0~dev8~66~g685bd33-1
Severity: important

Dear plover maintainer,

Your last upload of plover in Debian was the first upload. As a result, it was
not a source-only upload. Please make another source-only upload to allow the
package to migrate to Testing. You may find details about source-only upload
at https://wiki.debian.org/SourceOnlyUpload .

-- 
Thanks,
Boyuan Yang


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

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Till Kamppeter]

On 05/02/2020 20:14, Yves-Alexis Perez wrote:

So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in
order to do a comparison check, and tried to print, and it did work (with the
Brother PPD, unchanged).


This looks strange, there is no change in the pdftops filter which could 
have changed something before the last release.




Or try running the command

driverless


This doesn't return anything. My printer is on the network but I don't think
it advertises itself using Bonjour/zeroconf, so I'm unsure if it'd be enough
for that to find it.


driverless printing is a rather new property in network printers. It 
started some years ago with AirPrint to make iPhones be able to print 
when connecting to the local network via the WLAN of the router. 
Generally printers advertised to print from phones support at least one 
form of driverless printing, AirPrint in most cases. Typically the 
network printers launched in the last 5 years do driverless but your 
printer can be older.


"driverless" lists all IPP printers which support driverless printing.

   Till

Bug#950754: unbound: fails to parse old config file with do-not-query-localhost

[Kurt Roeckx]

Package: unbound
Version: 1.9.6-1
Severity: serious

Hi,

After upgrade to 1.9.6-1, unbound did no longer start. It did not
log anything about this in any log file.

I have a config that says:
do-not-query-localhost: no

It now returns a syntax error for that.


Kurt

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Till Kamppeter]

I have tried it also and with the command line

cupsfilter -p ../HL5250DN.ppd -i text/plain -m 
application/vnd.cups-postscript -e ~/.bashrc > out.ps 2>log


I got valid PostScript output with a PJL header. Note that I had to 
specify both input and output MIME types.


Probably in the cases whenthe printer does not print CUPS sends valid 
PJL and PostScript but some PostScript interpreter bug in the printer 
prevents it from printing.


You can try to send the PostScript output of the command line above to 
your printer without further filtering, either do


lp -d  -o raw out.ps

or

nc -w1  9100 < out.ps

Please try.

   Till

Bug#945546: Processed: libcrcutil: diff for NMU version 1.0-5.1

[Dmitry Smirnov]

On Thursday, 6 February 2020 4:06:03 AM AEDT Debian Bug Tracking System 
wrote:
> Bug #945546 [src:libcrcutil] libcrcutil: Please enable building on riscv64
> architecture Added tag(s) pending.

Thanks for your NMU, Adrian.

-- 
Regards,
 Dmitry Smirnov.

---

Honesty is a gift we can give to others. It is also a source of power and
an engine of simplicity. Knowing that we will attempt to tell the truth,
whatever the circumstances, leaves us with little to prepare for. We can
simply be ourselves.
-- Sam Harris


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

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Brian Potkin]

On Wed 05 Feb 2020 at 20:05:27 +0100, Yves-Alexis Perez wrote:

> On Wed, 2020-02-05 at 17:19 +, Brian Potkin wrote:
> > > Not really sure, but I don't think so. I mean, I'm using the PPD file
> > > from cups Debian packages, not anything from Brother.
> > 
> > As root, what do you get for
> > 
> >  grep "*NickName" /etc/cups/ppd/
> 
> *NickName: "Brother HL-5250DN BR-Script3"
> 
> The ppd is Copyright(C) 2005 Brother Industries, Ltd. so even if I have it
> from Debian, it still comes from Brother.

It is basically the same as the one I have from Brother.

> > Do you know the package name?
> 
> Not really, but I's the one cups (either the web interface or system-config-
> printer) shows me when using make & model.

We'll let that go. It is something for me to sort out.

> > > > I did test how filtering went with it
> > > > and a file or two. I got no errors, but did get the warnings you
> > > > got. Then again, I do not have the printer to print the output
> > > > file to.
> > > 
> > > Not entirely sure what is your workflow here, but with some details
> > > maybe I can try to reproduce what you did and see if something goes out
> > > of the printer?
> > 
> > Later, certainly. I'd like to test with your PPD first.
> 
> Attached.

Thanks. I used it (as root) with

 cupsfilter -p /etc/cups/ppd/ -m printer/foo -e /etc/nsswitch > out.ps 
2>log

There aren't any errors in the log.

Regards,

Brian.

Bug#950753: nmu: csound_1:6.13.0~dfsg-3 and other stk reverse dependencies

[Sebastian Ramacher]

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

libstk bumped its SOAME. So please schedule rebuilds for its reverse
dependencies:

nmu csound_1:6.13.0~dfsg-3 . ANY . unstable . -m "Rebuild against libstk-4.6.1"
dw csound_1:6.13.0~dfsg-3 . ANY . -m "libstk0-dev (>= 4.6.1)"
nmu lmms_1.2.1+dfsg1-4 . ANY . unstable . -m "Rebuild against libstk-4.6.1"
dw lmms_1.2.1+dfsg1-4 . ANY . -m "libstk0-dev (>= 4.6.1)"
nmu pd-flext_0.6.0+git20161101.1.01318a94-4 . ANY . unstable . -m "Rebuild 
against libstk-4.6.1"
dw pd-flext_0.6.0+git20161101.1.01318a94-4 . ANY . -m "libstk0-dev (>= 4.6.1)"
nmu supercollider-sc3-plugins_3.9.1~repack-3 . ANY . unstable . -m "Rebuild 
against libstk-4.6.1"
dw supercollider-sc3-plugins_3.9.1~repack-3 . ANY . -m "libstk0-dev (>= 4.6.1)"

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#950752: jove: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: jove
Version: 4.17.1.4-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for jove
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
# Helge Kreutzmann , 2006,2020.
#
msgid ""
msgstr ""
"Project-Id-Version: jove 4.17.1.0-1\n"
"Report-Msgid-Bugs-To: j...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-04 22:52+0100\n"
"PO-Revision-Date: 2020-02-02 09:31+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-15\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../jove.templates:1001
msgid "Found old version of /etc/jove.rc. Moved it to /etc/jove/jove.rc"
msgstr ""
"Alte Version von /etc/jove.rc gefunden. Datei wird nach /etc/jove/jove.rc "
"verschoben."

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Old version of /etc/jove.rc and new version /etc/jove/jove.rc found"
msgstr ""
"Alte Version von /etc/jove.rc und neue Version von /etc/jove/jove.rc gefunden."

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Moving old version to /etc/jove/jove.rc.old"
msgstr "Die alte Version wird nach /etc/jove/jove.rc.old verschoben."

#. Type: note
#. Description
#: ../jove.templates:3001
msgid "Removed obsolete /etc/init.d/jove script"
msgstr "Es wurde das veraltete Skript /etc/init.d/jove entfernt."

#. Type: note
#. Description
#: ../jove.templates:3001
msgid "Check NEWS.Debian for more information"
msgstr "Bitte lesen Sie NEWS.Debian für weitere Informationen."

#. Type: note
#. Description
#: ../jove.templates:4001
msgid "Found old files in /var/lib/jove/preserve/"
msgstr "Es wurden alte Dateien in /var/lib/jove/preserve/ gefunden."

#. Type: note
#. Description
#: ../jove.templates:4001
msgid ""
"You can recover those by running jove -r Check NEWS.Debian for more "
"information."
msgstr ""
"Sie können diese mittels »jove -r« wiederherstellen. Bitte lesen Sie NEWS."
"Debian für weitere Informationen."

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-02-05 at 19:32 +0100, Till Kamppeter wrote:
> Probably the best is to try to print without using PostScript. When 
> creating a print queue and selecting your printer's make, model, and 
> driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e 
> (ljet4/ljet4d/hpcups/hpijs) options.

So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in
order to do a comparison check, and tried to print, and it did work (with the
Brother PPD, unchanged).
> 
> Or try running the command
> 
> driverless

This doesn't return anything. My printer is on the network but I don't think
it advertises itself using Bonjour/zeroconf, so I'm unsure if it'd be enough
for that to find it.
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl47FBMACgkQ3rYcyPpX
RFtdsAf8D6wygO1CWSEe/xm1ZS5EkItg8zU4w69VvGmx/oeGAhd1KszecD2NwCkn
1SauiLt/POdnpCHCaiFpgzkHqmsXEW4IMg6rUxSawkLUnEgSeRW+UQT052VlNCWY
S9WvJxzoDDDQWjIUAX0oGy6fSDc9J61092S+TEBKwREtqifo2SdsBJ1DK0O9lOZp
LGY8RAdrJgL/XoIZnh30yJMTXqTG3KTuUMolTWBQeqQ0QR0VcQxhPVFZijcO8+5S
5PU8njwahwPXU7taZDCVcOtekboxMU8vSNJf9Gk7gkOxFEioMdSqaCLWCb3UGZyv
u83o2BbBxdtgY6g/BzRJCbh/39J2wA==
=wKgw
-END PGP SIGNATURE-

Bug#893912: stretch-backports doesnt help either

[Kate Komi]

On Sun, 3 Mar 2019 22:46:20 + living proof  wrote:
> for as well stretch-backports does not fix the problem
>

[2.574742] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_config.bin
[2.575137] bluetooth hci0: firmware: failed to load
rtl_bt/rtl8821a_config.bin (-2)
[2.575143] bluetooth hci0: Direct firmware load for
rtl_bt/rtl8821a_config.bin failed with error -2
[2.575145] Bluetooth: hci0: Failed to load rtl_bt/rtl8821a_config.bin

copying rtl8723a_config.bin from
https://github.com/lwfinger/rtl8723au_bt/ to  /lib/firmware/rtl_bt/
does NOT solve the issue. You are actually pointing to a config file
for a completly different device.

We are using the rtl8821a this config file is for the rtl8723au_bt...

Good evening.

I was fighting with this problem (Direct firmware load for
rtl_bt/rtl8821a_config.bin failed with error -2) for some time. In
/lib/firmware/rtl_bt/ directory I found that indeed this file has a
problem to load because this file does not even exist. For some reason
only one file is present, rtl8821a_fw.bin, where another device has
two (rtl8821c_config.bin and rtl8821c_fw.bin):

ls -al /lib/firmware/rtl_bt

...
-rw-r--r--  1 root root 40520 Aug 23 02:04 rtl8812ae_fw.bin
-rw-r--r--  1 root root 37420 Aug 23 02:04 rtl8821a_fw.bin
-rw-r--r--  1 root root10 Aug 23 02:04 rtl8821c_config.bin
-rw-r--r--  1 root root 37356 Aug 23 02:04 rtl8821c_fw.bin
...

I had package firmware-realtek installed in newest version, so I
downloaded .deb package from Debian webpage
(https://packages.debian.org/buster-backports/firmware-realtek).
Browsing it as
archive I found that file rtl_bt/rtl8821a_config.bin is also absent,
for unknown to me reason.

Then I started looking for this file in other releases (sid and
bullseye), with no positive result. I visited Realtek webpage, only to
find that they have drivers only for Windows for this
device. Digging further, on address
https://patchwork.ozlabs.org/patch/952071/ , I discovered following
note about some Realtek devices:

> The Bluetooth parts of RTL8723D and RTL8723B share the same lmp
> subversion, thus we need to check both lmp subversion and hci revision
> to distinguish the two. The same situation is true for RTL8821A and
> RTL8821C. Accordingly, the selection code is revised.

> To improve maintainability, a new id_table struct is defined, and an
> array of such structs is constructed. Adding a new device can thus be
> as simple as adding another value to the table.

With lack of luck in my quest to find rtl8821a_config.bin file for
Debian Buster I decided to try a crazy idea: duplicate
rtl8821c_config.bin file and rename duplication on
rtl8821a_config.bin.

-rw-r--r--  1 root root 40520 Aug 23 02:04 rtl8812ae_fw.bin
-rw-r--r--  1 root root10 Feb  5 17:11 rtl8821a_config.bin
-rw-r--r--  1 root root 37420 Aug 23 02:04 rtl8821a_fw.bin
-rw-r--r--  1 root root10 Aug 23 02:04 rtl8821c_config.bin
-rw-r--r--  1 root root 37356 Aug 23 02:04 rtl8821c_fw.bin


If both devices are so similar, maybe providing fake
rtl8821a_config.bin file will do the trick. After restart I I used
dmesg and checked logs:

[   26.389532] Bluetooth: hci0: RTL: rtl: examining hci_ver=06
hci_rev=000a lmp_ver=06 lmp_subver=8821

[   26.390623] Bluetooth: hci0: RTL: rom_version status=0 version=1

[   26.390624] Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8821a_fw.bin

[   26.392597] bluetooth hci0: firmware: direct-loading firmware
rtl_bt/rtl8821a_fw.bin
[   26.392605] Bluetooth: hci0: RTL: rtl: loading rtl_bt/rtl8821a_config.bin

[   26.392748] bluetooth hci0: firmware: direct-loading firmware
rtl_bt/rtl8821a_config.bin
[   26.392757] Bluetooth: hci0: RTL: cfg_sz 10, total sz 17438

Well, it looked promising. I installed some additional
Bluetooth-related packages (blueman, bluewho and entire family of
bluez; bluetooth and bluez were installed earlier) and then I
launched Bluetooth Manager. It turns out that program not only
detected Bluetooth device on my laptop but also I was able to send
files between my laptop and my Nokia mobile on both
directions. I paired successfully both devices, but because lack of
Bluetooth speakers I do not know if it is possible to play music via
Bluetooth. It should be, I hope.

So, my "solution" seems to work, at least for me. But may I ask the
question why file named rtl8821a_config.bin is not present in the
firmware-realtek package? It does not exist at all or was
removed for some reason?

Also my method is nasty, I know about it, but if anyone will solve
his/her problem by it, I will be happy.

With kindest regards,

Oliwia

Bug#950751: SyntaxWarning: "is" with a literal. Did you mean "=="

[Witold Baryluk]

Package: wifite
Version: 2.5.0~git20191114-2
Severity: normal

Dear Maintainer,

Looks like an obvious bug here, and it shows during dpkg setup (compiling
files probably) too:

Setting up wifite (2.5.0~git20191114-2) ...
/usr/lib/python3/dist-packages/wifite/tools/ifconfig.py:21: SyntaxWarning: "is" 
with a literal. Did you mean "=="?
  elif type(args) is 'str':
...



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

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

Versions of packages wifite depends on:
ii  aircrack-ng  1:1.5.2-3+b1
ii  net-tools1.60+git20180626.aebd88e-1
ii  python3  3.7.5-3
ii  reaver   1.6.5-1+b1
ii  tshark   3.2.1-1

wifite recommends no packages.

Versions of packages wifite suggests:
pn  bully
ii  hashcat  5.1.0+ds1-1
ii  hcxdumptool  5.1.7-1+b1
pn  hcxpcaptool  
pn  macchanger   
ii  pyrit0.5.1+git20180801-2

-- no debconf information

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Yves-Alexis Perez]

On Wed, 2020-02-05 at 17:19 +, Brian Potkin wrote:
> > Not really sure, but I don't think so. I mean, I'm using the PPD file
> > from cups Debian packages, not anything from Brother.
> 
> As root, what do you get for
> 
>  grep "*NickName" /etc/cups/ppd/

*NickName: "Brother HL-5250DN BR-Script3"

The ppd is Copyright(C) 2005 Brother Industries, Ltd. so even if I have it
from Debian, it still comes from Brother.
> 
> Do you know the package name?

Not really, but I's the one cups (either the web interface or system-config-
printer) shows me when using make & model.
> 
> > > I did test how filtering went with it
> > > and a file or two. I got no errors, but did get the warnings you
> > > got. Then again, I do not have the printer to print the output
> > > file to.
> > 
> > Not entirely sure what is your workflow here, but with some details
> > maybe I can try to reproduce what you did and see if something goes out
> > of the printer?
> 
> Later, certainly. I'd like to test with your PPD first.

Attached.
> 
> Open a new issue referring to #169 and referencing the Debian report.
I saw your other mail so I'm postponing that. I'll also check the steps from
Till

Regards,
--
Yves-Alexis
*PPD-Adobe: "4.3"
*% This program is free software; you can redistribute it and/or modify it
*% under the terms of the GNU General Public License as published by the Free
*% Software Foundation; either version 2 of the License, or (at your option)
*% any later version.
*%
*% This program is distributed in the hope that it will be useful, but WITHOUT
*% ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
*% FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
*% more details.
*%
*% You should have received a copy of the GNU General Public License along with
*% this program; if not, write to the Free Software Foundation, Inc., 59 Temple
*% Place, Suite 330, Boston, MA  02111-1307  USA
*%


*%
*%  Copyright(C) 2005 Brother Industries, Ltd.
*%  "Brother HL-5250DN BR-Script3"
*%

*% General Information Keywords 
*FormatVersion: "4.3"
*FileVersion: "1.03"
*LanguageEncoding: ISOLatin1
*LanguageVersion: English
*Manufacturer: "Brother"
*PCFileName: "BR5250_2.PPD"
*Product: "(Brother HL-5250DN series)"
*PSVersion: "(3010.106) 5"
*ShortNickName: "Brother HL-5250DN BR-Script3"
*ModelName: "Brother HL-5250DN BR-Script3"
*NickName: "Brother HL-5250DN BR-Script3"
*1284DeviceID: "MFG:Brother;MDL:HL-5250DN series;CMD:PJL,PCL,PCLXL,POSTSCRIPT;"

*% Basic Device Capabilities =
*LanguageLevel: "3"
*TTRasterizer: Type42
*ColorDevice: False
*DefaultColorSpace: Gray
*FileSystem: True
*?FileSystem:"
save 
/devname (%disk0%) def 
/ret false def 
0 1 7{ 
devname exch 48 add 5 exch put 
devname devstatus { 
0 ne {/ret true def}if 
pop pop pop pop pop pop pop 
}if 
}for 
ret {(True)}{(False)} ifelse = flush 
restore 
" 
*End

*Throughput: "28"
*FreeVM: "605"

*% Emulations and Protocols ==
*Protocols: PJL TBCP

*SuggestedJobTimeout: "0"
*SuggestedWaitTimeout: "300"
*PrintPSErrors: True

*% PostScript Patches ==
*%*JobPatchFile 1: "statusdict/setusbbinary known{statusdict begin true 
setusbbinary end}if"

*% JCL Features ==
*JCLBegin:   "<1B>%-12345X@PJL JOB<0A>"
*JCLToPSInterpreter: "@PJL ENTER LANGUAGE = POSTSCRIPT <0A>"
*JCLEnd: "<1B>%-12345X@PJL EOJ <0A><1B>%-12345X"

*% Installable Options ===

*OpenGroup: InstallableOptions/Options Installed

*OpenUI *OptionTrays/Number of Input Trays: PickOne
*DefaultOptionTrays: 1Trays
*OptionTrays 1Trays/ 1: ""
*OptionTrays 2Trays/ 2: ""
*OptionTrays 3Trays/ 3: ""
*?OptionTrays:"
save
<>setpagedevice currentpagedevice/BRFeeder get
2 eq{(3Trays)}{
  <>setpagedevice currentpagedevice/BRFeeder get
  1 eq{(2Trays)}{(1Trays)}ifelse
}ifelse
  = flush 
restore 
"
*End
*CloseUI: *OptionTrays

*CloseGroup: InstallableOptions

*UIConstraints: *OptionTrays 1Trays *InputSlot Tray2
*UIConstraints: *InputSlot Tray2 *OptionTrays 1Trays
*UIConstraints: *OptionTrays 1Trays *InputSlot Tray3
*UIConstraints: *InputSlot Tray3 *OptionTrays 1Trays
*UIConstraints: *OptionTrays 2Trays *InputSlot Tray3
*UIConstraints: *InputSlot Tray3 *OptionTrays 2Trays



*% Media Selection ==

*OpenUI *PageSize: PickOne
*OrderDependency: 30 AnySetup *PageSize
*DefaultPageSize: A4
*PageSize Letter/Letter: "<< /PageSize [612 792] /ImagingBBox null >> 
setpagedevice"
*PageSize Legal/Legal: "<< /PageSize [612 1008] /ImagingBBox null >> 
setpagedevice"
*PageSize Executive/Executive: "<< /PageSize [522 756] /ImagingBBox null >> 
setpagedevice"
*PageSize A4/A4: "<< /PageSize [595 842] /ImagingBBox 

Bug#950750: zita-alsa-pcmi FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: zita-alsa-pcmi
Version: 0.3.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

zita-alsa-pcmi fails to cross build from source, because it does not
pass cross tools to make. The easiest way of doing so - using
dh_auto_build - makes zita-alsa-pcmi cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru zita-alsa-pcmi-0.3.2/debian/changelog 
zita-alsa-pcmi-0.3.2/debian/changelog
--- zita-alsa-pcmi-0.3.2/debian/changelog   2020-02-03 20:36:38.0 
+0100
+++ zita-alsa-pcmi-0.3.2/debian/changelog   2020-02-05 19:50:12.0 
+0100
@@ -1,3 +1,10 @@
+zita-alsa-pcmi (0.3.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Feb 2020 19:50:12 +0100
+
 zita-alsa-pcmi (0.3.2-1) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru zita-alsa-pcmi-0.3.2/debian/rules 
zita-alsa-pcmi-0.3.2/debian/rules
--- zita-alsa-pcmi-0.3.2/debian/rules   2020-02-03 20:35:57.0 +0100
+++ zita-alsa-pcmi-0.3.2/debian/rules   2020-02-05 19:50:10.0 +0100
@@ -11,8 +11,8 @@
dh $@ -Smakefile
 
 override_dh_auto_build:
-   $(MAKE) -C source/
-   $(MAKE) -C apps/
+   dh_auto_build --sourcedirectory=source
+   dh_auto_build --sourcedirectory=apps
 
 override_dh_auto_clean:
dh_auto_clean

Bug#950749: ITP: node-mqtt-connection -- Barebone Connection object for MQTT

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Severity: wishlist
Owner: Ying-Chun Liu (PaulLiu) 


* Package name    : node-mqtt-connection
  Version : 4.0.0
  Upstream Author : mqtt-connection contributors
* URL : https://github.com/mqttjs/mqtt-connection
* License : Expat
  Programming Lang: JavaScript
  Description : Barebone Connection object for MQTT
 This library uses mqtt-packet for generating and parsing MQTT packets. It
 works over any kind of binary Streams. For example, TCP, TLS, and
WebSocket.
 .
 Node.js is an event-based server-side JavaScript engine.





signature.asc
Description: OpenPGP digital signature

Bug#950748: bootparamd does not receive broadcast messages unless rpcbind is run with -r

[Joshua Honeycutt]

Package: bootparamd
Version: 0.17-10
Severity: normal

Dear Maintainer,

I was attempting to use rarpd/tftp/bootparamd/nfs to do a solaris 
jumpstart installation. When running "rpc.bootparamd -d" I could see 
requests directly to the host (testing via callbootd), but requests
sent broadcast (both 192.168.1.255/24 and 255.255.255.255) never reached 
bootparamd.


I found adding the remote call option (-r) in /etc/default/rpcbind 
caused bootparamd to start seeing broadcast messages.


I see this behavior is documented in /usr/share/doc/rpcbind/README.Debian
but I'm wondering if you think there should be a information in
rpc.bootparamd(8) or other docs to indicate broadcasts may be ignored
by default because it's not obvious rpcbind may be involved.

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

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

Versions of packages bootparamd depends on:
ii  libc6  2.28-10
ii  rpcbind [portmap]  1.2.5-0.3+deb10u1

bootparamd recommends no packages.

bootparamd suggests no packages.

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Till Kamppeter]

The warning about not being able to convert color input into grayscale 
is principally no problem for you, as monochrome PostScript printers can 
receive color input without any problems, they convert the input by 
themselves.


What this warning tells to me is that you upgraded from a cups-filters 
version from before the fix of this issue


https://github.com/OpenPrinting/cups-filters/issues/169
   PS Level 1 forced for grayscale PDF rendering with Poppler/Cairo

to one afterwards.

Without the fix of this issue your printer had most probably received 
PostScript Level 1 and happily printed it.


Now it is receiving PostScript Level 2.

Brother PostScript printers are known to have many bugs in their 
PostScript interpreters and therefore we have already a big bunch of 
workarounds in our pdftops filter.


Probably the best is to try to print without using PostScript. When 
creating a print queue and selecting your printer's make, model, and 
driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e 
(ljet4/ljet4d/hpcups/hpijs) options.


Or try running the command

driverless

If it lists a URI (Unified Resource Identifier) for your printer 
(contains your printers host name, IP, or make/model), try to set up 
your printer with


lpadmin -p Printers -E -v URI -m everywhere

replacing URI by your printer's URI from the "driverless" output.

Does this work?

   Till

Bug#950747: projectl: Projectl fails to run with current libgphobos76

[Moshe Piekarski]

Package: projectl
Version: 1.001.dfsg1-9
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

projectl, which has a last changelog entry from april 2018 fails with
error: symbol lookup error: projectl: undefined symbol:
_D4core4stdc5errno5errnoFNbNdNiNeZi
Some googling suggests that this symbol belongs to the D runtime
(libgphobos76) which in 2018 was compiled from gcc-8 but today is compiled from 
gcc-9.
I built and installed the package locally and it works fine.
Please update the libgphobos76 dependency (and possibly make it a transition).

Thank you,
Moshe Piekarski

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

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

Versions of packages projectl depends on:
ii  libc62.29-9
ii  libgcc1  1:9.2.1-25
ii  libgl1   1.3.0-7
ii  libgphobos76 9.2.1-25
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-5

projectl recommends no packages.

projectl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAl47CVkZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igRTND/4x/VmNCXR18Ya9MVq+vXac
ZpW1IgcVXNI0AIi3md/h8sIxUhcKvvbRLTMXSG2lW233438dARJEIQUUv29L6x4+
qCM+/dwfPIECftfDW2DA1inkTPFQvd76h1U8nobBkZDrNlvZtOGyB61ZES0PtxT1
4WFGP1nTf4bXXMsJrj8wEP7qCEQC+M64Njpk5HERV/uJ9x6/ccCykA97wPTuTytZ
If4+Xp5XpXP4gw6rXqgYqHL3C8rRJD76xPNSMyDZ/QQnU1hItQDVmgXpNRCs2eIj
Nx++Xt41pX38aLjOTZJHEFBk9Gt6nEsD073kg8ltzrKW7RvuayQdMKxpC9Nen67d
nODVOqL01TYf8OQz/mq8kys7hKG6g5x2elAY0HZsZi6uTLKYBCnqRRHUBwViNytq
imZNtHFktMAKdVX7eC6OcM/HlCkxgVxlg++yHK9AHtSVNEHwybVkCF2D6SEevUqB
JOp3XYly7M2cwWgk5/3qGrvITmu7aSP8aU41BoV7LlchHLLXVTfp5J/iOtA4twim
98TCU+BDXVNoTPEjwZLNsCTyV1SccfzQDCqgZYsPdRY0ibZT7SX55Kh3hjERBpVl
XnZyGr6Y+sJWVVPLjL3shCfXB0Sp8Xiv6XDM0VuywffPReorrm6+7ioepxuYXAm7
BGgA4EpY0LyGssYZycexVA==
=Td/2
-END PGP SIGNATURE-

Bug#950746: gbrowse: Homepage field needs updating

[Adrian Bunk]

Source: gbrowse
Version: 2.54+dfsg-3
Severity: minor

The domain of the Homepage: field in debian/control expired,
current upstream location seems to be http://gmod.org/wiki/GBrowse

Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Michael Biebl]

Am 05.02.20 um 18:15 schrieb Michael Biebl:
> Am 05.02.20 um 13:28 schrieb Michael Biebl:
>> Am 05.02.20 um 13:22 schrieb Michael Biebl:
>>> Am 05.02.20 um 10:47 schrieb Andrey Rahmatullin:
 Attached.
>>>
>>>
 Running create action for entry a /var/log/journal
 Detected unsafe path transition /var/log → /var/log/journal during 
 canonicalization of /var/log/journal.
 Running create action for entry a /var/log/journal
>>>
>>> It appears this problem happens, if / is not owned by root:root and
>>> doesn't have 755. Since you said that all your files/directories were
>>> owned by sbuild:sbuild, it is likely that those messed up permissions
>>> tripped up systemd-tmpfiles.
>>
>> https://github.com/systemd/systemd/issues/11282
> 
> Sorry, should have read the bug report and your error message more
> closely. It's obviously /var/log (and not /) which has the wrong
> permissions. Otherwise the error message would have been different.
> 
> The reason why systemd-tmpfiles is complaining here, is that an
> unprivileged user (sbuild) has access over subdirectories with higher
> privileges and can fiddle with them (making it susceptible to a variety
> of symlink attacks)
> 
> Now, the question: How should systemd postinst behave in this case?
> Personally, I think throwing an error and letting the admin fix the
> situation is probably not the worst solution.
> Automatically fixing up the permissions in postinst is icky and I'd
> rather not do that.
> Simply ignore the error? Not sure, doesn't sound compelling either.
> 
> WDYT?
> 
> I have to add, that I just installed sbuild and created a sid chroot
> which did not have those permissions for /var/log.
> Maybe this was a bug in older versions of sbuild.
> 

Johannes, could you chime in here?
Do you have some insight why /var/log might have these permissions?

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#950745: RM: nuxwdog -- ROM; obsolete

[Timo Aaltonen]

Package: ftp.debian.org
Severity: normal

Dogtag-pki merged the functionality provided by nuxwdog in 10.6.10-1, so
the separate source can be removed, there should be no reverse-depends left.

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Michael Shuler]

On 2/5/20 11:12 AM, Dan Nicholson wrote:

I recently ran into this same issue and dug into it for a while. The
real problem stems from
https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is
that glibc 2.28 changed readdir to always use getdents64. This causes
problems when you're running a 32 bit guest in QEMU on a 64 bit host.
So, this would also affect running an i386 guest on an x86_64 host,
for example.


Thanks for the details. This appears more to me now that this is a lower 
level issue than the symptomatic behavior we see in processing 
certificates. (ie. this is not a bug with ca-certificates, but with openssl)





So, I think there are a few options on what to do.

1. Change update-ca-certificates back to using c_rehash. Presumably
perl is built with LFS and it's readdir wrapper DTRT.


c_rehash could be removed at any time, so I don't think this is a good 
option.



2. Build openssl with LFS as noted above.


Noted, thanks. This is why I am starting to believe this is a bug with 
openssl, not ca-certificates.



3. Wait for a fix to be hashed out between the glibc, kernel and qemu folks.


..which I suppose is indeed the eventual lower level issue to resolve, 
below openssl.


--
Kind regards,
Michael

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Dan Nicholson]

It posted https://salsa.debian.org/debian/openssl/merge_requests/4 to
build openssl with largefile support.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Brian Potkin]

On Wed 05 Feb 2020 at 17:19:31 +, Brian Potkin wrote:

> Open a new issue referring to #169 and referencing the Debian report.

Sorry; I should have suggested leaving doing this until we both have had
the opportunity to test the filtering system.

Regards,

Brian.

Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Andrey Rahmatullin]

On Wed, Feb 05, 2020 at 06:15:34PM +0100, Michael Biebl wrote:
> Now, the question: How should systemd postinst behave in this case?
I think failing is fine. I'd ask the sbuild maintainers what do they think
about this situation, and why such chroots exist (and/or maybe ask some
other people if theis chroots have the same perms).


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Brian Potkin]

On Wed 05 Feb 2020 at 17:18:28 +0100, Yves-Alexis Perez wrote:

> On Wed, Feb 05, 2020 at 03:29:22PM +, Brian Potkin wrote:
> > Your issue seems connected with
> > 
> >  https://github.com/OpenPrinting/cups-filters/issues/169
> > 
> > and its associated bugs.
> 
> When looking at the warning message in the logs I stumbled on that bug,
> but didn't really find it really informative (especially since it's
> closed while I still have the bug).

I think using gs as the renderer is regarded as the fix but, TBH, I got
a little lost when I started looking at the bugs linked from #169.

> > I take it you are using the PostScript
> > PPD provided by Brother. 
> 
> Not really sure, but I don't think so. I mean, I'm using the PPD file
> from cups Debian packages, not anything from Brother.

As root, what do you get for

 grep "*NickName" /etc/cups/ppd/

Do you know the package name?

> > I did test how filtering went with it
> > and a file or two. I got no errors, but did get the warnings you
> > got. Then again, I do not have the printer to print the output
> > file to.
> 
> Not entirely sure what is your workflow here, but with some details
> maybe I can try to reproduce what you did and see if something goes out
> of the printer?

Later, certainly. I'd like to test with your PPD first. 

> > I am not sure I really understand all that is involved here, so,
> > because you are able to provide first-hand experience, suggest
> > you forward the issue upstream.
> 
> Just to be sure: do you mean opening a new issue on upstream github, or
> just commenting on the issue linked above?

Open a new issue referring to #169 and referencing the Debian report.

Regards,

Brian.

Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Michael Biebl]

Am 05.02.20 um 13:28 schrieb Michael Biebl:
> Am 05.02.20 um 13:22 schrieb Michael Biebl:
>> Am 05.02.20 um 10:47 schrieb Andrey Rahmatullin:
>>> Attached.
>>
>>
>>> Running create action for entry a /var/log/journal
>>> Detected unsafe path transition /var/log → /var/log/journal during 
>>> canonicalization of /var/log/journal.
>>> Running create action for entry a /var/log/journal
>>
>> It appears this problem happens, if / is not owned by root:root and
>> doesn't have 755. Since you said that all your files/directories were
>> owned by sbuild:sbuild, it is likely that those messed up permissions
>> tripped up systemd-tmpfiles.
> 
> https://github.com/systemd/systemd/issues/11282

Sorry, should have read the bug report and your error message more
closely. It's obviously /var/log (and not /) which has the wrong
permissions. Otherwise the error message would have been different.

The reason why systemd-tmpfiles is complaining here, is that an
unprivileged user (sbuild) has access over subdirectories with higher
privileges and can fiddle with them (making it susceptible to a variety
of symlink attacks)

Now, the question: How should systemd postinst behave in this case?
Personally, I think throwing an error and letting the admin fix the
situation is probably not the worst solution.
Automatically fixing up the permissions in postinst is icky and I'd
rather not do that.
Simply ignore the error? Not sure, doesn't sound compelling either.

WDYT?

I have to add, that I just installed sbuild and created a sid chroot
which did not have those permissions for /var/log.
Maybe this was a bug in older versions of sbuild.

Michael






signature.asc
Description: OpenPGP digital signature

Bug#923479: update-ca-certificates fails to create hashes under 32-bit ARM (qemu)

[Dan Nicholson]

I recently ran into this same issue and dug into it for a while. The
real problem stems from
https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is
that glibc 2.28 changed readdir to always use getdents64. This causes
problems when you're running a 32 bit guest in QEMU on a 64 bit host.
So, this would also affect running an i386 guest on an x86_64 host,
for example.

The issue is that rehash calls OPENSSL_DIR_read on the certificate
directory. This is actually just a wrapper around readdir. However, if
you compile openssl (really libcrypto) with large file support, then
glibc actually uses readdir64, which will use a dirent64 structure
that doesn't have the overflow issues that the regular dirent
structure has in this situation.

After building openssl locally with future=+lfs in
DEB_BUILD_MAINT_OPTIONS, I was able to get the right behavior. Here's
a comparison (certs is just a local directory with one of the symlinks
from /etc/ssl/certs copied into it).

Current behavior:

root@talkbox:~# /qemu-arm-static -strace /usr/bin/openssl rehash
certs/ 2>&1 | grep getdents64
20411 getdents64(3,-13637592,32768,-559685376,-13637592,-622472) = 128

With LFS libcrypto:

root@talkbox:~#
LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf
/qemu-arm-static -strace /usr/bin/openssl rehash certs/ 2>&1 | grep
getdents64
20402 getdents64(3,-13637592,32768,0,32,-13637624) = 128
20402 getdents64(3,-13637592,32768,128,32,-13637624) = 0

And just the normal rehash output:

root@talkbox:~# openssl rehash -v certs/
Doing certs/
root@talkbox:~#
LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf/ openssl
rehash -v certs/
Doing certs/
link thawte_Primary_Root_CA.pem -> 2e4eed3c.0

So, I think there are a few options on what to do.

1. Change update-ca-certificates back to using c_rehash. Presumably
perl is built with LFS and it's readdir wrapper DTRT.

2. Build openssl with LFS as noted above.

3. Wait for a fix to be hashed out between the glibc, kernel and qemu folks.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless

Bug#945546: libcrcutil: diff for NMU version 1.0-5.1

[Adrian Bunk]

Control: tags 945546 + patch
Control: tags 945546 + pending

Dear maintainer,

I've prepared an NMU for libcrcutil (versioned as 1.0-5.1) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru libcrcutil-1.0/debian/changelog libcrcutil-1.0/debian/changelog
--- libcrcutil-1.0/debian/changelog	2018-05-01 17:07:09.0 +0300
+++ libcrcutil-1.0/debian/changelog	2020-02-05 18:41:16.0 +0200
@@ -1,3 +1,10 @@
+libcrcutil (1.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable building on riscv64. (Closes: #945546)
+
+ -- Adrian Bunk   Wed, 05 Feb 2020 18:41:16 +0200
+
 libcrcutil (1.0-5) unstable; urgency=medium
 
   * New patch to fix FTBFS due to non-ASCII character (Closes: #896501).
diff -Nru libcrcutil-1.0/debian/control libcrcutil-1.0/debian/control
--- libcrcutil-1.0/debian/control	2018-05-01 17:03:54.0 +0300
+++ libcrcutil-1.0/debian/control	2020-02-05 18:41:16.0 +0200
@@ -12,7 +12,7 @@
 Vcs-Git: https://salsa.debian.org/debian/crcutil.git
 
 Package: libcrcutil0
-Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel any-mips64el any-ppc64el any-sh4 any-x32
+Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel any-mips64el any-ppc64el any-riscv64 any-sh4 any-x32
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -42,7 +42,7 @@
 
 Package: libcrcutil-dev
 Section: libdevel
-Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel any-mips64el any-ppc64el any-sh4 any-x32
+Architecture: any-alpha any-amd64 any-arm any-arm64 any-i386 any-ia64 any-mipsel any-mips64el any-ppc64el any-riscv64 any-sh4 any-x32
 Depends: ${misc:Depends}, libcrcutil0 (= ${binary:Version})
 Suggests: libcrcutil-doc
 Description: library for cyclic redundancy check (CRC) computation - development files

Bug#669334: ascii2uni -a U byte injection

[Will Huang]

There is a bug here:

echo -n 'const t.\u0275fac=1;' | ascii2uni -a U
const t.=1;
1 token converted

The "fac" is been stripped.

Bug#950743: satpy: autopkgtest failures

[Bas Couwenberg]

Source: satpy
Version: 0.19.1-1
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The update of python3-xarray breaks autopkgtest:

 === python3.8 ===
 satpy (unittest.loader._FailedTest) ... ERROR
 
 ==
 ERROR: satpy (unittest.loader._FailedTest)
 --
 ImportError: Failed to import test module: satpy
 Traceback (most recent call last):
   File "/usr/lib/python3.8/unittest/loader.py", line 154, in loadTestsFromName
 module = __import__(module_name)
   File "/usr/lib/python3/dist-packages/satpy/__init__.py", line 53, in 
 from satpy.writers import available_writers  # noqa
   File "/usr/lib/python3/dist-packages/satpy/writers/__init__.py", line 29, in 

 import xarray as xr
   File "/usr/lib/python3/dist-packages/xarray/__init__.py", line 1, in 
 from . import testing, tutorial, ufuncs
   File "/usr/lib/python3/dist-packages/xarray/testing.py", line 7, in 
 from xarray.core import duck_array_ops, formatting
 ModuleNotFoundError: No module named 'xarray.core'
 
 
 --
 Ran 1 test in 0.000s

https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/4199620/log.gz

Kind Regards,

Bas

Bug#936630: Re: Bug#936630: gnumed-client: upstream has (unreleased) py3 support

[Scott Talbert]

On Thu, 30 Jan 2020, Andreas Tille wrote:


On Thu, Jan 30, 2020 at 09:14:35PM +0100, Karsten Hilbert wrote:

It's done, there's even a release 1.8.rc3.

I need to convince myself to release 1.8.0 proper :-)


Please convince yourself and I'll upload.


Agree, consider this another prod to convince yourself.  :)  The wxPython 
3.0 reverse depends are dwindling down to half a dozen or so, so it is 
getting closer to removal time.


BTW, the gnumed website seems to be having some problems.

Scott

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Yves-Alexis Perez]

On Wed, Feb 05, 2020 at 03:29:22PM +, Brian Potkin wrote:
> Your issue seems connected with
> 
>  https://github.com/OpenPrinting/cups-filters/issues/169
> 
> and its associated bugs.

When looking at the warning message in the logs I stumbled on that bug,
but didn't really find it really informative (especially since it's
closed while I still have the bug).

> I take it you are using the PostScript
> PPD provided by Brother. 

Not really sure, but I don't think so. I mean, I'm using the PPD file
from cups Debian packages, not anything from Brother.

> I did test how filtering went with it
> and a file or two. I got no errors, but did get the warnings you
> got. Then again, I do not have the printer to print the output
> file to.

Not entirely sure what is your workflow here, but with some details
maybe I can try to reproduce what you did and see if something goes out
of the printer?
> 
> I am not sure I really understand all that is involved here, so,
> because you are able to provide first-hand experience, suggest
> you forward the issue upstream.

Just to be sure: do you mean opening a new issue on upstream github, or
just commenting on the issue linked above?

Regards,
-- 
Yves-Alexis

Bug#606930: apt CDROM method fails if more than one package is required from a CDROM

[Jesse Jarzynka]

I think I'm still hitting this issue 10 years later. On Ubuntu 18.04.1 I
was trying to add the 18.04.2 CD as a source to upgrade from. It would seem
to work and I could upgrade single packages, but if I would do an upgrade I
would get "File not found" for every package even though the paths being
referenced were correct. The "cdrom://" protocol being sort of obtuse
really made debugging it difficult. I randomly noticed in my output from
"apt-config dump": Acquire::cdrom::mount "/media/cdrom/"; even though
apt-cdrom automatically mounted the disk to "/media/apt". I decided to try
symlinking "/media/cdrom" to "/media/apt" and it started working properly!

So it appears that there's some disconnect in apt between "/media/apt" and
"/media/cdrom" and when to look at each, or "Acquire::cdrom::mount" is not
getting updated when apt-cdrom is being ran. A similar issue was posted
here -
https://www.linuxquestions.org/questions/debian-26/problems-with-apt-cdrom-add-command-866761/

Hope this helps.

-Jesse

Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion

[Brian Potkin]

tags 950690 upstream
thanks


On Tue 04 Feb 2020 at 21:42:03 +0100, Yves-Alexis Perez wrote:

> Package: cups-filters
> Version: 1.27.0-2
> Severity: important
> 
> Hi,
> 
> since “some” time (few weeks maybe, I guess the 1.27.0 upload), I can't
> print on my Brother HL-5250DN network printer (which was working just
> fine earlier).
> 
> The printer is laser monochrome, and I always was able to print color
> and monochrome stuff, conversion was happening just fine.
> 
> Now, when I try to print, nothing happens and I guess an error in the
> logs about:
> 
> W [04/Feb/2020:21:28:45 +0100] [Job 570] Grayscale/monochrome printing
> requested for this job but Poppler is not able to convert to
> grayscale/monochrome PostScript.
> W [04/Feb/2020:21:28:45 +0100] [Job 570] Use \"pdftops-renderer\" option
> (see README file) to use Ghostscript or MuPDF for the PDF -> PostScript
> conversion.
> 
> First, it's really not obvious from the log *which* README this is
> about, and I had to dig a little before finding it was the one from
> cups-filters.
> 
> Then, I tried to set pdftops-renderer-default to various options (gs,
> pdftocairo) using:
> 
> lpadmin -p printer -o pdftops-renderer-default=
> 
> but it didn't work.
> 
> With:
> 
> - gs: nothing prints, but nothing happens in the logs
> - pdftocairo: same error message than without any option
> - pdftops: same error
> 
> With mupdf it does send something to the printer but the results shows:
> 
> ERROR NAME;
>   undefined
> COMMAND;
>   °
> OPERAND STACK;
> 
> and in the logs I get:
> 
> W [04/Feb/2020:21:34:29 +0100] [Job 573] Level 3 PostScript not
> supported by mutool.
> 
> Downgrading to 1.26.2 from testing seems to fix the problem (I still
> have the log entry, though, it seems, so maybe it's unrelated).

Thank you for your report, Yves-Alexis.

Your issue seems connected with

 https://github.com/OpenPrinting/cups-filters/issues/169

and its associated bugs. I take it you are using the PostScript
PPD provided by Brother. I did test how filtering went with it
and a file or two. I got no errors, but did get the warnings you
got. Then again, I do not have the printer to print the output
file to.

I am not sure I really understand all that is involved here, so,
because you are able to provide first-hand experience, suggest
you forward the issue upstream.

Regards,

Brian.

Bug#950668: jove: [INTL:ru] Russian debconf templates translation update 2

[Yuri Kozlov]

Updated version 4.17.1.4-1.

-- 
Best Regards,
Yuri Kozlov

# translation of jove_4.16.0.70-2_ru.po to Russian
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans#
#Developers do not need to manually edit POT or PO files.
#
# Yuri Kozlov , 2006, 2020.
msgid ""
msgstr ""
"Project-Id-Version: 4.17.1.4-1\n"
"Report-Msgid-Bugs-To: j...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-04 22:52+0100\n"
"PO-Revision-Date: 2020-02-05 18:46+0300\n"
"Last-Translator: Yuri Kozlov \n"
"Language-Team: Russian \n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms:  nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

#. Type: note
#. Description
#: ../jove.templates:1001
msgid "Found old version of /etc/jove.rc. Moved it to /etc/jove/jove.rc"
msgstr "Найдена старая версия /etc/jove.rc. Переносится в /etc/jove/jove.rc"

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Old version of /etc/jove.rc and new version /etc/jove/jove.rc found"
msgstr "Найдены старая версия /etc/jove.rc и новая версия /etc/jove/jove.rc"

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Moving old version to /etc/jove/jove.rc.old"
msgstr "Старая версия переносится в /etc/jove/jove.rc.old"

#. Type: note
#. Description
#: ../jove.templates:3001
#| msgid "we found the obsolete /etc/init.d/jove script and have now"
msgid "Removed obsolete /etc/init.d/jove script"
msgstr "Удалён старый сценарий /etc/init.d/jove"

#. Type: note
#. Description
#: ../jove.templates:3001
#| msgid "removed it. check NEWS.Debian for more information."
msgid "Check NEWS.Debian for more information"
msgstr "Подробности смотрите в NEWS.Debian."

#. Type: note
#. Description
#: ../jove.templates:4001
#| msgid "we found old files in /var/lib/jove/preserve/ . You can recover"
msgid "Found old files in /var/lib/jove/preserve/"
msgstr "Найдены старые файлы в /var/lib/jove/preserve/"

#. Type: note
#. Description
#: ../jove.templates:4001
#| msgid "those by running jove -r. check NEWS.Debian for more information."
msgid ""
"You can recover those by running jove -r Check NEWS.Debian for more "
"information."
msgstr ""
"Вы можете восстановить их запуском команды jove -r. "
"Подробности смотрите в NEWS.Debian."

Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so

[Thorsten Glaser]

Dixi quod…

> A core dump would probably have been helpful… hmm… I’ll start
> it again with ulimit -c unlimited and see if I can’t get one,
> iff it dumps one _and_ I figure out where.

Today, cups-browsed simply isn’t running (according to “ps ax”),
but I don’t have a segfault in dmesg or ANYTHING about it in
syslog and can’t find a coredump either. I did:

--- /etc/init.d/cups-browsed
+++ /etc/init.d/cups-browsed
@@ … @@
 case "$1" in
   start)
 log_begin_msg "Starting $DESC: $NAME"
 
 mkdir -p `dirname "$PIDFILE"`
+ulimit -c unlimited
 start-stop-daemon --start --oknodo --background $SSD_OPTIONS --exec 
$DAEMON
 log_end_msg $?
 ;;

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#950741: dosen't work with postgresql 12

[Kunz David]

Package: resource-agents-paf
Version:  2.2.1-1
Severity: important

Hallo

Thank you, for maintaining resource-agents-paf.
We use postgresql 12 and can't use paf.
Can you update this package on 2.3~rc1, that
we can use it.

Greetings,
David

Bug#950742: thrift: Fails to build against ruby2.7

[Lucas Kanashiro]

Source: thrift
Version: 0.13.0-2
Severity: important
Usertags: ruby2.7-transition

Dear Maintainer,

We are planning to start the ruby2.7 transition and your package failed
to build against ruby2.7. Check the full build log here:

https://people.debian.org/~kanashiro/ruby2.7/builds/7/thrift/thrift_0.13.0-2+rebuild1580886977_amd64.build

For now, to reproduce the failure locally you need:

* experimental enabled
* ruby-all-dev binary package from experimental (>= 1:2.5.7~0)

For instance, you can use use the following sbuild command:

$ sbuild -d unstable --build-dep-resolver=aptitude
--extra-repository="deb http://deb.debian.org/debian experimental main"
--starting-build-commands="apt install -y ruby-all-dev/experimental"
--source-only-changes

ruby2.7 should be enabled as the default ruby soon in unstable.

-- 
Lucas Kanashiro




signature.asc
Description: OpenPGP digital signature

Bug#943423: troubles generating refman.pdf

[Gordon, Craig A. (GSFC-660.1)[INNOVIM]]

Hi Paolo,

It was never intended for end users to have to generate the CCfits manual 
themselves (nor is it intended to be compatible with all versions of Doxygen).  
That's why CCfits-2.5.pdf is included with the stand-alone distribution.  Is 
there a special reason you're trying to run "make docs"?  Because otherwise I 
wouldn't recommend doing that.

-Craig


From: Paolo Greppi 
Sent: Wednesday, February 5, 2020 6:34 AM
To: ccf...@heasarc.gsfc.nasa.gov 
Cc: 943...@bugs.debian.org <943...@bugs.debian.org>
Subject: troubles generating refman.pdf

Hi,

CCfits fails to generate refman.pdf on Debian unstable with doxygen 1.8.16 and 
pdflatex from texlive-latex-base 2019.20191208.

To reproduce:

  wget https://heasarc.gsfc.nasa.gov/fitsio/CCfits/CCfits-2.5.tar.gz
  tar xf CCfits-2.5.tar.gz
  cd CCfits/
  ./configure
  make docs
  make -C latex

output:

  make: *** [Makefile:8: refman.pdf] Error 1

I attach refman.log

For more background: https://bugs.debian.org/943423

Thanks !

Paolo

Bug#950740: RM: ruby-memfs -- ROM; unmaintained, no reverse dependencies

[Sebastien Badia]

Package: ftp.debian.org
Severity: normal

This package was introduced in Debian because it was a B-D of ruby-simple-
navigation https://bugs.debian.org/816662
But ruby-simple-navigation is now removed from the archive…
https://bugs.debian.org/918541

Bug#942055: ghostscript in buster partly broken on armel?

[Jonas Smedegaard]

[ sent again to please Debian MTAs rejecting 8bit headers ]

control: tag -1 wontfix

Quoting Bernhard Übelacker (2020-02-04 20:13:41)
> Control: fixed -1 9.26a~dfsg-0+deb9u6
> Control: fixed -1 9.26a~dfsg-0+deb9u1
> Control: fixed -1 9.25~dfsg-0+deb9u1
> Control: found -1 9.27~dfsg-3.1
> Control: found -1 9.27~dfsg-3
> Control: found -1 9.26a~dfsg-2
> Control: found -1 9.26a~dfsg-1
> Control: found -1 9.26~dfsg-2
> Control: found -1 9.26~dfsg-1
> Control: found -1 9.25~dfsg-7
> Control: found -1 9.25~dfsg-2
> Control: found -1 9.24~~rc2~dfsg-1
> Control: fixed -1 9.22~dfsg-1
> Control: fixed -1 9.21~dfsg-1
> Control: fixed -1 9.20~dfsg-3.2
> 
> 
> Hello,
> tried to get a little further.
> 
> The last version from sid that did not show this error
> was 9.22~dfsg-1. All other good version seem to be created
> as security updates, where I cannot find the build logs.

Most notable change between 9.22 and 9.24 - and also applied to various 
degree in security updates - was a security fix affecting interpretation 
of Postscript code.

Yes, it broke existing working code, but (as I 
understand it) only existing _insecurely_ working code.

The change is highly unlikely to get reverted: Instead, reverse 
dependencies of Ghostscript need to apply fixes to tighten their code to 
avoid those Postscript routines identified as being insecure and 
therefore no longer permitted (or if certain that security is ensured in 
other ways then explicitly disable the safety measures).

Please do not reassign these bugs to Ghostscript, even though provable 
that they are "fixed" by downgrading Ghostscript.  The fix needs to be 
applied at the consumer end.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#942055: ghostscript in buster partly broken on armel?

[Jonas Smedegaard]

control: reassign -1 ghostscript
Control: fixed -1 9.26a~dfsg-0+deb9u6
Control: fixed -1 9.26a~dfsg-0+deb9u1
Control: fixed -1 9.25~dfsg-0+deb9u1
Control: found -1 9.27~dfsg-3.1
Control: found -1 9.27~dfsg-3
control: found -1 9.27~dfsg-2+deb10u3
control: found -1 9.27~dfsg-2+deb10u1
Control: found -1 9.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
control: fixed -1 9.26a~dfsg-0+deb9u5
Control: found -1 9.26~dfsg-2
Control: found -1 9.26~dfsg-1
Control: found -1 9.25~dfsg-7
Control: found -1 9.25~dfsg-2
Control: found -1 9.24~~rc2~dfsg-1
Control: fixed -1 9.22~dfsg-1
Control: fixed -1 9.21~dfsg-1
Control: fixed -1 9.20~dfsg-3.2

[ sent again to please Debian MTAs rejecting 8bit headers ]

Hi Bernhard,

Quoting Bernhard Übelacker (2020-02-05 15:06:02)
> Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> > Hi Alexander,
> > 
> > Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
> >> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
> >>
> >>> Most notable change between 9.22 and 9.24 - and also applied to 
> >>> various degree in security updates - was a security fix affecting 
> >>> interpretation of Postscript code.
> >>
> >> Maybe a stupid question, but does that fix work?  I'm just wondering, 
> >> if the firx triggers a problem on one arm but not on amd64, is it 
> >> working?
> > 
> > Fair question.
> > 
> > Ghostscript is (mainly) a Postscript interpreter.
> > 
> > To investigate if the cause for this issue is a) Ghostscript 
> > _interpreting_ differently on arm than on amd64, or a tool further back 
> > in the chain _producing_ different code for Ghostscript to interpret, it 
> > seems to me that we need someone to isolate the actual code fed into 
> > Ghostscript.
> >
> > I maintain the Ghostscript package, but am not skilled in the various 
> > tools using Ghostscript.  It seems more sensible to me to first 
> > investigate toolchain problems further back in the chain, where (I 
> > assume) it is better known how to isolate the data forwarded down the 
> > chain.
> 
> 
> I guess this is what I did in previous message 33 ?

Ohh, indeed!  Great details and smells strongly of the bug being in 
Ghostscript.  I am hereby re-re-re-assigning and reviving versions...

(weird - I received your later emails fine but that one crucial message 
is not in by mailsystem - I must've simply hit the wrong key when 
processing it, sorry!)


> There I attached file foomatic-9RyCd0 which is fed by cups into 
> ghostscript.

Yes, got it. Thanks!


> I have put the ghostscript command line parameter also in message 33.

Yes. Got it.  Will try on an armel box I got...

> I continued testing and a package "9.25~dfsg-7" compiled in an 
> unstable chroot as of date 2017-12-07 produces a working package. But 
> a package "9.25~dfsg-7" built inside a unstable chroot as of date 
> 2018-01-01 crashes in gx_filter_edgebuffer, like current version in 
> buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set.
> 
> Therefore I guess this could be related to the switch from gcc-7 
> 7.2.0-16 to gcc-7 7.2.0-18 in that time frame. (The -18 raised the 
> baseline to armv5te.) That would at least explain why the stretch 
> stable update packages do not show the problem (e.g. 
> 9.26a~dfsg-0+deb9u6), as they should be built with stretch's gcc-6.
> 
> But without pointing to an exact instruction or function I cannot 
> prove it. So are there any hints how to further debug ghostscript in 
> that regard?

Might be helpful if you could provide the stdout and stderr outputs of 
_only_ running the Ghostscript command - executed on amd64 and armel for 
easy comparison.

Also might be helpful to do the same passing additional option 
-dTTFDEBUG (as that seems to show more detail in the aread where it 
seems to fail).

...or if some of above is already covered in your previously provided 
debugging.txt then if you could help point exactly where...

I say "might" above because really this is more geeky than I can handle 
myself, so I am just guessing what upstream might find helpful - in 
other words: it would be even more helpful if (above more narrow test 
still fails then) you would file this directly as a bugreport upstream 
at https://bugs.ghostscript.com/ as it sounds like you would be better 
at guiding them than I am.


Kind regards, and sorry for missing that crucial previous post,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#950739: xapian-bindings: Fails to build against ruby2.7

[Lucas Kanashiro]

Source: xapian-bindings
Version: 1.4.12-3
Severity: important

Dear Maintainer,

We are planning to start the ruby2.7 transition and your package failed
to build against ruby2.7. Check the full build log here:

https://people.debian.org/~kanashiro/ruby2.7/builds/5/xapian-bindings/xapian-bindings_1.4.12-3+rebuild1580867044_amd64-2020-02-05T01:44:06Z.build

For now, to reproduce the failure locally you need:

* experimental enabled
* ruby-all-dev binary package from experimental (>= 1:2.5.7~0)

For instance, you can use use the following sbuild command:

$ sbuild -d unstable --build-dep-resolver=aptitude
--extra-repository="deb http://deb.debian.org/debian experimental main"
--starting-build-commands="apt install -y ruby-all-dev/experimental"
--source-only-changes

ruby2.7 should be enabled as the default ruby soon in unstable.

-- 
Lucas Kanashiro




signature.asc
Description: OpenPGP digital signature

Bug#950716: transition: ruby2.7

[Lucas Kanashiro]

On Wed, 5 Feb 2020 07:47:30 -0300 Lucas Kanashiro 
wrote:
> Building against ruby2.7 has been enabled in experimental, and we
> already did a test rebuild against it, with pretty good results:
> https://people.debian.org/~kanashiro/ruby2.7/builds/


Sorry for the confusion above, this is the correct url:

https://people.debian.org/~kanashiro/ruby2.7/builds/

> Ben file:
>
> title = "ruby2.7";
> architectures = ["amd64"];
> is_affected = .depends ~ /ruby2.5/ | .depends ~ /ruby2.7/;
> is_good = .depends ~ /ruby2.7/;
> is_bad = .depends ~ /ruby2.5/ & !.depends ~ /ruby2.7/;

And the Ben file would be this:

title = "ruby2.7";
is_affected = .depends ~ /ruby2.5/ | .depends ~ /ruby2.7/;
is_good = .depends ~ /ruby2.7/;
is_bad = .depends ~ /ruby2.5/ & !.depends ~ /ruby2.7/;

-- 
Lucas Kanashiro




signature.asc
Description: OpenPGP digital signature