Bug#941855: dunst: Daily systemd errors: "Failed to start Dunst notification daemon."

[Nikos Tsipinakis]

Hi,

This is usually caused by not having exported the DISPLAY variable into the
systemd environment, there has been extensive discussion about this in #347[1]
upstream.
How are you starting X11, are you using a custom xinitrc?

However it is weird that systemd reports that dunst is running even though it
obviously fails to start. I'm not sure what is going on there.

[1] https://github.com/dunst-project/dunst/issues/347

Bug#942199: rollup 1.0 transition: node-rollup-plugin-babel fails to build with Error: You must supply options.input to rollup

[Pirate Praveen]

package: node-rollup-plugin-babel
version: 3.0.3-3
severity: important

With rollup 1.0.2-1 in experimental, we get this error when building,

Found debian/nodejs/./build
cd ./. && sh -e debian/nodejs/./build
(!) You have passed an unrecognized option
Unknown input option: entry, targets, sourceMap. Allowed options: 
acorn, acornInjectPlugins, cache, chunkGroupingSize, context, 
experimentalCacheExpiry, experimentalOptimizeChunks, 
experimentalTopLevelAwait, external, inlineDynamicImports, input, 
manualChunks, moduleContext, onwarn, perf, plugins, preserveModules, 
preserveSymlinks, shimMissingExports, treeshake, watch


undefined → stdout...
[!] Error: You must supply options.input to rollup
Error: You must supply options.input to rollup
   at new Graph (/usr/share/nodejs/rollup/src/Graph.js:90:19)
   at Object.rollup 
(/usr/share/nodejs/rollup/src/rollup/index.js:129:23)
   at Object.build [as default] 
(/usr/share/nodejs/rollup/bin/src/run/build.js:41:10)

   at /usr/share/nodejs/rollup/bin/src/run/index.js:117:39
   at process._tickCallback (internal/process/next_tick.js:68:7)
   at Function.Module.runMain (internal/modules/cjs/loader.js:834:11)
   at startup (internal/bootstrap/node.js:283:19)
   at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

Please fix the error so we can upload rollup 1.0 to unstable.

Bug#875065: [odin] Future Qt4 removal from Buster -> odin is ready for Qt5

[Andreas Tille]

I can do so not before November 4th, Andreas.

On Fri, Oct 11, 2019 at 11:08:02PM +0200, Moritz Mühlenhoff wrote:
> On Wed, Jan 23, 2019 at 09:46:28AM +0100, thies wrote:
> > Dear all,
> > 
> > odin should compile on Buster without changes using the packages qt5-default
> > and libqwt-qt5-dev.
> 
> This bug hasn't seen any maintainer followup since two years, are the 
> maintainers
> planning to make this change?
> 
> We're now moving forward with the Qt4 removal, if there no immediate plans to
> switch port odin to Qt5, we'll request to remove it from the archive.
> 
> Cheers,
> Moritz
> 

-- 
http://fam-tille.de

Bug#942198: libp8-platform-dev: drop dependency on g++

[Helmut Grohne]

Package: libp8-platform-dev
Version: 2.1.0.1+dfsg1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:kodi src:kodi-pvr-argustv src:kodi-pvr-dvbviewer 
src:kodi-pvr-hdhomerun src:kodi-pvr-hts src:kodi-pvr-iptvsimple 
src:kodi-pvr-mediaportal-tvserver src:kodi-pvr-mythtv src:kodi-pvr-nextpvr 
src:kodi-pvr-njoy src:kodi-pvr-vdr-vnsi src:kodi-pvr-vuplus src:kodi-pvr-wmc

libp8-platform-dev gained a dependency on g++ to facilitate the GCC5
transition. Unfortunately, this dependency now breaks cross compilation.
We'd like to use translated tools (aka g++-for-host) here, but work is
not finished in unstable yet. Given that the transition is long over, I
suggest simply dropping the dependency. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru p8-platform-2.1.0.1+dfsg1/debian/changelog 
p8-platform-2.1.0.1+dfsg1/debian/changelog
--- p8-platform-2.1.0.1+dfsg1/debian/changelog  2018-07-29 06:13:31.0 
+0200
+++ p8-platform-2.1.0.1+dfsg1/debian/changelog  2019-10-12 07:57:01.0 
+0200
@@ -1,3 +1,10 @@
+p8-platform (2.1.0.1+dfsg1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the g++ dependency added for the GCC5 transition. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 12 Oct 2019 07:57:01 +0200
+
 p8-platform (2.1.0.1+dfsg1-2) unstable; urgency=medium
 
   * Update symbols to build with GCC8 (Closes: #897831)
diff --minimal -Nru p8-platform-2.1.0.1+dfsg1/debian/control 
p8-platform-2.1.0.1+dfsg1/debian/control
--- p8-platform-2.1.0.1+dfsg1/debian/control2018-07-29 06:13:31.0 
+0200
+++ p8-platform-2.1.0.1+dfsg1/debian/control2019-10-12 07:56:58.0 
+0200
@@ -17,7 +17,6 @@
 Depends: libp8-platform2 (= ${binary:Version}),
  ${misc:Depends},
  libfstrcmp-dev,
- g++ (>= 4:5.2)
 Provides: libp8-platform-dev
 Description: Pulse-Eight's platform support library -- development files
  Platform support library of Pulse-Eight. It includes C++ wrappers for

Bug#885212: Somebody plans to work on this?

[Pietro Battiston]

Dear Debian Science Maintainers,

are there plans to fix this, or should we worry?

(I ask because I am the maintainer of gbutils which is set for
autoremoval in 9 days due to this)

Thanks,

Pietro

Bug#942197: gbp-import-orig: Please add an option to add the closed bug(s) when importing new upstream version

[Laurent Bigonville]

Package: git-buildpackage
Version: 0.9.15
Severity: wishlist

Would be nice to have an option to be able to add a Closes statement to
the commit message when importing a new upstream version

That would allow people using gbp dch to have a bug requesting for a new
upstream version properly closed.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages git-buildpackage depends on:
ii  devscripts 2.19.6
ii  git1:2.23.0-1
ii  man-db 2.8.7-3
ii  python33.7.5-1
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  41.2.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  pbuilder  0.230.4
ii  pristine-tar  1.46
ii  python3-requests  2.21.0-1
ii  sbuild0.78.1-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.27-1+b1
ii  unzip6.0-25

-- no debconf information

Bug#942196: alsa-lib FTCBFS: missing Build-Depends: libpython3-dev

[Helmut Grohne]

Source: alsa-lib
Version: 1.1.8-2
Severity: important
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

alsa-lib fails to cross build from source, because it misses a required
dependency on libpython3-dev. Without this dependency, presence of
development headers for the host architecture is not ensured and the
build fails:

| libtool: compile:  aarch64-linux-gnu-gcc -DHAVE_CONFIG_H -I. 
-I../../../include -I../../../include -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/python3.7m -I/usr/include/python3.7m -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c python.c  -fPIC -DPIC -o 
.libs/smixer_python_la-python.o
| In file included from /usr/include/python3.7m/Python.h:8,
|  from python.c:22:
| /usr/include/python3.7m/pyconfig.h:9:12: fatal error: 
aarch64-linux-gnu/python3.7m/pyconfig.h: No such file or directory
| 9 | #  include 
|   |^
| compilation terminated.

Please consider applying the attached patch. Properly, this time. It was
correct in my previous patch.

Helmut
diff --minimal -Nru alsa-lib-1.1.8/debian/changelog 
alsa-lib-1.1.8/debian/changelog
--- alsa-lib-1.1.8/debian/changelog 2019-10-11 12:44:01.0 +0200
+++ alsa-lib-1.1.8/debian/changelog 2019-10-12 07:39:57.0 +0200
@@ -1,3 +1,10 @@
+alsa-lib (1.1.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: libpython3-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 12 Oct 2019 07:39:57 +0200
+
 alsa-lib (1.1.8-2) unstable; urgency=medium
 
   * Get rid of old, unused patches.
diff --minimal -Nru alsa-lib-1.1.8/debian/control alsa-lib-1.1.8/debian/control
--- alsa-lib-1.1.8/debian/control   2019-10-11 12:43:25.0 +0200
+++ alsa-lib-1.1.8/debian/control   2019-10-12 07:39:56.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Jordi Mallach ,
Elimar Riesebieter ,
Luke Yelavich 
-Build-Depends: debhelper (>= 11), python3-dev:native
+Build-Depends: debhelper (>= 11), python3-dev:native, libpython3-dev
 Build-Depends-Indep: doxygen, graphviz
 Standards-Version: 4.3.0
 Homepage: https://www.alsa-project.org/

Bug#942195: zh_CN.po: Fix a wrong character

[Mo Zhou]

Package: dpkg
Version: 1.19.7

I made a typo when doing the translation.

diff --git a/po/zh_CN.po b/po/zh_CN.po
index 947944ea0..c4f9c5fc5 100644
--- a/po/zh_CN.po
+++ b/po/zh_CN.po
@@ -6084,7 +6084,7 @@ msgstr "重复路径 %s"
 msgid ""
 "alternative %s (part of link group %s) doesn't exist; removing from
list of "
 "alternatives"
-msgstr "侯选项 %s(链接组 %s 的一部分)不存在；从候选项列表中移除。"
+msgstr "候选项 %s(链接组 %s 的一部分)不存在；从候选项列表中移除。"
 
 #: utils/update-alternatives.c
 msgid "priority"

Bug#940571: dpkg-buildflags should support an optimization area for things like lto and pgo

[Guillem Jover]

On Thu, 2019-10-10 at 10:39:23 +0200, Matthias Klose wrote:
> On 09.10.19 20:28, Guillem Jover wrote:
> > I take you are requesting both adding this and also enabling LTO by
> > default?
> 
> the infrastructure should provide both, having the option to enable it by a
> flag when it's not the default, and to disable it by default, when it's
> enabled by default.

This is something provided for all supported features, but this does
not answer whether you are requesting this to be the default or not.

Or is your plan to enable this by default in gcc instead of via flags
passed by dpkg-buildflags?

> > I'm fine with the former (even implementing that myself), but the latter
> > would need to go through [Q] first. And I see this can cause breakage [O]
> > according to the OpenSUSE people.
> > 
> > [Q] 
> > 
> > [O] 
> > 
> 
> well, yes, it breaks a few packages, more than a handful, but not the whole
> archive, and you can name these packages.  The question for now is how to
> name that option, and how to disable that on a per package basis. And we
> probably want to enable that for a subset of architectures first, which have
> been test built.  So the first thing is the name, so people can disable lto,
> before we even consider making it the default.

If you are suggesting repeating the same disaster that we have with
pie, with the default set by gcc being arch opt-in, then I'm honestly
less than interested in doing the same here, and I'd consider this a
direct wontfix. :/

> > > pgo doesn't directly translate into compiler flags, but almost always
> > > requires upstream support in the build system.  pgo usually is enabled by
> > > some configure options which are specific to the upstream build.  pgo
> > > usually requires running a profiling task, so this optimization probably
> > > should be disabled for cross builds, otoh, the cross build then is 
> > > different
> > > to the native build (although it should create a functional identical
> > > package).
> > 
> > I don't see how dpkg can support PGO, so I'm excluding that from this
> > request, as it seems this would be pretty much unactionable.
> 
> The only thing it would do is to provide a common interface to
> enable/disable it, not an implementation.

Ok, I guess, given that using unknown features for known areas emits
warnings (even though it seems weird and unexpected to support a feature
for which dpkg-buildflags will never be able to emit flags for, and some
other name could be used for this, but consistency would be nice).

Regards,
Guillem

Bug#942111: dpkg,debhelper: please set HOME, XDG_* to a temporary location during the build

[Guillem Jover]

Control: reassign -1 dpkg-dev,debhelper

Hi!

On Thu, 2019-10-10 at 14:58:11 +0100, Simon McVittie wrote:
> Package: dpkg,debhelper
> Severity: wishlist

> I'm reporting this feature request against both dpkg and debhelper because
> I don't yet know whether it's feasible to implement in debhelper, and
> if it's feasible in both places, I don't know which location is where
> it *should* be implemented.

> Problem statement
> -
> 
> Debian Policy §4.9 requires the build process of a package (defined in
> terms of the "required targets" in d/rules) to limit its write accesses
> to one of a few allowed locations:
> 
> - the unpacked source package being built
> - /tmp
> - /var/tmp
> - $TMPDIR
> - (https://bugs.debian.org/942051 points out that some other locations
>   like /dev/shm should also be allowed)

(BTW, I think some of the other locations presented are due to a very
strict interpretation of the wording, which do not follow the spirit
of the requirement.)

> Pasting similar setup code into increasingly many packages as their
> Policy violations are discovered does not seem like an ideal solution
> when the problem could be solved centrally instead: instead of fighting
> against these packages, we could relax the requirement to allow use of
> $HOME, while ensuring that $HOME is set to a clean per-build directory.

Indeed.

> Proposed solution
> -
> 
> Either dpkg-buildpackage should:
> 
> - create a fake home directory, perhaps debian/.temp-home/home, and set
>   $HOME to point to it
> - create a fake XDG_RUNTIME_DIR, perhaps debian/.temp-home/run, and set
>   $XDG_RUNTIME_DIR to point to it
> - delete those directories during cleaning
> - either unset the other XDG_* so that their hard-coded defaults are used,
>   or set them to known-good values, using the fake $HOME where applicable:
>   - XDG_CACHE_HOME: $HOME/.cache or unset
>   - XDG_CONFIG_HOME: $HOME/.config or unset
>   - XDG_CONFIG_DIRS: /etc/xdg or unset
>   - XDG_DATA_HOME: $HOME/.local/share or unset
>   - XDG_DATA_DIRS: /usr/local/share:/usr/share or /usr/share or unset

Right, there are a few problems with this though. The first is the
directory use, which might stomp over local packaging stuff. Then the
cleanup, which needs to be delegated to debian/rules, although I've
discussed with Niels to add a new dpkg-buildclean command or similar.

I've got a pending proposal to solve problems such as this, but I've
found no motivation the last several months to bring this up on
debian-devel. I'll try to find some, and sent it, but meh. The draft
is at:

  

The other main problem is yet again with dpkg-buildpackage not being
(still) the main and only canonical interface to build packages, so
debian/rules must keep working as before, per policy w/o externally
defined variables. :/

> or dh should do all of those in dh(1), and optionally in other dh_*
> commands for the benefit of packages that do not use dh.

As it is now, while I think that would be just suboptimal, and would
not cover non-dh debhelper packaging, that might be better than
nothing. :/

> Limitations of proposed solution
> 
> 
> If a package is built in an unclean environment that includes
> variables other than those that are reset explicitly (for example with
> PYTHONPATH=$HOME/.local/lib/python3), it will continue to read and/or
> write the home directory. (Solved by using debuild or sbuild.)

Cleansing the environment is something that dpkg-buildpackage should
be doing too, but given the current interface requirements (of
debian/rules being the official entry point), doing this by default in
dpkg-buildpackage would induce breakage when maintainers start assuming
the new environment.

> If this is solved in dpkg-buildpackage, and a package is built by invoking
> debian/rules directly, it might bypass this solution. (Solved by using
> dpkg-buildpackage, or anything that wraps it, like debuild or sbuild.)

Yeah, which might mean unexpected/broken behavior.

> If the user specifically *wants* to write outside the build directory,
> for example because they are using ccache with cached files in the
> default ~/.ccache, it will no longer be sufficient to run "debuild
> -ePATH=/usr/lib/ccache:$PATH"; the user will now also have to pass in
> an explicit CCACHE_DIR. (Mitigation: they already need to do this for
> increasingly many packages that have solved this problem locally, like
> glib2.0.)

Right, if the default got to switch to a cleansed environment, I don't
see a problem with people having to adapt to that.

> Where do the dpkg and debhelper maintainers think this ought to be solved?

IMO this should be done centrally in dpkg-buildpackage, but only if
that's the only supported entry point for building packages. As long as
the entry point is still debian/rules, unfortunately I think we need to
make do with possibly inferior solutions, which less coverage or more

Bug#942087: dpkg-source and dpkg-genchanges disagree how .dsc should be named if version ends with +b1

[Guillem Jover]

On Thu, 2019-10-10 at 09:44:21 +0200, Ansgar wrote:
> Guillem Jover writes:
> > On Thu, 2019-10-10 at 08:15:07 +0200, Ansgar wrote:
> >> With the first binNMU the changelog used 5.2.17+1+b1 as the version
> >> and this caused disagreement between different parts of dpkg.
> >> dpkg-source generates linux-signed-amd64_5.2.17+1+b1.dsc, but
> >> dpkg-genchanges strips the trailing +b1 from the version:
> [...]
> >> I'll suggest to work around this by mangling the version a bit more
> >> and use .b1 instead of +b1, but the disagreement seems to be a bug in
> >> dpkg.
> >
> > It looks to me that the problem might actually be the missing
> > binary-only=yes key/value in the changelog header though, which the
> > original should have? Could you check whether that would completely
> > fix this?
> 
> It should generate a new *source* package, it is not binary-only.
> dpkg-source does do so.

Why should it generate a new source? This is using the version suffix
for binNMUs, using this convention for something that is not a binNMU
seems just wrong.

> But dpkg-genchanges seems to (still) use the heuristic stripping the +bX
> from versions instead of using the binary-only key (which is not present
> here).
> 
> I think either:
> 
>  - dpkg-source should refuse to generate source packages using
>binNMU version numbers (that trigger the heuristic that other parts
>of dpkg use), or

This would still point at a problem with the version used. I'd rather
stop using the heuristic because we have metadata for this, and they
are Debian-centric things. But if the alernative is to allow packages
that break the versioning convention for no apparent good reason, then
I guess I might need to move this as a vendor-specific logic, and apply
it everywhere. :/

>  - dpkg-genchanges should be able to generate changes files for source
>packages that use versions ending in +bX (provided no binary-only is
>set); i.e. stop using heuristics and instead rely on the binary-only
>key.

Same as the previous point.

Thanks,
Guillem

Bug#942194: inxi: Make inxi automatically try to call sudo on some commands (dmidecode) when run as normal user

[contact smxi]

This should not be cluttering up Debian's bug tracker, this is not a bug, it's just a feature 
request, and it does zero good to file stuff like that on Debian's bug tracker (except that I 
happened to see it since I'm subscribed to inxi issues on Debian's bug tracker), file it on the inxi 
project github page as an issue, and close this Debian report since it's not a bug. Don't engage in 
further discussion on this email thread, if you want an issue like this looked at, report it to inxi 
on github.


I won't respond any further on this on this here since it's not a proper use of 
Debian's bug tracker.

Once you post the issue in the proper place I'll take a look at it. Apologies to the maintainer of 
the package.


thanks,

Harald Hope, inxi.

On 10/11/19 7:54 PM, Witold Baryluk wrote:

Package: inxi
Version: 3.0.36-1-1
Severity: wishlist

It is kind of a wishlist, but can be also considered a bug.

When running inxi, and asking for memory details (-m), it can't show all
details (like memory clocks, timings, ECC-ness), as it requires
dmidecode, which requires a root.

However, running full inxi with sudo, or under root, can influence other things,
most notably graphics stack settings, like Mesa details, if the user installed
custom mesa with custom LD_LIBRARY_PATH & co.

A solution would be to call inxi as normal without sudo, and ask inxi to
call sudo on necassary commands if needed. The new behaviour would be
controlled by switch only, and the current behaviour would be preserved.
This way it will work on systems without sudo or with sudo configured
in a way that requires extra authentication.




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

Kernel: Linux 5.2.0-3-amd64 (SMP w/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 inxi depends on:
ii  pciutils  1:3.6.2-2
ii  perl  5.30.0-6
ii  procps2:3.3.15-2+b1

Versions of packages inxi recommends:
ii  dmidecode  3.2-2
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+b1
ii  file   1:5.37-5
ii  hddtemp0.3-beta15-53
ii  iproute2   5.3.0-1
ii  kmod   26-3
ii  lm-sensors 1:3.5.0-3
ii  mesa-utils 8.4.0-1+b1
ii  net-tools  1.60+git20180626.aebd88e-1
ii  sudo   1.8.27-1+b1
ii  tree   1.8.0-1+b1
ii  usbutils   1:012-2
ii  x11-utils  7.7+4
ii  x11-xserver-utils  7.7+8

Versions of packages inxi suggests:
ii  curl  7.66.0-1
ii  libcpanel-json-xs-perl4.12-1+b1
ii  libjson-xs-perl   4.020-1+b1
ii  libxml-dumper-perl0.81-1.2
ii  perl [libhttp-tiny-perl]  5.30.0-6
ii  wget  1.20.3-1+b1

-- no debconf information

Bug#942194: inxi: Make inxi automatically try to call sudo on some commands (dmidecode) when run as normal user

[Witold Baryluk]

Package: inxi
Version: 3.0.36-1-1
Severity: wishlist

It is kind of a wishlist, but can be also considered a bug.

When running inxi, and asking for memory details (-m), it can't show all
details (like memory clocks, timings, ECC-ness), as it requires
dmidecode, which requires a root.

However, running full inxi with sudo, or under root, can influence other things,
most notably graphics stack settings, like Mesa details, if the user installed
custom mesa with custom LD_LIBRARY_PATH & co.

A solution would be to call inxi as normal without sudo, and ask inxi to
call sudo on necassary commands if needed. The new behaviour would be
controlled by switch only, and the current behaviour would be preserved.
This way it will work on systems without sudo or with sudo configured
in a way that requires extra authentication.




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

Kernel: Linux 5.2.0-3-amd64 (SMP w/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 inxi depends on:
ii  pciutils  1:3.6.2-2
ii  perl  5.30.0-6
ii  procps2:3.3.15-2+b1

Versions of packages inxi recommends:
ii  dmidecode  3.2-2
ii  dnsutils   1:9.11.5.P4+dfsg-5.1+b1
ii  file   1:5.37-5
ii  hddtemp0.3-beta15-53
ii  iproute2   5.3.0-1
ii  kmod   26-3
ii  lm-sensors 1:3.5.0-3
ii  mesa-utils 8.4.0-1+b1
ii  net-tools  1.60+git20180626.aebd88e-1
ii  sudo   1.8.27-1+b1
ii  tree   1.8.0-1+b1
ii  usbutils   1:012-2
ii  x11-utils  7.7+4
ii  x11-xserver-utils  7.7+8

Versions of packages inxi suggests:
ii  curl  7.66.0-1
ii  libcpanel-json-xs-perl4.12-1+b1
ii  libjson-xs-perl   4.020-1+b1
ii  libxml-dumper-perl0.81-1.2
ii  perl [libhttp-tiny-perl]  5.30.0-6
ii  wget  1.20.3-1+b1

-- no debconf information

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value

[Kurt Kremitzki]

Just as an addendum, I just tested the build with sbuild in a dirty 
unstable-i386 schroot where I had installed dwz 0.12-3 from stable, and 
the build succeeds, where it fails with 0.13-1.

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed.

[Kurt Kremitzki]

Package: dwz
Version: 0.12-3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

I'm not certain if critical is the correct severity, but it seems dwz is
causing a build regression in freecad. As part of Python 3 removal, I
dropped the Python 2 build and packages in a new upload This should
have  been uneventful, but somehow, the builds for i386, mipsel, and
s390x are all failing with essentially the same error, as follows:

```
make[1]: Leaving directory '/<>'
   dh_dwz -a -O--buildsystem=cmake
dwz: /build/dwz-aS1MPf/dwz-0.13/dwz.c:9310: write_die: Assertion `value && 
refdcu->cu_kind != CU_ALT' failed.
dh_dwz: dwz 
-mdebian/libfreecad-python3-0.18/usr/lib/debug/.dwz/i386-linux-gnu/libfreecad-python3-0.18.debug
 -M/usr/lib/debug/.dwz/i386-linux-gnu/libfreecad-python3-0.18.debug -- 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/DraftUtils.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Drawing.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/DrawingGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Fem.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FemGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FreeCAD.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FreeCADGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Image.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ImageGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Import.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ImportGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Inspection.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/InspectionGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Measure.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Mesh.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshPart.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshPartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Part.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PartDesignGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Path.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PathGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PathSimulator.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Points.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PointsGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/QtUnitGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Raytracing.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/RaytracingGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ReverseEngineering.so
 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ReverseEngineeringGui.so
 debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Robot.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/RobotGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Sketcher.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SketcherGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Spreadsheet.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SpreadsheetGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Start.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/StartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Surface.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SurfaceGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/TechDraw.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/TechDrawGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Web.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/WebGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/_PartDesign.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/area.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriver.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverDAT.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverSTL.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverUNV.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADApp.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADBase.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libMEFISTO2.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libSMDS.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libSMESH.so 
debian/libfre

Bug#942003: libcln-dev: remove unneeded dependencies

[Richard B. Kreckel]

On 08.10.19 23:35, Pino Toscano wrote:
> libcln-dev depends on some packages which are not strictly needed as
> such:
> - g++: even though cln is a C++ library, usually -dev packages with
>   includes do not require a certain compiler, which is chosen by the
>   user

In theory, it should depend on c++-compiler, which is also provided by
clang, for instance. But since that is not the practice in other C++
libs either, I'm not going to discuss this.  => agreed.

> - libc6-dev | libc-dev: as above, usually -dev packages do not require
>   the standard C library headers, as they are provided by the libc

Sure, agreed.

> - install-info: for few years install-info has been shipping a dpkg
>   trigger to automatically run update-info-dir

Sure, agreed.

Thanks for the patch. I'll apply it and upload these days.

   -richy.

Bug#935621: Bug935621: openstack-dashboard: incompatible with django 2.2

[Thomas Goirand]

On 10/11/19 7:42 PM, Boyuan Yang wrote:
> Hi zigo, Michael,
> 
> On Wed, 9 Oct 2019 18:02:16 +0200 Thomas Goirand  wrote:
>> Hi,
>>
>> This was fixed with the last upload of Horizon.
> 
> Unfortunately the last upload was not a source-only upload. As a result, the
> fixed version will never migrate to testing.
> 
> Could you please make another source-only upload as described in 
> https://wiki.debian.org/SourceOnlyUpload at your convenience?
> 
> Thanks,
> Boyuan Ynag

It looks like Michal didn't know. I've re-uploaded source-only.

Cheers,

Thomas Goirand (zigo)

Bug#941901: buster-pu: package octavia/3.0.0-3, fix for CVE-2019-17134

[Thomas Goirand]

On 10/7/19 2:35 PM, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> Since Buster was frozen, I worked quite a long time on Octavia, and was
> able to make the octavia-agent work properly, as well as building an
> Octavia base image using Debian only stuff [1]. It works super well
> using the next version of OpenStack, ie: Stein, while Buster has Rocky.
> 
> Though I'd like to be able to provide a working Amphorae image using
> only stuff from Buster, if possible. This is what this update is about.
> The update contains:
> 
> - Fix for the vrrp script template.
> - Fix for detecting the OS from within Octavia itself.
> - Fix for CVE-2019-17134, where the Amphora didn't enforce cert checking.
> - Fix for the octavia-agent package init / systemd scripts.

Kindly ping? It'd nice if we could get this done... :)

Thomas

Bug#941093: ping!

[Lisandro Damián Nicanor Pérez Meyer]

Hi Paul!


El vie., 11 oct. 2019 17:00, Paul Gevers  escribió:

> Hi Lisandro,
>
> [Please provide more context in your replies to bugs, it really annoying
> to have to look up a bug just to figure the context out. A
> "qtbase-opensource-src transition" anywhere in your e-mail subject or
> body would have fixed that].
>

Sorry for that, I'm starting to use neomutt and I have been screwing some
mails lately.



> On 04-10-2019 20:18, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Gentle ping for this one. Maxy just told me it is blocking a KDE update
> in
> > unstable too.
>
> We're currently having a perl transition ongoing and I already ack'ed
> opencv for after that's finished. I'll see where we are after the perl
> transition and how all transitions are entangled, but if it all needs to
> go sequential there's a couple of older requests still ahead of this
> transition.
>

That's just fine, kneeing more or less were we are is useful to organize us
and keeping users updated. Thanks!

>

Bug#935653: 100% CPU usage for a long time

[Pascal Giard]

Dear Balint,

I confirm that, like Thibaut Girka, I actually get tons of "sanity check
failed" which actually trigger those numerous "falling back to adjusting
's dependencies recursively".

Best regards,

-Pascal
--
Homepage (http://pascal.giard.info)
École de technologie supérieure (http://etsmtl.ca)

Bug#931729: apt-mirror: SSUse of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror line 829)

[Сергей Фёдоров]

I offer version 2 of the correction:

To solve a problem I wrote about earlier,
in the text of the program "apt-mirror 0.5.4-1" commented or added new lines.

I marked my changes with comments:
# *** my comment
# *** my insert

#---
# I agree with Justin Pasher (932...@bugs.debian.org) and with Stephan Seitz 
(932...@bugs.debian.org),
# if you look a little lower in the text of the program "apt-mirror",
# you can see a similar code, but for all 3 archive formats:
#
# sub find_dep11_files_in_release
#...
#   if ( $filename =~ 
m{^$component/dep11/(Components-${arch}\.ml|icons-[^./]+\.tar)\.(gz|bz2|xz)$} )
#
#So maybe better:

sub find_translation_files_in_release
{
...
  # if ( $filename =~ m{^$component/i18n/Translation-[^./]*\.bz2$} ) # my 
comment
  if ( $filename =~ m{^$component/i18n/Translation-[^./]*\.(gz|bz2|xz)$} )  
# my insert

# In order not to think about it anymore, especially since all the rest of the 
text supports all 3 formats.
#---
sub need_update
{
my $filename   = shift;
my $size_on_server = shift;

my ( undef, undef, undef, undef, undef, undef, undef, $size ) = 
_stat($filename);

// $size may have a value "undef", if the file on client side is apsent.
# return 1  unless ($size);# *** my comment 2
return 1  unless (defined $size);  # *** my insert  2
return 1  if ($size <= 0); # *** my insert  2

return 0 if $size_on_server == $size;

unlink( $filename ) || die("apt-mirror: unlink error:  $! for file: 
$filename"); # *** my insert
return 1;
}

#---
sub process_index
{
 ...
 if ( exists $lines{"Filename:"} )
 {   # Packages index
 $skipclean{ remove_double_slashes( $path . "/" . $lines{"Filename:"} ) 
} = 1;
 print FILES_ALL remove_double_slashes( $path . "/" . 
$lines{"Filename:"} ) . "\n";
 print FILES_MD5 $lines{"MD5sum:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined lines{"MD5sum:"};
 print FILES_SHA1 $lines{"SHA1:"} . "  " . remove_double_slashes( $path 
. "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"SHA1:"};
 print FILES_SHA256 $lines{"SHA256:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"SHA256:"};
 if ( need_update( $mirror . "/" . $lines{"Filename:"}, $lines{"Size:"} 
) )
 {
 print FILES_NEW remove_double_slashes( $uri . "/" . 
$lines{"Filename:"} ) . "\n";
 add_url_to_download( $uri . "/" . $lines{"Filename:"}, 
$lines{"Size:"} );
 }
 }
 #else # *** my comment
 elsif ( exists $lines{"Files:"} )  # *** my insert
 {# Sources index
  foreach ( split( /\n/, $lines{"Files:"} ) )
  {
 ...
}
##
## Main download

chdir get_variable("mirror_path") or die("apt-mirror: can't chdir to mirror");

my $need_bytes = 0;
foreach ( values %urls_to_download )
{
$need_bytes += $_;
}
if ($need_bytes > 0) {  # *** my insert

  my $size_output = format_bytes($need_bytes);

  print "$size_output will be downloaded into archive.\n";

  download_urls( "archive", sort keys %urls_to_download );
}  # *** my insert
##

String with "unlink" in "sub need_update" is very important, since "wget" does
not a re-change a package if it is not fully downloaded on previous runs
of "apt-mirror". For example, if in the previous run "apt-mirror" pressed 
"Ctrl+C".

After this change everything works fine and the message:

Processing indexes: [SUse of uninitialized value $lines{"Files:"} in split 
at /usr/bin/apt-mirror line 829,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 829,  line 2.
P]

больше не возникает. Да и сообщения из-за повторного скачивания неполностью
скаченных пакетов тоже не возникают.

no longer appears. And messages for re-download the not completely
downloaded packages also do not occur.

Bug#906578: [makehuman] Future Qt4 removal

[Moritz Mühlenhoff]

On Sat, Aug 18, 2018 at 08:34:21AM -0400, Boyuan Yang wrote:
> Source: makehuman
> Version: 1.1.1-1
> Severity: normal
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> TL;DR: Your package, makehuman, is using pyqt4 which depends on Qt4. 
> However, it is planned that Qt4 shall be removed from Debian in the 
> future. Please check upstream status for Qt5 migration and package 
> the new (py)Qt5-based version when available.
> 
> * Python3 + Qt5 development git repository:
> 
> https://github.com/makehumancommunity/makehuman
> 
> == Begin mail template ==
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced]  msg6.html>
> 
> Currently Qt4 has been dead upstream and we are starting to have 
> problems
> maintaining it.
> 
> In order to make this move, all packages directly or indirectly 
> depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a 
> Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether 
> there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging 
> it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> 
> For any questions and issues, do not hesitate to contact the Debian 
> Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 

Hi,
there hasn't been any followup on this bug since over a year and we're now 
moving
forward with the Qt4 removal, are there immediate plans to port makehuman to 
Qt5 or
should we remove it from the archive?

Cheers,
Moritz

Bug#874901: [GLE-devel] Probable fix for qgle seg faults with latest ghostscript versions

[Moritz Mühlenhoff]

On Fri, Sep 13, 2019 at 07:54:04PM +0200, Francesco Poli wrote:
> > Right now I see three possible "fixes" for the libgs problem:
> [...]
> > - fix the code, link to libgs during the build, as is done with all the
> >   other libraries qgle depends on. I do not understand why libgs is treated
> >   differently, there may be a reason, I just don't know. I think Laurence is
> >   working on that, but maybe somebody else working on gle can comment.
> 
> I think this is probably the best strategy, but, as I said, let's hear
> what upstream developers have to say on this.
> 
> In the meanwhile, I would like to suggest once more that you upload the
> fixes for the serious bug (Qt5 porting) and for the other bug (qgle
> segfault)!

Agreed, it would be good if we could move forward with the Qt5 change,
we've closing in on the Qt4 removal and this is one of the ~ three dozen
packages left.

Cheers,
Moritz

Bug#942192: RFS: gkdebconf/2.1.0 [QA] -- Helper to reconfigure packages with Debconf

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for a QA upload of the package "gkdebconf".

 * Package name: gkdebconf
   Version : 2.1.0
   Upstream Author : Gustavo Noronha Silva 
 Agney Lopes Roth Ferraz 
 * URL : N/A
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/gkdebconf
   Section : admin

It builds this binary package:

  gkdebconf - Helper to reconfigure packages with Debconf

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gkdebconf/gkdebconf_2.1.0.dsc

Changes since the last upload:

   * QA upload.

   [ Helmut Grohne ]
   * Fix FTCBFS: Don't hard code pkg-config. (Closes: #916419)

   [ Américo Monteiro ]
   * Update Portuguese translation (Closes: #925574).

   [ Jean-Pierre Giraud ]
   * Update French translation (Closes: #928698).

   [ Yavor Doganov ]
   * Use dpkg-parsechangelog to derive version for AC_INIT.
   * Remove GConf migration code; stop recommending gconf2.
   * Port to GTK 3; adjust Build-Depends accordingly.
   * Use dpkg-query instead of accessing dpkg's internal database directly.
   * Update packages providing the debconf frontends.
   * Prompt the user if the GNOME frontend is missing.
   * Bump compat level to 12.
   * Convert the icon to PNG as AppStream does not support XPM.
   * Bump Standards-Version to 4.4.1; no changes needed.
   * Don't set LDFLAGS; unnecessary with GCC 9.
   * Update copyright years.
   * Restore Vcs fields; point to the new Salsa repository.

Bug#875075: [openscenegraph] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sun, Aug 18, 2019 at 09:02:36AM +0200, Sebastiaan Couwenberg wrote:
> On Sat, 23 Sep 2017 11:47:59 +0200 "Manuel A. Fernandez Montecelo" wrote:
> > This package will be removed after rdeps migrate to openscenegraph-3.4 or a 
> > later version (which does support Qt5), or rdeps are removed, or if nothing 
> > else, when the removal of Qt4 happens.
> > 
> > (We plan to poke rdeps withing a few months, we don't want this version 
> > shipped in Buster).
> 
> The only remaining libopenscenegraph100v5 rdeps are opensurgsim & kido,
> I wouldn't wait for them to stop using openscenegraph.
> 
> More problematic is that the libopenthreads packages are still only
> provided by openscenegraph and not openscenegraph-3.4. Please stop
> providing those packages from src:openscenegraph and build them from
> src:openscenegraph-3.4 instead.
> 
> This RC bug affects all rdeps of openscenegraph-3.4 too because of that.

Could we move forward with an upload? This is a blocker for the removal
of Qt4 from the archive.

Cheers,
Moritz

Bug#875065: [odin] Future Qt4 removal from Buster -> odin is ready for Qt5

[Moritz Mühlenhoff]

On Wed, Jan 23, 2019 at 09:46:28AM +0100, thies wrote:
> Dear all,
> 
> odin should compile on Buster without changes using the packages qt5-default
> and libqwt-qt5-dev.

This bug hasn't seen any maintainer followup since two years, are the 
maintainers
planning to make this change?

We're now moving forward with the Qt4 removal, if there no immediate plans to
switch port odin to Qt5, we'll request to remove it from the archive.

Cheers,
Moritz

Bug#875041: [meshlab] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

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

There hasn't been any followup on this bug since two years and we're now moving
forward with the Qt4 removal, are there immediate plans to port meshlab to Qt5 
or
should we remove it from the archive?

Cheers,
Moritz

Bug#875031: [linguider] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

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

Hi,
There hasn't been any followup on this bug since two years and we're now moving
forward with the Qt4 removal, are the immediate plans to port linguider to Qt5 
or
should we remove it from the archive?

Cheers,
Moritz

Bug#942191: Depends on qt4

[Moritz Muehlenhoff]

Source: hachoir-metadata
Severity: serious

hachoir-metadata build-depends on python-qt4, which is being removed from the 
archive along with Qt4 soon.

Cheers,
Moritz

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

[Filipe Fonseca]

Hello,

Using /etc/systemd/system/clamav-daemon.service.d/extend.conf

[Service]
ExecStartPre=-/bin/mkdir /run/clamav
ExecStartPre=/bin/chown clamav /run/clamav

from stretch works for me.

I would prefer

[Service]
ExecStartPre=/bin/mkdir -p /run/clamav
ExecStartPre=/bin/chown clamav /run/clamav

Best regards,
Filipe

--
filipe.fons...@farmingbits.com
+351.914593743

Bug#942024: stretch-pu: package openjpeg2/2.1.2-1.1+deb9u4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-10-09 at 09:40 +0200, Hugo Lefeuvre wrote:
> as discussed in #939553[0], no DSA will be issued by the security
> team for
> CVE-2018-21010 and this vulnerability can be fixed via -pu. The
> attached
> debdiff addresses this issue, along with CVE-2018-20847 and CVE-2018-
> 21010.

I think that second occurrence of 2018-21010 might be incorrect. :-)

Please go ahead.

Regards,

Adam

Bug#942190: cups: Memory leak for WIFI enabled printer.

[Mladen Mijatov]

Package: cups
Version: 2.3.0-5
Severity: normal

I have HP LaserJet 1102W which I use through WIFI network. Over time cupsd
starts leaking memory and within few hours goes to 1GB sometimes.

Printer requires HP's LIP service and drivers to work.

I have also noticed that when printer is interrupted in half-print, even if I
rester printing service memory will leak. Since I have never reported cups
related issues submitting additional information would require some level of
guidance.



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

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

Versions of packages cups depends on:
ii  cups-client2.3.0-5
ii  cups-common2.3.0-5
ii  cups-core-drivers  2.3.0-5
ii  cups-daemon2.3.0-5
ii  cups-filters   1.25.6-1
ii  cups-ppdc  2.3.0-5
ii  cups-server-common 2.3.0-5
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript9.27~dfsg-3.1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.29-2
ii  libcups2   2.3.0-5
ii  libgcc11:9.2.1-8
ii  libstdc++6 9.2.1-8
ii  libusb-1.0-0   2:1.0.23-1
ii  poppler-utils  0.71.0-6
ii  procps 2:3.3.15-2+b1

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4+b1
ii  colord   1.4.3-4
ii  cups-filters [ghostscript-cups]  1.25.6-1
ii  printer-driver-gutenprint5.3.3-2

Versions of packages cups suggests:
ii  cups-bsd   2.3.0-5
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20190913-1
ii  hplip  3.19.8+dfsg0-7
ii  printer-driver-hpcups  3.19.8+dfsg0-7
pn  smbclient  
ii  udev   242-7

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

Bug#941093: ping!

[Paul Gevers]

Hi Lisandro,

[Please provide more context in your replies to bugs, it really annoying
to have to look up a bug just to figure the context out. A
"qtbase-opensource-src transition" anywhere in your e-mail subject or
body would have fixed that].

On 04-10-2019 20:18, Lisandro Damián Nicanor Pérez Meyer wrote:
> Gentle ping for this one. Maxy just told me it is blocking a KDE update in
> unstable too.

We're currently having a perl transition ongoing and I already ack'ed
opencv for after that's finished. I'll see where we are after the perl
transition and how all transitions are entangled, but if it all needs to
go sequential there's a couple of older requests still ahead of this
transition.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#942189: libiscsi7: Connecting to IPv6 hosts does not work

[Armin Fisslthaler]

Package: libiscsi7
Version: 1.18.0-2
Severity: important
Tags: ipv6 patch

Dear Maintainer,

trying to connect to IPv6 hosts with applications using libiscsi7 does
not work and results in the following error message:
> Failed to start full connect Couldn't connect transport 
No IPv6 traffic is sent by the application since the connect() syscall
fails.

This is easily testable with the following command:
> iscsi-inq --initiator-name  iqn.1993-08.org.debian:01:f4242424242f   
> iscsi://[fec0:2727::3]:3260/iqn.foo.test/1

This is a blocker for accessing disks via -disk iscsi//... in qemu.


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

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

Versions of packages libiscsi7 depends on:
ii  libc62.28-10
ii  libibverbs1  22.1-1
ii  librdmacm1   22.1-1

libiscsi7 recommends no packages.

libiscsi7 suggests no packages.

-- no debconf information
>From 179f6b33d43f26cbca133ff03fa1bacc7e8a6120 Mon Sep 17 00:00:00 2001
From: Ronnie Sahlberg 
Date: Sun, 8 Jan 2017 12:57:12 -0800
Subject: [PATCH] Fix IPV6

Signed-off-by: Ronnie Sahlberg 
---
 lib/socket.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/lib/socket.c b/lib/socket.c
index 926e474..41b68c0 100644
--- a/lib/socket.c
+++ b/lib/socket.c
@@ -188,6 +188,20 @@ static int iscsi_tcp_connect(struct iscsi_context *iscsi, 
union socket_address *
 
int socksize;
 
+   switch (ai_family) {
+   case AF_INET:
+socksize = sizeof(struct sockaddr_in);
+break;
+   case AF_INET6:
+socksize = sizeof(struct sockaddr_in6);
+break;
+default:
+   iscsi_set_error(iscsi, "Unknown address family :%d. "
+   "Only IPv4/IPv6 supported so far.",
+   ai_family);
+return -1;
+}
+
iscsi->fd = socket(ai_family, SOCK_STREAM, 0);
if (iscsi->fd == -1) {
iscsi_set_error(iscsi, "Failed to open iscsi socket. "
@@ -246,8 +260,6 @@ static int iscsi_tcp_connect(struct iscsi_context *iscsi, 
union socket_address *
ISCSI_LOG(iscsi,3,"TCP_NODELAY set to 1");
}
 
-   socksize = sizeof(struct sockaddr_in);  // Work-around for now, need to 
fix it
-
if (connect(iscsi->fd, &sa->sa, socksize) != 0
&& errno != EINPROGRESS) {
iscsi_set_error(iscsi, "Connect failed with errno : "
@@ -332,6 +344,7 @@ iscsi_connect_async(struct iscsi_context *iscsi, const char 
*portal,
case AF_INET:
socksize = sizeof(struct sockaddr_in);
memcpy(&sa.sin, ai->ai_addr, socksize);
+sa.sin.sin_family = AF_INET;
sa.sin.sin_port = htons(port);
 #ifdef HAVE_SOCK_SIN_LEN
sa.sin.sin_len = socksize;
@@ -341,6 +354,7 @@ iscsi_connect_async(struct iscsi_context *iscsi, const char 
*portal,
case AF_INET6:
socksize = sizeof(struct sockaddr_in6);
memcpy(&sa.sin6, ai->ai_addr, socksize);
+sa.sin6.sin6_family = AF_INET6;
sa.sin6.sin6_port = htons(port);
 #ifdef HAVE_SOCK_SIN_LEN
sa.sin6.sin6_len = socksize;
-- 
2.20.1

>From 179f6b33d43f26cbca133ff03fa1bacc7e8a6120 Mon Sep 17 00:00:00 2001
From: Ronnie Sahlberg 
Date: Sun, 8 Jan 2017 12:57:12 -0800
Subject: [PATCH] Fix IPV6

Signed-off-by: Ronnie Sahlberg 
---
 lib/socket.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/lib/socket.c b/lib/socket.c
index 926e474..41b68c0 100644
--- a/lib/socket.c
+++ b/lib/socket.c
@@ -188,6 +188,20 @@ static int iscsi_tcp_connect(struct iscsi_context *iscsi, 
union socket_address *
 
int socksize;
 
+   switch (ai_family) {
+   case AF_INET:
+socksize = sizeof(struct sockaddr_in);
+break;
+   case AF_INET6:
+socksize = sizeof(struct sockaddr_in6);
+break;
+default:
+   iscsi_set_error(iscsi, "Unknown address family :%d. "
+   "Only IPv4/IPv6 supported so far.",
+   ai_family);
+return -1;
+}
+
iscsi->fd = socket(ai_family, SOCK_STREAM, 0);
if (iscsi->fd == -1) {
iscsi_set_error(iscsi, "Failed to open iscsi socket. "
@@ -246,8 +260,6 @@ static int iscsi_tcp_connect(struct iscsi_context *iscsi, 
union socket_address *
ISCSI_LOG(iscsi,3,"TCP_NODELAY set to 1");
}
 
-   socksize = sizeof(struct sockaddr_in);  // Work-around for now, need to 
fix it
-
if (connect(is

Bug#942184: New stable version is available: 5.13.1

[Dmitry Shachnev]

Control: tags -1 +moreinfo

Hi Boris!

On Fri, Oct 11, 2019 at 06:44:00PM +0300, Boris Pek wrote:
> Package: qtwebkit-opensource-src
> Version: 5.212.0~alpha3-4
> Severity: wishlist
>
> Hi,
>
> Please update QtWebkit to the latest stable version 5.13.1.
> Tarballs are available here:
> https://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/src/submodules/

As the URL says, it is a snapshot, not a release. All releases are
listed here:

https://github.com/qtwebkit/qtwebkit/releases

Is there any specific fix you want from the new snapshot?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#942075: buster-pu: package cyrus-imapd/3.0.8-6+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-10-09 at 22:41 +0200, Xavier Guimard wrote:
> cyrus-imapd ≤ 3.0.8 has a RC bug: it may loss data during upgrade
> from
> stretch to buster. The fix is very simple, then I think it is low
> risky
> to upgrade it in next Buster point release.
> 

+cyrus-imapd (3.0.8-6+deb10u1) buster; urgency=medium
+
+  * Fix data loss (Closes: #933163)

It might be worth expanding on the issue a little there, to make the
scope clearer.

In any case, please go ahead.

Regards,

Adam

Bug#942044: buster-pu: package open-vm-tools/2:10.3.10-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-10-09 at 15:59 +0200, Bernd Zeimetz wrote:
> I'd like to update open-vm-tools with the next pointrelease as
> upstream
> found some memory leaks which need to be fixed. This includes a very
> minor security issue where root would have access to soon expiring
> saml
> tokens - but root has access to them anyway (for example by running a
> hacked version of open-vm-tools).
> 

Please go ahead; thanks.

Regards,

Adam

Bug#942188: ansible: CVE-2019-14846

[Salvatore Bonaccorso]

Source: ansible
Version: 2.8.3+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/pull/63366

Hi,

The following vulnerability was published for ansible.

CVE-2019-14846[0]:
| Ansible, all ansible_engine-2.x versions and ansible_engine-3.x up to
| ansible_engine-3.5, was logging at the DEBUG level which lead to a
| disclosure of credentials if a plugin used a library that logged
| credentials at the DEBUG level. This flaw does not affect Ansible
| modules, as those are executed in a separate process.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14846
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14846
[1] https://github.com/ansible/ansible/pull/63366

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#941946: resolution

[Peter Upton]

Bug no longer occurs after BIOS update.
Looks like this was a bug with the bios and not Debian.

Bug#942110: stretch-pu: package gnustep-base/1.24.9-3.1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-10-10 at 16:42 +0300, Yavor Doganov wrote:
> I'd like to fix a vulnerability in the gdomap daemon (no DSA).  It is
> fixed in testing/unstable and already approved/uploaded for buster
> (release.d.o #940943).  The patch is the same.

Please go ahead.

Regards,

Adam

Bug#942177: buster-pu: package dkimpy-milter/1.0.1-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-10-11 at 10:05 -0400, Scott Kitterman wrote:
> This update is based on a maitnenance update from upstream (1.0.2) by
> an
> upstream familiar with Debian's post-release update process with an
> intent to only address issues appropriate for a Debian stable update.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#939033: qutemol: Uses GifQuantizeBuffer - stops working with newer giflib

[Graham Inggs]

For reference, upstream proposed that applications requiring this
function should link lutil or make their own copy of the code [1].

Arch Linux bug report [2] refers to a patch [3], which resolves the issue.

Gentoo bug report [4] refers to a pull request [5], which was not accepted.


[1] https://sourceforge.net/p/giflib/bugs/132/
[2] https://bugs.archlinux.org/task/62211
[3] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/giflib-5.1.9-fix-missing-quantize-API-symbols.patch?h=packages/giflib
[4] https://bugs.gentoo.org/682198
[5] https://github.com/gentoo/gentoo/pull/12386

Bug#942187: libxdmf-dev: conflict with older libxdmf3

[Marc Glisse]

Package: libxdmf-dev
Version: 3.0+git20190531-1
Severity: normal

Dear Maintainer,

I upgraded libxdmf-dev and libxdmf3 on my system (more precisely, I ran
"sudo apt install libloki-dev" which caused the update of those 2
packages) and got the following error:

Unpacking libxdmf-dev (3.0+git20190531-1) over (3.0+git20160803-5+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libxdmf-dev_3.0+git20190531-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/xdmf/openmpi/libXdmf.so', which 
is also in package libxdmf3:amd64 3.0+git20160803-5+b1

It seems that a file was moved from libxdmf3 to libxdmf-dev without
adding any conflicts/replaces/breaks (whichever is required in this
situation so apt updates things in the right order).

It is easy enough to work around but it would still be good to fix it.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_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 libxdmf-dev depends on:
ii  libgzstream-dev  1.5+dfsg-4
ii  libloki-dev  0.1.7-3+b3
ii  libxdmf3 3.0+git20190531-1

libxdmf-dev recommends no packages.

libxdmf-dev suggests no packages.

-- no debconf information

Bug#942186: RM: sandboxgamemaker -- RoQA; inactive upstream; NIT; broken; orphaned; RC-buggy; low popcon

[Olly Betts]

Package: ftp.debian.org
Severity: normal

* Last upstream release was 2013
* Not in testing
* Doesn't work at all without manually downloading a tarball from
  upstream, pulling out various files, and installing by hand (#764896)
* Orphaned
* Very low popcon (Inst: 58 Vote: 5)
* No rdeps according to: `dak rm -Rn sandboxgamemaker`

Cheers,
Olly

Bug#941698: Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2

[Romain Francoise]

On Fri, Oct 11, 2019 at 2:06 PM Thierry fa...@linux.ibm.com
 wrote:
> This is similar to bug #873377 which was supposed to be fixed in V 4.9.1-2 - 
> logs show that for v4.9.1-2 and -3 test was not run - then it was failing but 
> not reported as an error for the global count of success !

Sigh. I re-enabled this test in 4.9.3-1 thinking that it had been
fixed, but alas no, it still fails. Will disable again...

Bug#942139: (no subject)

[bert]

see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942126
that is the exact issue I'm having, so maybe close this bug report?

Bug#925036: liblockfile: diff for NMU version 1.16-1.1

[Boyuan Yang]

Control: tags 925036 + patch
Control: tags 925036 + pending

Dear maintainer,

I've prepared an NMU for liblockfile (versioned as 1.16-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru liblockfile-1.16/debian/changelog liblockfile-1.16/debian/changelog
--- liblockfile-1.16/debian/changelog   2019-09-26 08:32:11.0 -0400
+++ liblockfile-1.16/debian/changelog   2019-10-11 13:55:06.0 -0400
@@ -1,3 +1,15 @@
+liblockfile (1.16-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild with source-only upload to allow testing migration.
+  * debian/control:
+- Drop anibal from the uploader list. (Closes: #925036)
+  * debian/source/options: Drop customized compression settings.
+(solves lintian warning:
+debian-source-options-has-custom-compression-settings)
+
+ -- Boyuan Yang   Fri, 11 Oct 2019 13:55:06 -0400
+
 liblockfile (1.16-1) unstable; urgency=low
 
   * new upstream version (closes: #933104)
diff -Nru liblockfile-1.16/debian/control liblockfile-1.16/debian/control
--- liblockfile-1.16/debian/control 2019-07-22 16:16:07.0 -0400
+++ liblockfile-1.16/debian/control 2019-10-11 13:51:56.0 -0400
@@ -2,7 +2,6 @@
 Section: devel
 Priority: standard
 Maintainer: Miquel van Smoorenburg 
-Uploaders: Anibal Monsalve Salazar 
 Standards-Version: 3.9.4
 Build-depends: debhelper (>=9)
 Vcs-Git: https://github.com/miquels/liblockfile-debian
diff -Nru liblockfile-1.16/debian/source/options liblockfile-
1.16/debian/source/options
--- liblockfile-1.16/debian/source/options  2017-01-05 08:40:57.0
-0500
+++ liblockfile-1.16/debian/source/options  2019-10-11 13:55:03.0
-0400
@@ -1,3 +1 @@
-compression = "bzip2"
-compression-level = 9
 extend-diff-ignore = "README.md|LICENSE"


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

Bug#935621: Bug935621: openstack-dashboard: incompatible with django 2.2

[Boyuan Yang]

Hi zigo, Michael,

On Wed, 9 Oct 2019 18:02:16 +0200 Thomas Goirand  wrote:
> Hi,
> 
> This was fixed with the last upload of Horizon.

Unfortunately the last upload was not a source-only upload. As a result, the
fixed version will never migrate to testing.

Could you please make another source-only upload as described in 
https://wiki.debian.org/SourceOnlyUpload at your convenience?

Thanks,
Boyuan Ynag


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

Bug#603600: Info received (Can reproduce, maybe a bugfix is availible)

[Dirk Heilig]

i've manged to build the version currently used in debian buster with this
patch applied to src/client.cc:

229,230d228
< if (e.active.gain == 0 && !video::IsFullScreen())
< show_menu(false);

Which is basically the linked change.
At least for me, this solves my issue.


Am Do., 10. Okt. 2019 um 19:51 Uhr schrieb Debian Bug Tracking System <
ow...@bugs.debian.org>:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Erich Schubert 
>
> If you wish to submit further information on this problem, please
> send it to 603...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 603600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603600
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#931018: Please add Breaks for webpack << 4.28.3 to acorn 6

[Pirate Praveen]

On Mon, 24 Jun 2019 20:29:23 +0500 Pirate Praveen
 wrote:
> package: node-acorn
> version: 
> 6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1
> severity: wishlist
> 
> Please add Breaks: webpack (<< 4.28.3~) as node-acorn 6 gets installed 
> otherwise in experimental (experienced when trying to build 
> node-dagre-d3-renderer in salsa). I tried to update it myself, but 
> master seems not in a state to upload.

Please also add Breaks: rollup (<< 1.0~), node-buble (<< 0.19.8~)

Bug#941917: nginx: FTBFS on several architectures: luajit.h: No such file or directory

[gregor herrmann]

On Thu, 10 Oct 2019 23:46:26 +0200, gregor herrmann wrote:

> Do I understand this correctly that changing the architecture list
> should fix the bug short-term and then the failing luajit detection
> should be fixed as well? At least the first part would be quite easy.

A quick test on the arm64 porterbox seems to indicate that a simple
update of the architecture list for the liblua* build dependencies is
indeed enough to fix the immediate problem.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Police: Wrapped Around Your Finger


signature.asc
Description: Digital Signature

Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version

[Paul Gevers]

Hi Matthias,

On 10-10-2019 15:06, Matthias Klose wrote:
> Please setup a tracker to add python3.8 as a supported python3 version.
> This is non-blocking, as packages can migrate on their own once built.
> I'm not yet starting this, just want to have an overview of affected
> packages.
> 
> Please could you re-use the final version of the python3.7 tracker,
> which had several iterations in #902582?

Done. Will appear slightly after 17:30 UTC if I didn't make any mistake.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds

[Nicolas Bercher]

On Thu, 28 Feb 2019 14:20:35 +0100 Dejan Muhamedagic 
 wrote:

Package: lvm2
Version: 2.03.02-2
Followup-For: Bug #918590

As Ville Korhonen already reported, this bug affects all chroot
based stuff (debootstick, multistrap, schroot) making them
effectively unusable. There's some more info here:

https://bbs.archlinux.org/viewtopic.php?id=242594



The Arch post mentioned above helpd me a lot but was not enough for me
since all lvm tools where still stuck in the chroot env.

My solution was to also bind mount /run/udev from the host to the
chrooted system.

My complete story and solution below:

I faced this bug today while playing with LVM volumes on a new EFI
machine.  I was using a live Debian Buster and chrooted Debian Buster.

In the chroot, I tried =strace /sbin/lvdisplay= and discovered attempts
to open files in /run/udev/.

I also warn you that for Debian Buster to be chrooted, your live CD
must be equipped with same LVM2 version or so.  This is the first time I
face this issue (I have debug lots of situations in the past using, for
example, quite old rescuecd w.r.t. chrooted system).

# On the host:
apt-get install lvm2
pvscan
vgchange -a y
mount /dev/vg/debian-amd64 /mnt/debian-amd64

# Prepare chroot:
root=/mnt/debian-amd64
mkdir -p /mnt/debian-amd64/run/lvm
mkdir -p /mnt/debian-amd64/run/udev
mount --bind /dev $root/dev
mount --bind /proc $root/proc
mount --bind /sys $root/sys
mount --bind /dev/pts $root/dev/pts
mount --bind /run/lvm $root/run/lvm
mount --bind /run/udev $root/run/udev
# Do not forget EFI partition:
mount /dev/sda1 $root/boot/efi

# Run chroot:
chroot $root /bin/bash

# In the chroot:
update-grub
grub-install --efi-directory=/boot/efi

Hope this helps.
Nicolas

Bug#942185: netatalk FTCBFS: bare pkg-config invocation

[Helmut Grohne]

Source: netatalk
Version: 3.1.12~ds-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

netatalk fails to cross build from source, because there is one
remaining bare pkg-config invocation. All others are fine. The attached
patch fixes it. Please consider applying it.

Helmut
--- netatalk-3.1.12~ds.orig/macros/netatalk.m4
+++ netatalk-3.1.12~ds/macros/netatalk.m4
@@ -156,7 +156,8 @@
 AC_ARG_WITH([tracker-prefix],
   [AS_HELP_STRING([--with-tracker-prefix=PATH],[Prefix of Tracker (default: none)])],
   [ac_cv_tracker_prefix=$withval],
-  [ac_cv_tracker_prefix="`pkg-config --variable=prefix tracker-sparql-$ac_cv_tracker_pkg_version`"]
+  [AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+   ac_cv_tracker_prefix="`$PKG_CONFIG --variable=prefix tracker-sparql-$ac_cv_tracker_pkg_version`"]
 )
 
 AC_ARG_WITH([tracker-install-prefix],

Bug#514464: caps lock led does not show up

[Victor Tapia]

Hi,

this bug is still present in Debian/Ubuntu. I noticed that in ckbcomp
broken_caps is set to 1 even when the keycode $v is <100, triggering the
ControlL_lock replacement. IIUC the 'gt' is a string operator that
should be replaced with '>' at print_vector():

if ($v != $c && $v gt 0x7f) {
$broken_caps = 1;
}

Also, is the udev rule going to be part of the next release of
console-setup?

Thanks,

Victor

Bug#942184: New stable version is available: 5.13.1

[Boris Pek]

Package: qtwebkit-opensource-src
Version: 5.212.0~alpha3-4
Severity: wishlist

Hi,

Please update QtWebkit to the latest stable version 5.13.1.
Tarballs are available here:
https://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/src/submodules/

Best wishes,
Boris

Bug#942183: Fwd: memcached : FTBFS on ppc64el - missing ss command

[Thierry fa...@linux.ibm.com]

Source: memcached
Version: 1.5.19-1

autopkgtest fails on ppc64el with message ss not found. This command 
coming from package iproute2, I believe it is a missing dependency.

Bug#942182: keepalived: gets stuck when receive queue of the raw socket fills up, fixed upstream in 2.0.12

[Paul Emmerich]

Package: keepalived
Version: 1:2.0.10-1
Severity: important

Dear Maintainer,

we've encountered the following bug in a setup with several unicast 
vrrp_instances:

https://github.com/acassen/keepalived/issues/1080

This is fixed upstream since 2.0.12



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

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

Versions of packages keepalived depends on:
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libip4tc0 1.8.2-4
ii  libip6tc0 1.8.2-4
ii  libjson-c30.12.1+ds-2
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libsnmp30 5.7.3+dfsg-5
ii  libssl1.1 1.1.1d-0+deb10u1
ii  libxtables12  1.8.2-4

Versions of packages keepalived recommends:
pn  ipvsadm  

keepalived suggests no packages.

-- no debconf information

Bug#942164: wpasupplicant: WiFi not working on FT or enterprise networks (CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00)

[Andrej Shadura]

Hi again,

On Fri, 11 Oct 2019 at 17:03, Andrej Shadura  wrote:
> > * wpasupplicant=2:2.4-1+deb9u4 (oldstable) *works*, but because
> > NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP'"
> > * wpasupplicant=2:2.7+git20190128+0c1e29f-6 (stable) *doesn't work*, but
> > because NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP
> > WPA-EAP-SHA256 FT-EAP FT-EAP-SHA384'"
> >
> > Now I'm on wpasupplicant=2:2.9.3 and it doesn't work, either, for the
> > same config reason
> >
> > Apparently nm uses the capabilities and triggers the bug.
>
> I’d suggest you report it to both NetworkManager and wpa
>  (attaching the error logs, not as links
> on pastebin since they may expire).

Just a thought… Apparently, you can change key_mgmt in the connection settings:

[wifi-security]
key-mgmt=...

It is possible you can limit it to what your hardware supports, but I
haven’t tested it.

-- 
Cheers,
  Andrej

Bug#942164: wpasupplicant: WiFi not working on FT or enterprise networks (CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00)

[Andrej Shadura]

Hi,

On Fri, 11 Oct 2019 at 16:58, Matteo Fortini  wrote:
> My network card is a BCM4350 802.11ac Wireless Network Adapter running
> on Linux 5.3

Well, Broadcom is a tricky one.

> * wpasupplicant=2:2.4-1+deb9u4 (oldstable) *works*, but because
> NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP'"
> * wpasupplicant=2:2.7+git20190128+0c1e29f-6 (stable) *doesn't work*, but
> because NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP
> WPA-EAP-SHA256 FT-EAP FT-EAP-SHA384'"
>
> Now I'm on wpasupplicant=2:2.9.3 and it doesn't work, either, for the
> same config reason
>
> Apparently nm uses the capabilities and triggers the bug.

I’d suggest you report it to both NetworkManager and wpa
 (attaching the error logs, not as links
on pastebin since they may expire).

-- 
Cheers,
  Andrej

Bug#942164: wpasupplicant: WiFi not working on FT or enterprise networks (CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00)

[Matteo Fortini]

My network card is a BCM4350 802.11ac Wireless Network Adapter running 
on Linux 5.3


* wpasupplicant=2:2.4-1+deb9u4 (oldstable) *works*, but because 
NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP'"
* wpasupplicant=2:2.7+git20190128+0c1e29f-6 (stable) *doesn't work*, but 
because NetworkManager uses "Config: added 'key_mgmt' value 'WPA-EAP 
WPA-EAP-SHA256 FT-EAP FT-EAP-SHA384'"


Now I'm on wpasupplicant=2:2.9.3 and it doesn't work, either, for the 
same config reason


Apparently nm uses the capabilities and triggers the bug.



Il 11/10/19 12:44, Andrej Shadura ha scritto:

Hi,

On Fri, 11 Oct 2019 at 09:40, Matteo Fortini  wrote:

Thank you for you ack.

Yes I can connect to "other" networks, but it's not easy not to be able to 
connect: at home, at work, at my town's free wifi, just to give some examples. In two of 
the three cases, I have no power to do anything.

This is a log with debug switched on: https://pastebin.com/XxA20Pwy

If there is anything I can do to help, I am more than willing to try it.

The issue has been here for almost a month.

What is your hardware? What is the latest version of wpa-supplicant that worked?

Bug#813559: Fix proposal

[Frédéric Bonnard]

Control: tags -1 patch

--

Hi,

I submitted a merge request which enables ngs-sdk to build on ppc64* and
possibly others :
https://salsa.debian.org/med-team/ngs-sdk/merge_requests/1

Regards,


F.


pgpRFWhUMZx9T.pgp
Description: PGP signature

Bug#942181: gopher: Unnecessarily distributes empty directories

[Boyuan Yang]

Package: gopher
Version: 3.0.17.2
Severity: minor

Package gopher is shipping empty directories:

-> % dpkg -c ./gopher_3.0.17.2_amd64.deb
drwxr-xr-x root/root 0 2019-10-04 01:27 ./
drwxr-xr-x root/root 0 2019-10-04 01:27 ./etc/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./etc/gopher/
-rw-r--r-- root/root  2458 2019-10-04 01:27 ./etc/gopher.hlp
-rw-r--r-- root/root  3111 2019-10-04 01:27 ./etc/gopher.rc
-rw-r--r-- root/root  1808 2019-10-04 01:27 ./etc/gopherremote.rc
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/bin/
-rwxr-xr-x root/root146816 2019-10-04 01:27 ./usr/bin/gopher
-rwxr-xr-x root/root 56048 2019-10-04 01:27 ./usr/bin/gophfilt
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/sbin/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/doc/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/doc/gopher/
-rw-r--r-- root/root  2636 2008-03-02 16:38 ./usr/share/doc/gopher/FAQ
-rw-r--r-- root/root  3438 2008-03-02 16:38
./usr/share/doc/gopher/INSTALL.gz
-rw-r--r-- root/root  2348 2008-03-02 16:38
./usr/share/doc/gopher/PLATFORMS
-rw-r--r-- root/root  2606 2008-03-02 16:38 ./usr/share/doc/gopher/README
-rw-r--r-- root/root   718 2008-03-02 16:38 ./usr/share/doc/gopher/TODO
-rw-r--r-- root/root  5687 2019-10-04 01:27
./usr/share/doc/gopher/changelog.gz
-rw-r--r-- root/root 15020 2008-03-02 16:38
./usr/share/doc/gopher/client.changes.gz
-rw-r--r-- root/root  3941 2008-03-02 16:38
./usr/share/doc/gopher/clientlogging.vms.gz
-rw-r--r-- root/root  1326 2019-10-04 00:16
./usr/share/doc/gopher/copyright
-rw-r--r-- root/root  1832 2008-03-02 16:38
./usr/share/doc/gopher/object.changes
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/man/
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/man/man1/
-rw-r--r-- root/root  3139 2019-10-04 01:27
./usr/share/man/man1/gopher.1.gz
-rw-r--r-- root/root  1642 2019-10-04 01:27
./usr/share/man/man1/gophfilt.1.gz
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/man/man5/
-rw-r--r-- root/root  1350 2019-10-04 01:27
./usr/share/man/man5/gopherrc.5.gz
drwxr-xr-x root/root 0 2019-10-04 01:27 ./usr/share/man/man8/


At least we do not ./usr/share/man/man8/ and ./usr/sbin/ at this time. A sane
approach is to drop debian/*.dirs and let debhelper utilities like dh_install
to automatically handle directory creation.

Best,
Boyuan Ynag


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

Bug#942180: ITP: golang-github-lk4d4-joincontext -- Golang library to join contexts

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:nomad

   Package name: golang-github-lk4d4-joincontext
Version: 0.0+git20171026
Upstream Author: Alexander Morozov
License: Expat
URL: https://github.com/LK4D4/joincontext
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-lk4d4-joincontext
Description: Golang library to join contexts
 Library joincontext provides a way to combine two contexts. For example it
 might be useful for grpc server to cancel all handlers in addition to
 provided handler context.


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

Bug#942179: pyudev's autopkg tests fail with pytest 4.6

[Matthias Klose]

Package: src:pyudev
Version: 0.21.0-1_0.21.0-1
Severity: serious
Tags: sid bullseye patch

pyudev's autopkg tests fail with pytest 4.6. Patch at
http://launchpadlibrarian.net/446268752/pyudev_0.21.0-1_0.21.0-1ubuntu1.diff.gz

Bug#942178: Build bcal on other architectures

[Frédéric Bonnard]

Package: src:bcal
Version: 2.1+git20190806.6c8d325-1

--

Dear maintainer,
is there any reason that bcal is not built on other architectures
(any/linux-any)?
I tested and it built well on ppc64/ppc64el.

Regards,


F.


pgpAEEO_1oMrY.pgp
Description: PGP signature

Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

[Cesare Leonardi]

Package: gvfs-fuse
Followup-For: Bug #942126

Hello Simon, sorry if my bug report was a bit scarce of information. I
was a bit in hurry when I wrote it. Now I try to remedy...


On Thu, 10 Oct 2019 19:44:44 +0100 Simon McVittie  wrote:
> On Thu, 10 Oct 2019 at 19:24:48 +0200, Cesare Leonardi wrote:
> > Every time MATE desktop starts, it mounts several SMB share with a
> > command like that:
> > gio mount "smb://host/folder"
> 
> By what mechanism does it mount them?

This PC is integrated in an Active Directory domain and I login using a
domain user. Winbind (from Samba), pam_winbind and nsswitch are involved
in this.

In my MATE environment I mount some shares from:
System -> Preferences -> Personal -> Startup Applications
Here I have a startup program for each "gio mount".

Before upgrading gvfs to 1.42.1-1, each mounted share was accessible
from /run/user/ID/gvfs/. Real example:

$ ls -o /run/user/11278/gvfs/
drwx-- 1 BERNI\leonardic0 ago  8  2015 'smb-share:server=gam,share=ced'
drwx-- 1 BERNI\leonardic0 giu  8  2017 
'smb-share:server=gam,share=driver'


Now the gvfs folder is not populated anymore.
In my initial report I forgot to add that the journal doesn't
apparentely show nothing useful to me.

But I've done some more tests and now I suspect that the culprit is fuse3.
Upgrading from 1.42.0+really1.38.1-1 to 1.42.1-1 I saw that gvfs-fuse
dependencies switched from libfuse2 to libfuse3-3 and the latter
suggests "fuse3". Do note that in this bug report I still use fuse2,
but these days I've tried to install "fuse3" (that replaces "fuse"
2.9.9): the result was terrible because then logging with my Active
Directory user failed, with big slowness on login and in other places.
In that situation the journal showed errors from pam_winbind but I don't
know how and why it's related to fuse. Since with fuse3 the system was
substantially unusable for me, I had to immediately revert to fuse 2.x.

Now I've also reverted gvfs to 1.42.0+really1.38.1-1, but let me know if
you want me to do some tests or if you need more information: I will
upgrade to the latest version for you then I'll revert afterward.

Thank you.

Cesare.



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

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

Versions of packages gvfs-fuse depends on:
ii  fuse  2.9.9-2
ii  gvfs  1.42.0+really1.38.1-1
ii  libc6 2.29-2
ii  libfuse2  2.9.9-2
ii  libglib2.0-0  2.62.1-1

gvfs-fuse recommends no packages.

gvfs-fuse suggests no packages.

-- no debconf information

Bug#942177: buster-pu: package dkimpy-milter/1.0.1-1

[Scott Kitterman]

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

This update is based on a maitnenance update from upstream (1.0.2) by an
upstream familiar with Debian's post-release update process with an
intent to only address issues appropriate for a Debian stable update.

There are several types of changes included:

1.  Resiliance: After the last upstream release, a nubmer of issues with
the reliability of the milter when presented with corrupted data were
identified (although not in the BTS, the report was upstream from a
Debian user).  There are a number of changes to catch errors and
continue the milter running.  These are the most critical.

dkimpy-milter-1.0.2/dkimpy_milter/__init__.py
line 54, 133, and line 255 through 303 hunks.

2.  Correctness: If the milter is configured to both sign and verify
messages in the same process (which is not the usual case, but can
happen - I discuverd this one the hard way), then the milter will fail.

dkimpy-milter-1.0.2/dkimpy_milter/__init__.py line 174 hunk

The log message that the milter is starting would not log anything in
the failure case, which is the interesting one.

dkimpy-milter-1.0.2/dkimpy_milter/__init__.py line 351 hunk

All of the above are low risk, important fixes that will affect all
users of the package.

3.  Init fixes for sysv:  It turns out people use this in Docker
containers and bugs were filed upstream about the init scripts not
working in Debian Buster.  This was both packaging problems (debian/
rules changes) and init problems.  Updating the init so it works when
installed from upstream source, also required changes to paths used by
Debian (0001-update-upstream-unit-and-init-file-paths.patch).

These changes are slightly more extensive, but have no impact for users
of Debian's default init.  Sysv init support is totally broken now, so
there is no risk of regression.

I did my own test of these in Docker (since that's where they seem to be
used) and with these changes, they work now.

Scott K
diff -Nru dkimpy-milter-1.0.1/CHANGES dkimpy-milter-1.0.2/CHANGES
--- dkimpy-milter-1.0.1/CHANGES 2019-02-11 15:13:44.0 -0500
+++ dkimpy-milter-1.0.2/CHANGES 2019-10-07 00:12:30.0 -0400
@@ -1,3 +1,13 @@
+1.0.2 2019-10-07
+ - Fix startup logging so it provides information at a useful time
+ - Fix message extraction so that signing in the same pass through the milter
+   as verifying works correctly
+ - Fix variable initialization so mailformed mails missing body From do not
+   cause a traceback (LP: #1844161)
+ - Catch more ascii encoding errors to improve resilience against bad data
+   (LP: #1844189)
+ - Fix sysv init so it works (LP: #1839487)
+
 1.0.1 2019-02-11
  * Reorder milter start and dropping privileges so permissions on Unix socket
are correct (LP: 1797720)
diff -Nru dkimpy-milter-1.0.1/debian/changelog 
dkimpy-milter-1.0.2/debian/changelog
--- dkimpy-milter-1.0.1/debian/changelog2019-02-11 15:32:17.0 
-0500
+++ dkimpy-milter-1.0.2/debian/changelog2019-10-07 00:31:48.0 
-0400
@@ -1,3 +1,14 @@
+dkimpy-milter (1.0.2-1) buster; urgency=medium
+
+  * New upstream release
+  * Put upstream init file where dh_installinit expects to find it so it is
+properly registered
+  * Update debian/watch to point to 1.0 version for stable updates
+  * Update and rename d/p/0001-update-upstream-unit-and-init-file-paths.patch
+so sysv init paths are correct too
+
+ -- Scott Kitterman   Mon, 07 Oct 2019 00:31:48 -0400
+
 dkimpy-milter (1.0.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru dkimpy-milter-1.0.1/debian/gbp.conf 
dkimpy-milter-1.0.2/debian/gbp.conf
--- dkimpy-milter-1.0.1/debian/gbp.conf 2018-03-19 01:16:48.0 -0400
+++ dkimpy-milter-1.0.2/debian/gbp.conf 2019-10-07 00:25:34.0 -0400
@@ -1,2 +1,3 @@
 [DEFAULT]
-debian-branch=debian/master
+debian-branch=debian/buster
+upstream-branch=buster/upstream
diff -Nru 
dkimpy-milter-1.0.1/debian/patches/0001-update-upstream-unit-and-init-file-paths.patch
 
dkimpy-milter-1.0.2/debian/patches/0001-update-upstream-unit-and-init-file-paths.patch
--- 
dkimpy-milter-1.0.1/debian/patches/0001-update-upstream-unit-and-init-file-paths.patch
  1969-12-31 19:00:00.0 -0500
+++ 
dkimpy-milter-1.0.2/debian/patches/0001-update-upstream-unit-and-init-file-paths.patch
  2019-10-07 00:29:55.0 -0400
@@ -0,0 +1,38 @@
+From: Scott Kitterman 
+Date: Wed, 14 Mar 2018 22:53:01 -0400
+Subject: update upstream unit and init file paths
+
+---
+ system/dkimpy-milter | 4 ++--
+ system/dkimpy-milter.service | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/system/dkimpy-milter b/system/dkimpy-milter
+index f4d4e0f..5ca6368 100755
+--- a/system/dkimpy-milter
 b/system/dkimpy-milter
+@@ -18,9 +18,9 @@
+ # Short-Description: dkimpy-milter
+ # Description:   Python DKIM Milter for Sendmail and Postfix
+ ### END INIT INFO
+-prefi

Bug#942088: manpages-dev: crypt(3) is not installed

[张 敬强]

在 2019年10月10日星期四 CST 下午4:13:06，您写道：
> Version: 5.02-1
> 
> Am 10.10.19 um 08:22 schrieb Zhang Jingqiang:
> > Package: manpages-dev
> > Version: 5.02-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > crypt(3) is missing, which contains also crypt_r
> 
> Hi,
> 
> thanks for the bug report. Those manpages are intentionally removed from
> the Debian package, because they are already included in another package
> (libcrypt2-dev). Therefore, we have a name conflict and both packages
> cannot be installed at the same time.

But they have been diverted in libcrypt2-dev:

# dpkg-divert --list | grep libcrypt2
diversion of /usr/lib/x86_64-linux-gnu/libcrypt.a to /usr/lib/x86_64-linux-
gnu/glibc_libcrypt.a by libcrypt2-dev
diversion of /usr/lib/x86_64-linux-gnu/libcrypt.so to /usr/lib/x86_64-linux-
gnu/glibc_libcrypt.so by libcrypt2-dev
diversion of /usr/share/man/man3/crypt.3.gz to /usr/share/man/man3/
glibc_crypt.3.gz by libcrypt2-dev
diversion of /usr/share/man/man3/crypt_r.3.gz to /usr/share/man/man3/
glibc_crypt_r.3.gz by libcrypt2-dev
diversion of /usr/include/crypt.h to /usr/include/glibc_crypt.h by libcrypt2-
dev

# dpkg -L libc6-dev | grep crypt
/usr/include/crypt.h
diverted by libcrypt2-dev to: /usr/include/glibc_crypt.h
/usr/lib/x86_64-linux-gnu/libcrypt.a
diverted by libcrypt2-dev to: /usr/lib/x86_64-linux-gnu/glibc_libcrypt.a
/usr/lib/x86_64-linux-gnu/libcrypt.so
diverted by libcrypt2-dev to: /usr/lib/x86_64-linux-gnu/glibc_libcrypt.so

Bug#942161: [Python-modules-team] Bug#942161: src:impacket: Substantial issues with debian/copyright

[Emmanuel Arias]

Hello Scott,

Thanks for the report,

I will fix it

Thanks

On 10/11/19 2:31 AM, Scott Kitterman wrote:
> Package: src:impacket
> Version: 0.9.15-5
> Severity: serious
> Justification: Policy 2.5
>
> This is at least in part a problem in the existing package, so I am not
> going to reject the package for this, but it should definitely be fixed.
> The following significant issues need review/update in debian/copyright:
>
> Copyright 2018-2019 SecureAuth Corporation vice CORE Security Technologies 
> for most, but not all code.
>
> Missing license:
> examples/kintercept.py:# Copyright (c) 2019 Isaac Boukris 
> impacket/examples/remcomsvc.py:# Copyright (c) 2006 Talha Tariq [ 
> talha.ta...@gmail.com ]
> iimpacket/krb5/asn1.py:# Copyright (c) 2013, Marc Horowitz
> impacket/krb5/types.py:# Copyright (c) 2013, Marc Horowitz
> impacket/krb5/crypto.py:# Copyright (C) 2013 by the Massachusetts Institute 
> of Technology.
> impacket/smb.py:# Copyright (C) 2001 Michael Teo 
> tests/htmlcov/jquery.hotkeys.js: * Copyright 2010, John Resig
> tests/htmlcov/jquery.ba-throttle-debounce.min.js: * Copyright (c) 2010 
> "Cowboy" Ben Alman
> tests/dot11/test_wps.py:# Copyright (c) 2003-2013 CORE Security Technologies
>
> Missing copyright attribution
> impacket/dcerpc/v5/even6.py:# Copyright (c) 2017 @MrAnde7son
>
> Scott K
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

-- 
Cheers,
Emmanuel Arias
@eamanu
https://eamanu.com




signature.asc
Description: OpenPGP digital signature

Bug#942176: libsane: Canon LiDE 220 works up to 1200 dpi only

[Philipp Klaus Krause]

Package: libsane
Version: 1.0.27-3.2
Severity: normal

I use xsane, started from GIMP with a Canon LiDE 220.

It works fine at resolutions up to 1200 dpi.

When I choose 2400 dpi or 4800 dpi, the following happens:

xsane hangs for a while. Sometimes, after a short or long wait (trying to scan
an area of 1 cm by 2 cm at 4800 dpi, there was a hang of 20 min before the
messagea appeared) , I get an error message "Konnte Scanner nicht starten:
Ungültiges Argument" (German for: could not start scanner, invalid argument) or
"Konnte Scanner nicht starten: Fehler während Geräte I/O" (German for: could
not start scanner, error during device I/O).
Afterwards further scans at low resolutions also give the error message. After
retsarting xsane, I can scan at resolutions up to 1200 dpi again.

According to the manufacturer of the scanne, Canon, the LiDE supports up to
4800 dpi. However, there is a footnote "When scanning in high resolution, the
scan size is restricted." in their device description, and Windows users indeed
report that he Scanner won't let them scan large areas at full resolution.

If this is really a hardware restriction that cannot be worked around it seems
sane should:

1) Allow scans of small areas at 2400 and 4800 dpi
2) Immediately give an informative error message when attempting to scan large
areas at 2400 or 4800 dpi.



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

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

Versions of packages libsane depends on:
ii  acl2.2.53-5
ii  adduser3.118
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.29-2
ii  libgphoto2-6   2.5.22-3
ii  libgphoto2-port12  2.5.22-3
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libsane-common 1.0.27-3.2
ii  libsnmp30  5.7.3+dfsg-5
ii  libssl1.1  1.1.1c-1
ii  libtiff5   4.0.10+git191003-1
ii  libusb-1.0-0   2:1.0.23-1
ii  udev   242-7

Versions of packages libsane recommends:
pn  sane-utils  

Versions of packages libsane suggests:
ii  avahi-daemon  0.7-4+b1
pn  hplip 

-- no debconf information

Bug#942175: virtualbox: missing UnattendedTemplates

[Dmitry Mikhirev]

Package: virtualbox
Version: 6.0.12-dfsg-1
Severity: normal

Dear maintainer,

the `vboxmanage unattended install` comaand is unusable because it fails
to find kickstart/preseed templates.

% vboxmanage unattended install centos8 --iso 
/home/dmitry/iso/CentOS-8-x86_64-1905-boot.iso
VBoxManage: info: Preparing unattended installation of RedHat_64 in machine 
'centos8' (65c40358-d75f-4413-879e-f0fb72e143c8).
VBoxManage: error: Failed to open 
'/usr/share/virtualbox/UnattendedTemplates/redhat67_ks.cfg' 
(VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), 
component UnattendedWrap, interface IUnattended, callee nsISupports
VBoxManage: error: Context: "Prepare()" at line 1793 of file 
VBoxManageMisc.cpp

Please add templates to the package.

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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-4
ii  libdevmapper1.02.12:1.02.155-3
ii  libgcc1   1:8.3.0-6
ii  libgl11.1.0-1
ii  libgsoap-2.8.75   2.8.75-1
ii  libopus0  1.3-1
ii  libpng16-16   1.6.36-6
ii  libpython3.7  3.7.3-2
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5opengl5 5.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1d-0+deb10u1
ii  libstdc++68.3.0-6
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx6   1.8.1-2
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2
ii  virtualbox-dkms [virtualbox-modules]  6.0.12-dfsg-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages virtualbox recommends:
ii  libxcb11.13.1-2
ii  virtualbox-qt  6.0.12-dfsg-1

Versions of packages virtualbox suggests:
ii  vde22.3.2+r586-2.2
pn  virtualbox-guest-additions-iso  

-- no debconf information

Bug#942174: qgit: Please packaging upstream new version (2.9)

[Boyuan Yang]

Source: qgit
Severity: normal
X-Debbugs-CC: w...@debian.org

Dear qgit maintainer,

QGit upstream released new version (2.9) on Aug 2019:

https://github.com/tibirna/qgit/releases/tag/qgit-2.9

Please consider packaging it in Debian.

Thanks,
Boyuan Yang


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

Bug#942173: firmware-amd-graphics: seg fault with ati picasso grafic card and libqt5 software

[Claudia Neumann]

Package: firmware-amd-graphics
Version: 20190717-2~bpo10+1
Severity: important



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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.133+deb10u1

-- no debconf information

program using libqt5 crashes, see crash report.
The same program has no problems on debian buster with intel grafic cards or 
older 
ati grafic cards. 
The same problem occurs with certain nvidia grafic cards.


grafic card:
45: PCI 2a00.0: 0300 VGA compatible controller (VGA)
  [Created at pci.386]
  Unique ID: CvqU.ZnnDY2ASNb1
  Parent ID: JZZT.A_VqgZKlSp2
  SysFS ID: /devices/pci:00/:00:08.1/:2a:00.0
  SysFS BusID: :2a:00.0
  Hardware Class: graphics card
  Model: "ATI Picasso"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x15d8 "Picasso"
  SubVendor: pci 0x1462 "Micro-Star International Co., Ltd. [MSI]"
  SubDevice: pci 0x7b84 
  Revision: 0xc8
  Driver: "amdgpu"
  Driver Modules: "amdgpu"
  Memory Range: 0xe000-0xefff (ro,non-prefetchable)
  Memory Range: 0xf000-0xf01f (ro,non-prefetchable)
  I/O Ports: 0xe000-0xefff (rw)
  Memory Range: 0xfcb0-0xfcb7 (rw,non-prefetchable)
  Memory Range: 0x000c-0x000d (rw,non-prefetchable,disabled)
  IRQ: 71 (451696 events)
  Module Alias: "pci:v1002d15D8sv1462sd7B84bc03sc00i00"
  Driver Info #0:
Driver Status: amdgpu is active
Driver Activation Cmd: "modprobe amdgpu"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #32 (PCI bridge)

crash report:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x711cc700 (LWP 6135)]
[New Thread 0x7fffe9f17700 (LWP 6136)]
[New Thread 0x7fffe3fff700 (LWP 6138)]

Thread 1 "hbftp64.unx" received signal SIGSEGV, Segmentation fault.
0x7fffd90d9a21 in ?? () from /lib/x86_64-linux-gnu/libLLVM-7.so.1
#0  0x7fffd90d9a21 in ?? () from /lib/x86_64-linux-gnu/libLLVM-7.so.1
#1  0x7fffd8f646f4 in llvm::ManagedStaticBase::RegisterManagedStatic(void* 
(*)(), void (*)(void*)) const () from /lib/x86_64-linux-gnu/libLLVM-7.so.1
#2  0x7fffd90d90df in llvm::PassRegistry::getPassRegistry() () from 
/lib/x86_64-linux-gnu/libLLVM-7.so.1
#3  0x7fffd90d1134 in 
llvm::PassNameParser::PassNameParser(llvm::cl::Option&) () from 
/lib/x86_64-linux-gnu/libLLVM-7.so.1
#4  0x7fffd8e585c3 in ?? () from /lib/x86_64-linux-gnu/libLLVM-7.so.1
#5  0x77fe437a in ?? () from /lib64/ld-linux-x86-64.so.2
#6  0x77fe4476 in ?? () from /lib64/ld-linux-x86-64.so.2
#7  0x77fe82d3 in ?? () from /lib64/ld-linux-x86-64.so.2
#8  0x762cbb2f in _dl_catch_exception () from 
/lib/x86_64-linux-gnu/libc.so.6
#9  0x77fe7bba in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x77e27256 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#11 0x762cbb2f in _dl_catch_exception () from 
/lib/x86_64-linux-gnu/libc.so.6
#12 0x762cbbbf in _dl_catch_error () from 
/lib/x86_64-linux-gnu/libc.so.6
#13 0x77e27975 in ?? () from /lib/x86_64-linux-gnu/libdl.so.2
#14 0x77e272e6 in dlopen () from /lib/x86_64-linux-gnu/libdl.so.2
#15 0x7fffe80c1919 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#16 0x7fffe80c9ce7 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#17 0x7fffe80b6859 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#18 0x7fffe80b1f64 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#19 0x7fffe80b297d in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#20 0x724b99c0 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#21 0x72386358 in QXcbWindow::create() () from 
/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#22 0x7237139e in QXcbIntegration::createPlatformWindow(QWindow*) const 
() from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#23 0x7720d565 in QWindowPrivate::create(bool, unsigned long long) () 
from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x76644b6d in QWidgetPrivate::create_sys(unsigned long long, bool, 
bool) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x766451ad in QWidget::create(unsigned long long, bool, bool) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#26 0x76651ff3 in QWidget::setVisible(bool) () from 
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#27 0x55642f49 in hb_vmSend (uiParams=) at 
../../../hvm.c:6115
#28 0x55640552 in hb_vmExecute (pCode

Bug#942158: rdate: packaging needs a new licensing

[Eriberto Mota]

Control: severity 942158 important

Em qui, 10 de out de 2019 às 23:48, Thiago Andrade Marques
 escreveu:
>
> Package: rdate
> Severity: normal
>
> Hi all,
>
> To support packaging interaction with upstream (BSD-4-Clause),
> Rdate needs licensing to be changed from 'GPL-2+' to 'BSD-3-Clause'.
>
>
> I am opening this bug with a CC to all previous Rdate maintainers in Debian to
> ask if someone has any objection to change the licensing in Debian packaging
> (to 'BSD-3-Clause'). In my opinion, this is the best option to interact
> with the upstream.
>
> I will wait 10 days to know if anyone has any objection.
>
> Thanks!
>
> Regards,
>
> Thiago Andrade


Hi Thiago,

Thank you for your concern with rdate.

I agree with the licensing changes.

Cheers,

Eriberto

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

[root]

Package: clamav-daemon
Version: 0.101.4+dfsg-0+deb8u1
Severity: normal

Dear Maintainer,

I've just upgraded ClamAV on jessie, but clamav does not restart. On log i
get:

  Oct 11 09:02:40 ibrsamba clamd[28918]: Fri Oct 11 09:02:40 2019 -> !LOCAL: 
Socket file /var/run/clamav/clamd.ctl could not be bound: Permission denied
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Main process 
exited, code=exited, status=1/FAILURE
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Unit entered 
failed state.
  Oct 11 09:02:40 ibrsamba systemd[1]: clamav-daemon.service: Failed with 
result 'exit-code'.

Looking at clamav run folder:

ibrsamba:~# ls -la /var/run/clamav/
totale 0
drwxr-xr-x  2 root root   40 ott 11 09:01 .
drwxr-xr-x 33 root root 1060 set 13 12:14 ..

doing simply:

chown clamav /var/run/clamav

permit me to correctly restart clamav. Now:

ibrsamba:~# ls -la /var/run/clamav/
totale 0
drwxr-xr-x  2 clamav root 60 ott 11 12:57 .
drwxr-xr-x 33 root   root   1060 set 13 12:14 ..
srw-rw-rw-  1 clamav clamav0 ott 11 12:57 clamd.ctl

Thanks.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog = "yes"
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
ScanOnAccess disabled
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPPr

Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2

[Thierry fa...@linux.ibm.com]

Source: tcpdump
Version: 4.9.3-1
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=tcpdump&arch=ppc64el&suite=sid

--- 1 tests failed 441 tests 
passed Failed test: ikev2pI2 41c41 < (v2auth: len=196 method=rsasig 
authdata=() 
)) --- > (v2auth: len=196 method=rsasig 
authdata=(9d7686de6fabda36c4b374135ccca0c4596fe7636e19ee71ea7d276b4230948ab529651ba1dbec39e85e506ff90b48a57611be386a5867beccde9c9971587907251df58f0c46b473d9f0abc308eb85482f08383d) 
))



This is similar to bug #873377 which was supposed to be fixed in V 
4.9.1-2 - logs show that for v4.9.1-2 and -3 test was not run - then it 
was failing but not reported as an error for the global count of success !

Bug#942170: Update node-buble to a version compatible with acorn 6

[Pirate Praveen]

Package: node-buble
version: 0.19.4-3
Severity: important
Control: block 942169 by -1

node-acorn 6 is in experimental and rollup 1.0 will soon be uploaded to 
experimental. Some packages using node-buble failed to build with this 
error. Other packaged like node-uri-js, node-d3-color etc which does 
not use buble built fine.

Bug#942169: Update rollup to 1.0

[Pirate Praveen]

Package: rollup
Version: 0.68.2-2
Control: block 911367 by -1

I have started the update process in master-1.0 branch.

Bug#911367: [Pkg-javascript-devel] Bug#911367: New upstream is out

[Pirate Praveen]

Control: retitle -1 "Update node-acorn to 6.x"

On Sat, 20 Oct 2018 16:46:55 +0200 Bastien ROUCARIES
 wrote:
> Note that it will need a hug testing due to change of API for plugins.

I have started updating rollup to 1.0.2 in (master-1.0 branch), which
switches to acorn 6.

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

[Thierry fa...@linux.ibm.com]

Changing on file side is not enough as there a couple of file impacted
 > g++ -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security --std=gnu++11 
-I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I/usr/include  -I/usr/include/libxml2 -L/lib -fopenmp 
-D_GLIBCXX_PARALLEL  -pipe  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security --std=gnu++11 
-c -o backend/filters/algorithms/3Depict-spatial.o `test -f 
'backend/filters/algorithms/spatial.cpp' || echo 
'./'`backend/filters/algorithms/spatial.cpp

In file included from /usr/include/qhull/qhull_a.h:28,
 from backend/filters/algorithms/spatial.cpp:30:
/usr/include/qhull/libqhull.h:46:30: error: operator '&&' has no right operand
   46 | #if __MWERKS__ && __POWERPC__
  |  ^



and included files are not common !

Bug#942164: wpasupplicant: WiFi not working on FT or enterprise networks (CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00)

[Andrej Shadura]

Hi,

On Fri, 11 Oct 2019 at 09:40, Matteo Fortini  wrote:
> Thank you for you ack.
>
> Yes I can connect to "other" networks, but it's not easy not to be able to 
> connect: at home, at work, at my town's free wifi, just to give some 
> examples. In two of the three cases, I have no power to do anything.
>
> This is a log with debug switched on: https://pastebin.com/XxA20Pwy
>
> If there is anything I can do to help, I am more than willing to try it.
>
> The issue has been here for almost a month.

What is your hardware? What is the latest version of wpa-supplicant that worked?

-- 
Cheers,
  Andrej

Bug#893665: #893665 smartmontools: smartd doesn't notice newly added devices afters start

[Dmitry Smirnov]

I've made a quick proof-of-concept file

/etc/udev/rules.d/90-smartmontools-hotplug.rules

with the following content:

SUBSYSTEM=="block", RUN+="/usr/bin/pkill -HUP smartd"

and it seems to work.

"pkill" command is provided by "procps" package.

It is a rather naive idea of rescan and it can probably be improved but it is 
something for a start.

-- 
Regards,
 Dmitry Smirnov

---

Good luck happens when preparedness meets opportunity.


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

Bug#942137: postgresql-common: strech/buster upgrades fail with error 'invalid value for parameter "lc_time"'

[Jean-Michel Vourgère]

Control: tag -1 - moreinfo

Hi Christoph

My English locale en_GB.UTF-8 is working fine. It is my default locale, 
defined either at installation, or by dpkg-reconfigure locales.

Each time I do a major Debian dist-upgrade (7/8, 8/9 and 9/10), I get many 
such perl warnings. It has never been a real issue, but for the flood of my 
terminal.

Attached is the beginning of my term.log and my /etc/postgresql/9.6/main/
postgresql.conf.

You'll notice that packages locales and perl-modules are unpacked really 
early, but are configured later. These annoying warnings stops when they are 
configured.

You'll notice that I have:
lc_messages = 'en_GB.UTF-8' # locale for system error message
# strings
lc_monetary = 'en_GB.UTF-8' # locale for monetary formatting
lc_numeric = 'en_GB.UTF-8'  # locale for number formatting
#lc_time = 'en_GB.UTF-8' # locale for time formatting


The only problem is lc_time. One must comment out the line for postgres9.6 to 
start during the dist-upgrade. The other lines like lc_messages, lc_monetary 
and lc_numeric are not a problem.

I upgraded 5 different postgresql servers, and I had to edit the 
postgresql.conf in the middle of the update on all 5 of them! Not doing so 
causes the whole dist-upgrade to fail with other nastier side-effect. This is 
not an isolated issue!

You suggested that I redo a "dpkg-reconfigure locales". I don't think I could 
do that in the middle of a dist-upgrade! I assure you that my locale is 
working fine before and after the upgrade, even if it's broken during the 
dist-upgrade!

You can very probably reproduce the problem by installing a stretch using 
locale en_GB.UTF-8, then install postgres (You should then get a 
lc_time='en_GB.UTF-8' in postgresql.conf) and libnss, then do a dist-upgrade 
accepting all automatic restarts when required.

Fell free to tell me how I can help to pinpoint the issue.Log started: 2019-10-10  19:09:28
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 73431 files and directories currently installed.)
Preparing to unpack .../libc-l10n_2.28-10_all.deb ...
Unpacking libc-l10n (2.28-10) over (2.24-11+deb9u4) ...
Preparing to unpack .../locales_2.28-10_all.deb ...
Unpacking locales (2.28-10) over (2.24-11+deb9u4) ...
dpkg: systemd-shim: dependency problems, but removing anyway as you requested:
 libpam-systemd:amd64 depends on systemd-shim (>= 10-3~) | systemd-sysv; however:
  Package systemd-shim is to be removed.
  Package systemd-sysv is not installed.

(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 73450 files and directories currently installed.)
Removing systemd-shim (10-3) ...
Removing 'diversion of /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service to /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.systemd by systemd-shim'
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on systemd-sysv | sysvinit-core; however:
  Package systemd-sysv is not installed.
  Package sysvinit-core is to be removed.

Removing sysvinit-core (2.88dsf-59.9) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 73417 files and directories currently installed.)
Preparing to unpack .../systemd-sysv_241-7~deb10u1_amd64.deb ...
Unpacking systemd-sysv (241-7~deb10u1) ...
Setting up systemd-sysv (241-7~deb10u1) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading databa

Bug#941124: [Pkg-erlang-devel] Bug#941124:

[Evgeny Golyshev]

> If you don't mind, I could make a NMU with these changes (the NMU diff
> is attached).
>

Yes, please, make a NMU with the changes you suggested.
Thank you.

Evgeny

Bug#942168: system-config-printer: Verifying set authentication on SAMBA printer installation fails due to forced Kerberos use

[Antonio Cebrián]

Package: system-config-printer
Version: 1.5.11-4

Verifying set authentication on SAMBA printer installation fails due to
forced Kerberos use in "newprinter.py" file:

if auth_set:
# No prompting.
def do_auth (svr, shr, wg, un, pw):
return (group, user, passwd)
ctx = pysmb.smbc.Context (debug=debug, auth_fn=do_auth)
try:
ctx.optionUseKerberos = True
except AttributeError:
# requires pysmbc >= 1.0.12
pass

f = ctx.open ("smb://%s/%s" % (host, share),
  os.O_RDWR, 0o777)
accessible = True
else:
# May need to prompt.

Related console messages:

Kinit for myuser@MYDOMAIN to access MYSERVER failed: Cannot contact any KDC
for requested realm
Caught non-fatal exception.  Traceback:
File "/usr/share/system-config-printer/newprinter.py", line 2861, in on_
btnSMBVerify_clicked
os.O_RDWR, 0o777)
smbc.PermissionError: (13, 'Permission denied')
Continuing anyway..


Disabling Kerberos use solves the problem and allows installation and
printing on the SAMBA printer:

sudo sed -i -e 's/ctx.optionUseKerberos = True/ctx.optionUseKerberos =
False/' /usr/share/system-config-printer/newprinter.py


Perhaps adding a checkbox to the "New Printer" dialog to allow
enable/disable of Kerberos use will be the best solution.

Best regards.

Bug#862908: #862908 smartd fails to start when no disks are present

[Dmitry Smirnov]

Thorsten, upstream suggested to pass "-q never" to smartd.

I verified that the daemon starts on system without disks
with 

smartd_opts="-q never"

in "/etc/default/smartmontools".

I hope it helps.

-- 
Cheers,
 Dmitry Smirnov

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#725884: hdparm: Standby (spindown) timeout option (-S) has no effect

[Alex Mestiashvili]

On 6/30/19 2:31 PM, Alex Mestiashvili wrote:
> On 3/10/19 10:41 PM, Stijn Segers wrote:
>> Hi,
>>
>> I recently experienced the same issue here. Until Debian Stretch everything 
>> was fine, but I recently upgraded to Debian Buster (pre-release). I 
>> previously just set the spindown time and this used to work fine. Hdparm -Y 
>> on the devices (using the plain /dev/sd? paths) still worked, but automatic 
>> spindown was somehow broken. I tried enabling APM (setting it to 127) but 
>> that didn't change a thing - I previously only set spindown time and that 
>> worked just fine. I then switched to /dev/disk/by-id/ paths, that didn't 
>> work either.
>>
>> What I have noticed, however, is that spindown_time settings up to 59 work; 
>> anything from 60 (5 minutes) and up won't. Hope this helps.
>>
>> Cheers
>>
>> Stijn
>>
> 
> Hi,
> I just have managed to set the spindown for apm 60 and 100. Both worked.
> There is a trick though. After setting the spindown_time (-S) one
> actually need to run hdparm -C /dev/sdX twice as the very first time
> hdparm -C returns an old value for the disk - active/idle, but the
> second time it returns that the drive is in standby mode.
> 
> Also there are no APM related changes as far as I see in the code
> diff[0] between hdparm 9.51 in Stretch and 9.58 in Buster. What have
> also changed is udev and kernel versions.
> One can try to test a stretch machine where all presumably worked and
> update hdparm and then udev (available via stretch-backports) to nail
> down the problem.
> 
> Best,
> Alex
> 
> [0]
> https://salsa.debian.org/debian/hdparm/compare/debian%2F9.51+ds-1...upstream%2F9.58+ds
> 

The problem is most likely caused by smartd or udisksd which poll drives
regularly. Please see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930796#42

Bug#925518: Your company and Recovhub

[brandon . welsh]

Hello planet.ubuntu.com,

My name is Brandon Welsh, i'm the founder of www.recovhub.com the first
nationwide listing directory that's used as a portal for treatment centers
to login and view patient leads and V.O.B.s ( verification of benefits )
anytime an individual submits their insurance policy on a treatment centers
listing.

Recovhub streamlines the intake and admissions process in substance abuse
treatment and allows individuals to locate help nationwide for all levels
of care. I thought I would reach out since Recovhub could potentially help
those reading this article and with hopes you would also link to us at
recovhub.com !

You may already be listed on the Recovhub website, if you're on Recovhub
make sure your listing is up to date by visiting listings.recovhub.com to
create an account and manage your listings. As a startup company working to
provide a better way of conducting business for the addiction treatment
industry, it would be greatly appreciated it if you linked to us and helped
to provide the resource bringing patients and providers together direct and
in an ethical process.

Thank You for taking the time to read this email and we look forward to
hearing from you soon!

Team Recovhub

supp...@recovhub.com
310-795-0909

-- 
Copyright 2019 Recovhub, Inc. All Rights Reserved 
Recovhub
18626 Knapp St. 
Los Angeles, CA 91324
+1 (800) 381-8603
supp...@recovhub.com 



This document may contain sensitive and 
confidential information along with any and all mail herein or attached 
hereto, therefor this document is strictly and solely meant for the 
recipient of intended delivery. Upon reading this document, if you’re not 
the sole intended recipient, please notify sender of this document 
immediately. When informing Recovhub of this document and delivery upon 
error, please delete any and all copies of this document, any and all 
attachments belonging to or part of this document and immediately cease and 
decis of any and all copies of this document. 


Parts of this document may 
contain private, sensitive and confidential patient information (HIPPAA CF 
45) and any use of this document and or the communication herein or 
attached hereto in any form other than the sole purpose originally intended 
is strictly prohibited and may be punishable by law. 


Recovhub will 
pursue any and all damages, costs pertaining to and other monies deemed 
related to the misuse and neglect of this communication herein the document 
deemed sensitive and confidential property of Recovhub Inc. a California 
Corporation with principal address of 18626 Knapp St. Los Angeles, CA 
90046. Recovhub will seek fines and fees owed to the fullest extent legally 
allowed and permissible by state or federal law. Any trademarks used in 
this communication are owned by their respective partys and are not to be 
copied, reproduced and or used without prior written consent. 


RECOVHUB | 
PATENT PENDING | COPYRIGHT 2017-19 RECOVHUB, INC. All Rights Reserved

-- 
Copyright 2019 Recovhub, Inc. All Rights Reserved 
Recovhub
18626 Knapp St. 
Los Angeles, CA 91324
+1 (800) 381-8603
supp...@recovhub.com 



This document may contain sensitive and 
confidential information along with any and all mail herein or attached 
hereto, therefor this document is strictly and solely meant for the 
recipient of intended delivery. Upon reading this document, if you’re not 
the sole intended recipient, please notify sender of this document 
immediately. When informing Recovhub of this document and delivery upon 
error, please delete any and all copies of this document, any and all 
attachments belonging to or part of this document and immediately cease and 
decis of any and all copies of this document. 


Parts of this document may 
contain private, sensitive and confidential patient information (HIPPAA CF 
45) and any use of this document and or the communication herein or 
attached hereto in any form other than the sole purpose originally intended 
is strictly prohibited and may be punishable by law. 


Recovhub will 
pursue any and all damages, costs pertaining to and other monies deemed 
related to the misuse and neglect of this communication herein the document 
deemed sensitive and confidential property of Recovhub Inc. a California 
Corporation with principal address of 18626 Knapp St. Los Angeles, CA 
90046. Recovhub will seek fines and fees owed to the fullest extent legally 
allowed and permissible by state or federal law. Any trademarks used in 
this communication are owned by their respective partys and are not to be 
copied, reproduced and or used without prior written consent. 


RECOVHUB | 
PATENT PENDING | COPYRIGHT 2017-19 RECOVHUB, INC. All Rights Reserved

Bug#941638: autopkg tests still rely on removed python-schema

[Andreas Tille]

Hi,

since I have no permissions to push my patches feel free to
git am the attachments from my NMU.

Kind regards

   Andreas.

-- 
http://fam-tille.de
>From 27ed7d0257f4487b2ef24709f5d7e87ecf2c66ba Mon Sep 17 00:00:00 2001
From: Andreas Tille 
Date: Fri, 11 Oct 2019 11:33:38 +0200
Subject: [PATCH 1/2] Don't run the Python2 autopkg tests. python-schema is
 gone

---
 debian/changelog  | 9 +++--
 debian/tests/control  | 2 --
 debian/tests/run_examples | 4 
 debian/tests/unittests| 1 -
 4 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 2b3e3b3..c4967ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,13 @@
-docopt (0.6.2-3) UNRELEASED; urgency=medium
+docopt (0.6.2-2.1) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
 
- -- Ondřej Nový   Mon, 01 Oct 2018 09:41:53 +0200
+  [ Matthias Klose ]
+  * Don't run the Python2 autopkg tests. python-schema is gone
+Closes: #941638
+
+ -- Andreas Tille   Fri, 11 Oct 2019 11:32:39 +0200
 
 docopt (0.6.2-2) unstable; urgency=medium
 
diff --git a/debian/tests/control b/debian/tests/control
index db53506..36cbce3 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -2,5 +2,3 @@ Tests: unittests, run_examples
 Depends: @,
  python3-pytest,
  python3-schema,
- python-pytest,
- python-schema,
diff --git a/debian/tests/run_examples b/debian/tests/run_examples
index e2340b4..2ea740d 100644
--- a/debian/tests/run_examples
+++ b/debian/tests/run_examples
@@ -1,7 +1,3 @@
 for file in $(ls examples/*.py); do
 python3 $file -h
 done
-
-for file in $(ls examples/*.py); do
-python $file -h
-done
diff --git a/debian/tests/unittests b/debian/tests/unittests
index 1740e64..360e4e8 100644
--- a/debian/tests/unittests
+++ b/debian/tests/unittests
@@ -1,2 +1 @@
 pytest-3
-pytest
-- 
2.23.0

>From deed149e061dd64adb7ea78134a81240681e5230 Mon Sep 17 00:00:00 2001
From: Andreas Tille 
Date: Fri, 11 Oct 2019 11:35:56 +0200
Subject: [PATCH 2/2] Upload to unstable

---
 debian/changelog | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c4967ab..8aabf7e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,6 @@
-docopt (0.6.2-2.1) UNRELEASED; urgency=medium
+docopt (0.6.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
 
   [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
@@ -7,7 +9,7 @@ docopt (0.6.2-2.1) UNRELEASED; urgency=medium
   * Don't run the Python2 autopkg tests. python-schema is gone
 Closes: #941638
 
- -- Andreas Tille   Fri, 11 Oct 2019 11:32:39 +0200
+ -- Andreas Tille   Fri, 11 Oct 2019 11:34:05 +0200
 
 docopt (0.6.2-2) unstable; urgency=medium
 
-- 
2.23.0

Bug#942167: RFS: okasha/0.2.4-4 [RC]

[Ahmed El-Mahmoudy]

Package: sponsorship-requests
Severity: important
 
Hello,

Please sponsor the updated package okasha 0.2.4-4.

It fixes the following RC bug:
#940198 (serious): python3-okasha-examples: missing Breaks+Replaces: 
python-okasha-examples

The latest entry in the Debian changelog is:

okasha (0.2.4-4) unstable; urgency=medium

  * Add Breaks+Replaces: python-okasha-examples (Closes: #940198)
  * py3.diff: add fix for string + utf8 concatenation


As required, I tested the package against unstable's version of lintian and it
it reports:
I: okasha source: testsuite-autopkgtest-missing


To access further information about this package, please visit the 
following URL:
 
   https://mentors.debian.net/package/okasha

Alternatively, it is available on Salsa:
g...@salsa.debian.org:python-team/modules/okasha.git

also, one can download the package with dget using this command:
 
dget -x 
https://mentors.debian.net/debian/pool/non-free/o/okasha/okasha_0.2.4-4.dsc

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#941124: [Pkg-erlang-devel] Bug#941124:

[Sergei Golovan]

Hi Evgeny,

On Tue, Oct 1, 2019 at 1:27 PM Evgeny Golyshev  wrote:
>
> Hello everyone
>
> I maintain Elixir in Debian.
> Obviously the compatibility between the Erlang's versions has been
> broken. I did a small research and found out that failing autopkgtest
> is the result of Erlang's :re module. Unfortunately, I can't provide
> details for the problem because a deeper study of it can take a lot of
> time which I don't have so far.
> Also I can confirm that rebuilding Elixir against the newest Erlang
> fixes the problem.

I'd like to propose a fix for this bug. It adds a dependency on newly
introduced virtual package erlang-pcre-, which will help to
notice when PCRE is changed.

The patch also utilises ${erlang:Depends} which calculates the dependencies
automatically. By the way, it appears that elixir should depend not only
on erlang-base, but also on a few other erlang related packages (erlang-crypto,
erlang-inets etc.)

If you don't mind, I could make a NMU with these changes (the NMU diff
is attached).

Cheers!

--
Sergei Golovan


elixir-lang_1.9.1dfsg-1.1.nmu.diff
Description: Binary data

Bug#942064: profphd: autopkgtest failure

[Dominique Dumont]

On Thu, 10 Oct 2019 23:18:29 +0200 gregor herrmann  wrote:
> Looking a bit further, this doesn't seem to affect only the
> autopkgtest because:
> 
> % grep -r '\$\[' | wc -l
> 1099
> 
> I mean, it might be possible to just remove '$[ = 1;' eleven hundred
> times and see what happens if all arrays are based on 0 instead of 1
> but I don't know.
> (I also noted that prof.pl had $[ set although I haven't seen an
> array in the whole script …)

Another interesting count is the number of times a numeric index is used with 
an array (array ref are not used in there):

$ ack '\$\w+\[\d' | wc -l
833

To be compared with the number of times an array is used with a variable:
$ ack '\$\w+(->)?\[\$' |wc -l
2045

Fortunately, these should not be changed. But how these variables are 
initialized may be a problem

For instance $it and $ct variable are often used as iterator. Let's see how 
many times they are initialized with 1 or with a digit:

$ ack '\$(it|ct)\w+\s*=1\b'  | wc -l
29

$ ack '\$(it|ct)\w+\s*=\d' | wc -l
220

For this to improve, we'd need a set of high level tests provided by debian-
med or upstream team.

Then some change could be done with a script (removed $[=1 lines and decrement 
all numeric indexes)

Dealing with the remaining will unfortunately be a manual task.

HTH

Dod

Bug#934913: [pkg-php-pear] Bug#934913: php-easyrdf: should maybe link with librdf0 and suggest/recommend raptor2-utils

[Jonas Smedegaard]

Quoting Marco Villegas (2019-10-11 03:54:16)
> On Fri, 16 Aug 2019 15:40:17 +0200
> Jonas wrote:
> > Thanks for packaging EasyRdf!
> 
> It was definitely interesting!

Just tell me if you are interested in doing more RDF-related packaging, 
any time! :-)


> > Seems other tools are optionally used as well - including graphviz.

Did you see last sentence above? graphviz is definitly in Debian.


 - 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#942118: marked as pending in smartmontools

[Dmitry Smirnov]

On Friday, 11 October 2019 7:13:45 PM AEDT Thorsten Glaser wrote:
> Sorry, that doesn’t fix it

Actually it does.


> : it also doesn’t start after a reboot.

According to your log it looks like unrelated problem: #862908.

-- 
Cheers,
 Dmitry Smirnov.

---

There is no such thing as public opinion. There is only published opinion.
-- Winston Churchill


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

Bug#938677: Please check autopkgtest of (may be failed) attempt of Python3 port (Was: Bug#938677: tophat: Python2 removal in sid/bullseye)

[Andreas Tille]

Hi,

I tried to use 2to3 to port tophat to Python3 in Git[1].  Unfortunately
the autopkgtest fails with:


autopkgtest [09:04:13]: test run-unit-test: [---

[2019-10-11 09:04:13] Beginning TopHat run (v2.1.1)
---
Traceback (most recent call last):
  File "/usr/bin/tophat", line 4106, in 
sys.exit(main())
  File "/usr/bin/tophat", line 3898, in main
run_log = open(logging_dir + "run.log", "w", 0)
ValueError: can't have unbuffered text I/O
autopkgtest [09:04:13]: test run-unit-test: ---]
autopkgtest [09:04:14]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 1


I'd applaude if in beginning of November if I'm back from beeing offline
if this would be fixed. :-)

Kind regards

 Andreas.

[1] https://salsa.debian.org/med-team/tophat

-- 
http://fam-tille.de

Bug#941202:

[Daniel Cadden]

Thank you.
Will this be fixed for Stretch?

-- 

Bug#942118: marked as pending in smartmontools

[Thorsten Glaser]

Control: reopen -1

Dmitry Smirnov dixit:

>SysV: don't (re)start daemon during upgrade (Closes: #942118).

Sorry, that doesn’t fix it: it also doesn’t start after a reboot.

root@ci-busyapps:~ # service smartmontools start
Starting S.M.A.R.T. daemon: smartd failed!

syslog has:

Oct 11 08:13:00 ci-busyapps smartd[28543]: smartd 7.0 2018-12-30 r4883 
[x86_64-linux-5.2.0-3-amd64] (local build)
Oct 11 08:13:00 ci-busyapps smartd[28543]: Copyright (C) 2002-18, Bruce Allen, 
Christian Franke, www.smartmontools.org
Oct 11 08:13:00 ci-busyapps smartd[28543]: Opened configuration file 
/etc/smartd.conf
Oct 11 08:13:00 ci-busyapps smartd[28543]: Drive: DEVICESCAN, implied '-a' 
Directive on line 21 of file /etc/smartd.conf
Oct 11 08:13:00 ci-busyapps smartd[28543]: Configuration file /etc/smartd.conf 
was parsed, found DEVICESCAN, scanning devices
Oct 11 08:13:00 ci-busyapps smartd[28543]: In the system's table of devices NO 
devices found to scan
Oct 11 08:13:00 ci-busyapps smartd[28543]: Unable to monitor any SMART enabled 
devices. Try debug (-d) option. Exiting...

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

Bug#942166: RFP: malcontent -- library for parental control of applications

[Simon McVittie]

Package: wnpp
Severity: wishlist

* Package name: malcontent
  Version : 0.4.0
  Upstream Author : Philip Withnall / Endless
* URL : https://gitlab.freedesktop.org/pwithnall/malcontent
* License : LGPL-2.1+
  Programming Lang: C with GObject
  Description : library for parental control of applications

malcontent implements support for restricting the type of content
accessible to non-administrator accounts on a Linux system. Typically,
when this is used, a non-administrator account will be for a child using
the system; and the administrator accounts will be for the parents;
and the content being filtered will be apps which are not suitable for
the child to use, due to (for example) being too violent.

This is not a security boundary, and a sufficiently technically advanced
user may always work around these parental controls. malcontent is not a
mandatory access control (MAC) system like AppArmor or SELinux. However,
its correct use by applications should provide enough of an obstacle
to prevent users easily or accidentally having access to content which
they shouldn’t.



Flatpak 1.5.1+ will optionally use this library to check for permission
to install and run apps. I don't intend to package or maintain it myself,
but if someone else maintains it, I'm willing to enable the dependency
in Flatpak.

Presumably other projects, such as GNOME Shell, will gain a similar
optional dependency.

Bug#942165: CVE-2019-14857

[Moritz Muehlenhoff]

Package: libapache2-mod-auth-openidc
Severity: grave
Tags: security

Please see: https://groups.google.com/forum/#!topic/mod_auth_openidc/boy1Ba3Gdk4

https://github.com/zmartzone/mod_auth_openidc/commit/5c15dfb08106c2451c2c44ce7ace6813c216ba75
https://github.com/zmartzone/mod_auth_openidc/commit/ce37080c6aea30aabae8b4a9b4eea7808445cc8e
https://github.com/zmartzone/mod_auth_openidc/pull/451

Cheers,
Moritz