Bug#893684: libslf4j-java: CVE-2018-8088: Deserialisation vulnerability in EventData constructor can allow for arbitrary code execution

[Salvatore Bonaccorso]

Source: libslf4j-java
Version: 1.7.25-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://jira.qos.ch/browse/SLF4J-430
Control: found -1 1.7.7-1

Hi,

the following vulnerability was published for libslf4j-java.

CVE-2018-8088[0]:
| org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before
| 1.8.0-beta2 allows remote attackers to bypass intended access
| restrictions via crafted data.

Unfortunately upstream does not tell us much on the security issue.
[1] itself and the subtask [2] only tells us that the EventData is
going to be marked first as deprecated (then removed) "due to a
security vulnerability" [3].

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-2018-8088
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088
[1] https://jira.qos.ch/browse/SLF4J-430
[2] https://jira.qos.ch/browse/SLF4J-430
[3] 
https://github.com/qos-ch/slf4j/commit/d2b27fba88e983f921558da27fc29b5f5d269405

Please adjust the affected versions in the BTS as needed.
that all earlier versions are affected.

Regards,
Salvatore

Bug#839695: qemu: Please build qemu with –enable-gtk

[Stefan Weil]

Hi Michael,

QEMU from buster is not usable at all with the default SDL2 user
interface. It is terribly slow (even with KVM enabled) – maybe a
deadlock problem which I have noticed with SDL2 for a long time now.

That means you should go a step further and remove not only GTK3
support, but also SDL2 support. That will be even better for headless
virtual machines.

Regards
Stefan

Bug#893476: DNS setting is not reflected in netplan yaml file when domain name is empty string

[Cyril Brulebois]

Hi,

윤영수  (2018-03-19):
> When we install ubuntu server and set DNS addresses (ex. 8.8.8.8), the
> event that the DNS setting is not reflected in netplan yaml file
> (/etc/netplan/*.yaml) may occur.
> 
> We finded that the reason is related to the source code of the network
> package 'netcfg'.
> 
> In the function 'nc_wi_netplan_write_nameservers' of write_interface.c
> of netcfg-1.142ubuntu5(netcfg package source code directory), the
> nameservers are not written in the netplan yaml file if domain name is
> empty string.
> 
> We hope that the nameservers are written even if domain name is empty
> string.

netplan support seems to be an Ubuntu-specific addition that wasn't
forwarded to Debian, and there's no trace of it in our git repository or
in our released packages.

> Please check the bug.

Please file your bug report where it belongs: in launchpad.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#860950: steam: crashes on startup

[Clayton]

> I think it can probably be closed, then?

I would say so, yes.

> > "Linux
> > 
> > 32-bit Linux distributions are also no longer supported.
> > Please install a 64-bit Linux distribution to make use of the Steam
> > browser."
> > 
> > This sounds to me like it might be the end of the road for Steam on
> > 32-bit.  
> 
> Because the Steam client is a 32-bit binary with 32-bit dependencies,
> we have to distribute it as steam:i386 anyway - otherwise its
> dependencies on libraries like libGL wouldn't work correctly.
> 
> If the embedded web browser (a separate process, I think) doesn't work
> on a pure i386 system but only on an amd64 + i386 multiarch system,
> then that isn't really something we can fix. If I remember correctly
> from using Windows Steam under Wine at a time when Wine failed to run
> the embedded web browser, the Steam client can work enough without its
> web browser to log in (during startup) and install and run games that
> were bought by using a different web browser or a different machine,
> as long as those games are themselves 32-bit; so I think "works with
> severely degraded functionality" would be a reasonable summary?

That's fair ball, TBH I will probably not even try again as in browsing
through the games library I did not see too much that would likely run
well (if at all) on an ancient machine, so I have since scrounged a
64-bit machine with a bit more oomph for permanent use as game machine.

Thanks for staying on top of steam,
Clayton

Bug#893685: Segfault after higher number of connections

[Peter Viskup]

Package: siege
Version: 4.0.2-1.1+b1

When running siege, always getting the segfault after more than 700
connections were made. Tests made on nonTLS connections with GET method
only (Debian repository URIs). Siege just stops receiving data. There are
seen high receive queues on siege side and send queues on server side.

Installing the unstable version fixed the issue (downloading deb and "dpkg
-i").

Maybe related to upstream bug https://github.com/JoeDog/siege/issues/76

Peter

Bug#879816: reopen eclipse-titan GCC dependency issue

[Matthias Klose]

reopen 879816
thanks

this upper dependency is bogus. if at all, only the major version matters, since
GCC 5.  And if eclipse-titan checks this version itself, it better should be
patched out not to check the version.

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Philipp Kern]

On 03/20/2018 10:59 PM, Luca Boccassi wrote:
> The problems I see are that it would make an already quite complex
> packaging system, over which we have very little control (most of it
> it's binary blobs) even more complicated. We already have 2 layers of
> update-alternatives (mesa vs nvidia and then current vs legacy).
> 
> It would also mean we have to start maintaining multiple versions at
> the same time - again being all binary blobs, which will multiply the
> source of problems. Basically, it would mean that instead of having
> current vs legacy340xx (up until a few months ago also legacy304xx),
> every single driver update would have to be maintained separately.

I don't propose this as the solution, though. I think that'd indeed be
infeasible. What I'm saying is that the *binary* packages are versioned
like this, not the source packages. It's like the kernel in a way, where
every ABI version gets its own binary package name. Although in Debian
the hesitance to change the ABI is much higher than in Ubuntu, for
reasons that I assume have to do with the NEW queue. Cleaning up older
versions is something we'd find a solution for, just like people clean
up their old kernels.

So please separate out maintenance from the proposal. ;-)

I get it with the two layers of alternatives. Is the reason for mesa vs.
nvidia because we don't put Nvidia into the library search path first
and need to deal with the corresponding file conflicts in a sane way? Or
because we want to keep co-installability between mesa and nvidia?

> In the end the problem is an annoyance but not a deal breaker - updates
> can be scheduled and delayed (unlike some other OSes...), and on top of
> that, version bumps are not that common - at most once a month, and
> only for those running unstable or testing - in stable we just ship LTS
> versions.

Actually it's a real deal breaker in mass deployments. If your users are
hesitant to do reboots because it resets their work environment, you
really need to detach nvidia updates from the rest of the package
updates, which means having a custom-built solution to do that. That has
turned out to be brittle, as it turns out that you end up installing
pre-downloaded modules at boot, blocking it for about ten minutes. (It
has gotten better with SSDs, but still.)

Even if you just ship LTS versions there are sometimes updates needed,
be it for Meltdown/Spectre or new hardware. In our case we actually do
use testing, but even then we had the need to push updates to drivers. I
think a setup that separates out binaries for every version that allows
for consistent rollbacks[1] and rollforwards would be beneficial not
just for us but also for the whole userbase of Debian.

We'd be willing to invest some time into a solution - as our own to work
around the flaws in the packaging has turned out to be a maintenance
headache. But that only works if we at least agree on a plan. I'm also
happy to clarify more that I probably missed in the proposal. :)

Kind regards and thanks
Philipp Kern

[1] We had a bunch of regressions with newer drivers in the past that
made them dead on arrival, like missing repaints in terminals for a
fraction of the cards.

Bug#860950: steam: should clean up partial files after a failed download

[Simon McVittie]

Control: retitle -1 steam: should clean up partial files after a failed download
Control: tags -1 - moreinfo
Control: severity -1 wishlist

On Wed, 21 Mar 2018 at 15:32:43 +0800, Clayton wrote:
> > I think it can probably be closed, then?
> 
> I would say so, yes.

Actually, there's one thing left here:

Michael Gilbert wrote:
> This looks like an incomplete download.  Try backing up your
> ubuntu12_32 folder, and execute steam again.
>
> If that works, the script will need to try to clean up after a failed
> download.

smcv

Bug#888859: RFS: iolang/2017.09.06+dfsg-1 [ITP]

[Lumin]

Control: owner -1 w...@debian.org

Hi,

I'm releasing the ownership of this bug since I'm not able to deal with
it due to work in real life.

Sorry for the inconvenience.


On 22 February 2018 at 16:05, Yangfl  wrote:
> Control: tags -1 - moreinfo
>
> On Thu, 15 Feb 2018 09:11:18 + Lumin  wrote:
>> control: owner -1 !
>> control: tags -1 +moreinfo
>>
>> Hi Yangfl,
>
> Hi Lumin,
>
> Confused I haven't received your mail via BTS. Much thanks for your
> interest and willing to sponsor.
>
>> *  URL : http://www.iolang.com
>>   Are you sure this URL is correct?
>
> Sorry, this RFS header is copied from old ITP. The one in d/control should be
>
>> Thank you for your work. Here are some comments
>> on your package.
>>
>> * -dfsg: would you please explain what is removed
>>   from original source in README.source?
>
> d/copyright should have provided a list of removed files (see Files-Excluded).
>
> By the way, I have made a PR to upstream to remove ConvertUTF and it
> has accepted. The next release will not affected by this.
>
>> * please fix the following lintian I/W/E:
>>   (reproduce with debuild -S)
>>
>> P: iolang source: insane-line-length-in-source-file docs/js/jquery.js
>> line length is 517 characters (>512)
>> P: iolang source: source-contains-prebuilt-javascript-object
>> docs/js/jquery.js line length is 517 characters (>512)
>> N: jquery
>> O: iolang source: source-is-missing docs/js/jquery.js line length is
>> 517 characters (>512)
>> P: iolang source: source-contains-prebuilt-doxygen-documentation
>> addons/SGML/source/libsgml-1.1.4/docs/html/
>> I: iolang source: quilt-patch-missing-description
>> addons-fix-missing-depends.patch
>> I: iolang source: quilt-patch-missing-description addons-no-rpath.patch
>> I: iolang source: quilt-patch-missing-description
>> libs-fix-shlib-with-executable-stack.patch
>> I: iolang source: quilt-patch-missing-description libs-soname.patch
>> I: iolang source: quilt-patch-missing-description 
>> modules-fix-atk-libname.patch
>> I: iolang source: quilt-patch-missing-description
>> modules-fix-clutter-include-dirs.patch
>> I: iolang source: quilt-patch-missing-description
>> modules-fix-openssl-wrong-variable-names.patch
>> I: iolang source: quilt-patch-missing-description modules-fix-qdbm-path.patch
>> I: iolang source: quilt-patch-missing-description modules-mariadb.patch
>> I: iolang source: quilt-patch-missing-description no-sse.patch
>> I: iolang source: quilt-patch-missing-description no-static.patch
>> E: iolang source: debian-rules-is-dh_make-template
>> I: iolang source: testsuite-autopkgtest-missing
>>
>> * the package ships a copy of jquery.js, we should be able to use
>>   the one provided by libjs-jquery.
>
> Added deps on libjs-jquery. Source of jquery.js is now provided.
>
> Also move Flux resource files to /usr/share/ .
>
>> Your package was successfully built on debomatic-amd64,
>> http://debomatic-amd64.debian.net/distribution#unstable/iolang/2017.09.06+dfsg-1/buildlog
>>
>> I'll check copyright later.
>>
>> --
>> Best,
>>
>>



-- 
Best,

Bug#881847: shadowsocks-libev: Consider listening on all interfaces, and IPv6

[Roger Shimizu]

Dear James,

Thanks for your report, and sorry for the late reply!

On Thu, Nov 16, 2017 at 2:46 AM, James Valleroy  wrote:
> Package: shadowsocks-libev
> Severity: wishlist
>
> Dear Maintainer,
>
> Currently, the default config for ss-server has server set to
> 127.0.0.1. Considering the purpose of this server, wouldn't it make
> sense to listen on all interfaces (and accept outside connections) by
> setting server default value to 0.0.0.0?
>
> Also, please consider enabling IPv6 support by default. The man page
> gives this example:
>
> {
> "server":["::0","0.0.0.0"],
> ...
> }

Considering currently the service only binds to localhost, for security's sake,
I think it's better to use the patch below.
What do you think?

diff --git a/debian/config.json b/debian/config.json
index 8ffa650..eb32b99 100644
--- a/debian/config.json
+++ b/debian/config.json
@@ -1,5 +1,5 @@
 {
-"server":"127.0.0.1",
+"server":["127.0.0.1", "::1"],
 "server_port":8388,
 "local_port":1080,
 "password":"barfoo!",

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#893676: hurd: internal compiler error building petsc

[Samuel Thibault]

Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote:
> The build of PETSc 3.8 triggers an internal compiler error on hurd:
> 
> CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o
>   ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= 
> ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
>   /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c: In function 
> 'VecSetInf':
>   /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: 
> internal compiler error: Aborted
>}

Well, perhaps it's just because the current version of gcc-7 isn't
built.

Samuel

Bug#718819: python3 has circular Depends on dh-python

[jim_p]

Package: python3
Version: 3.6.4-1
Followup-For: Bug #718819

Dear Maintainer,

First of all, thank you for merging my report (893477) with this one. It seems
that the python3 package is a better place to make that report, although I
still think that dpkg-dev is the source of my issue.

Second, this report is written from my debian testing installation, because I
decided to remove dpkg-dev and all the useless dependencies it brings along
from my unstable system. That also removed dh-python and python3 along with
more packages. I also lost pastebinit, icdiff and reportbug as I can remember,
thus I can no longer use reportbug to report bugs from that system directly.

Third, for a tiny package like pastebinit, apt now installs all sorts of
rubbish due to that circular depencency between dh-python and python3 and the
direct one between dh-python and dpkg-dev, e.g.

# apt-get install pastebinit
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  binutils binutils-common binutils-i686-linux-gnu bzip2 dh-python dpkg-dev
  libbinutils libdpkg-perl libpython3-stdlib libpython3.6-minimal
  libpython3.6-stdlib make patch python3 python3-minimal python3.6
  python3.6-minimal
Suggested packages:
  binutils-doc bzip2-doc debian-keyring gnupg | gnupg2 gcc | c-compiler git
  bzr make-doc ed diffutils-doc python3-doc python3-tk python3-venv
  python3.6-venv python3.6-doc binfmt-support
Recommended packages:
  build-essential gcc | c-compiler fakeroot gnupg | gnupg2
  libalgorithm-merge-perl libfile-fcntllock-perl
The following NEW packages will be installed:
  binutils binutils-common binutils-i686-linux-gnu bzip2 dh-python dpkg-dev
  libbinutils libdpkg-perl libpython3-stdlib libpython3.6-minimal
  libpython3.6-stdlib make pastebinit patch python3 python3-minimal python3.6
  python3.6-minimal
0 upgraded, 18 newly installed, 0 to remove and 2 not upgraded.
Need to get 12.0 MB of archives.
After this operation, 55.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] n

And all that with apt being configured to NOT install suggested and recommended
packages! If I had configured apt to install recommended dependencies as well,
the useless ones would be a lot more.

Forth, can't you just make dpkg-dev an OPTIONAL depencency for dh-python?
Making it a recommended one would still make apt install it on systems that are
configured to install recommended packages by default, which in turn is the
default behaviour of apt.

Fifth, seeing that "wontfix" there means I have little to no hope of changing
your minds, and that makes me really upset.

Thank you.



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

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

Versions of packages python3 depends on:
ii  dh-python  2.20170125
ii  libpython3-stdlib  3.6.4-1
ii  python3-minimal3.6.4-1
ii  python3.6  3.6.5~rc1-1

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information

Bug#870214: Status on 870214

[Thomas D]

Hi,

I can confirm this problem exists in stable. Any plans on fixing this?
Or at least provide a means of suppressing the warnings?

BR
Thomas

Bug#892585: systemd: can not create user.slice/user session, after upgrade systemd from 237-4 to 238-1/2

[johnw]

After upgrade systemd to 238-3, I still have this problem :(
Any one?
Help, please.

--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC



signature.asc
Description: OpenPGP digital signature

Bug#893686: Please create debian-openst...@lists.debian.org

[Thomas Goirand]

Package: lists.debian.org
Severity: normal

Dear listmasters,

We would like to create debian-openst...@lists.debian.org. Here's the list
information, as per https://www.debian.org/MailingLists/HOWTO_start_list:

Name:
=
debian-openstack

Rational:
=

Currently, we have the openstack-de...@lists.alioth.debian.org list which 
receives all the BTS and package tracking traffic. Hopefully, we will move that 
to @tracker.debian.org somehow.

Though together with this, we also discuss ways of packaging OpenStack, and do 
a bit of OpenStack on Debian user support.

We (ie: the OpenStack Debian team) believe it'd be a way better if we could 
have a separate mailing list for these discussions. Please create 
debian-openst...@lists.debian.org.

Short description:
==
Discussing packaging and using OpenStack on Debian

Long description:
=
If you wish to become a member of the Debian OpenStack packaging team and 
contribute to the https://salsa.debian.org/openstack-team Git repositories, 
please join this list, describe yourself and what you want to do. The team will 
be very happy to help you to help.

If you are an OpenStack user running on Debian and need help, join the list and 
ask your questions.

Category:
=
- Users
- Developers

(if only one category can be selected, then Developers)

Subscription Policy:

Open

Post Policy:

Moderated (I already do the moderation to avoid SPAM, I can continue...).

Web Archive:

Yes

Moving existing mailing lists to lists.debian.org:
==
The current list on Alioth contains too much noise with all the package
tracking stuff, and we do not wish to move that. Filtering it would probably
be too much work.

Cheers,

Thomas Goirand (zigo)

Bug#620511: ITP: ipt-netflow -- netfilter target which sends traffic statistics via NetFlow

[Axel Beckert]

Hi,

[dropping previous ITP-owners from Cc]

Axel Beckert wrote yesterday:
> Unfortunately I had no answers to these questions, so I intend to
> package ipt-netflow from scratch. Co-maintainers welcome! Details (git
> repo, actual package name, etc.) later this week.

A close-to-production, dkms-based packaging is available at
https://salsa.debian.org/debian/iptables-netflow

While the binary package name will be iptables-netflow-dkms, I'm still
unsure if I rather should go with upstream's "ipt-netflow" as the
source package name, or if I should stay with the current
"iptables-netflow" which closer to the binary package name.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#893688: libserf-1-1: bzr-svn segfaults in serf_bucket_aggregate_append

[Colin Watson]

Package: libserf-1-1
Version: 1.3.9-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

bzr-svn segfaults due to a list management bug in
serf_bucket_aggregate_append.  This is unfortunately hard to observe
because bzr-svn isn't in Debian any more and various things around it
have bitrotted a bit, but we still rely on it for Subversion imports in
Launchpad, and it is possible to set up a reproduction environment in
unstable with a bit of hacking.

First, install bzr from unstable.

Next, grab commit 01cfebd2e32b940ddfa55373640907b39da8413f of subvertpy
(https://github.com/jelmer/subvertpy), which makes a bit of API that
bzr-svn needs available with modern versions of Subversion, and build it
("sudo apt build-dep python-subvertpy && make").

Next, grab bzr-svn ("bzr branch lp:bzr-svn").  It's a bit broken with
modern versions of libsvn; I had to apply the following hacky patch,
which is almost certainly not quite right in some way (which is why I
haven't submitted it yet), but it'll do for the purposes of this bug:

=== modified file 'logwalker.py'
--- logwalker.py2012-03-08 17:52:35 +
+++ logwalker.py2018-03-21 08:25:52 +
@@ -206,7 +206,8 @@ class CachingLogWalkerUpdater(object):
 self.count += 1
 self.pb.update('fetching svn revision info', self.count, self.total)
 self.logwalker.cache.insert_paths(revision, orig_paths,
-revprops, self.all_revprops)
+{key.encode("UTF-8"): value for key, value in revprops.items()},
+self.all_revprops)
 self.logwalker.saved_maxrevnum = max(revision,
 self.logwalker.saved_maxrevnum)
 if self.logwalker.saved_minrevnum is None:

=== modified file 'transport.py'
--- transport.py2012-03-08 17:52:35 +
+++ transport.py2018-03-21 08:21:59 +
@@ -440,7 +440,7 @@ class SvnRaTransport(Transport):
 if self._uuid is None:
 conn = self.get_any_connection()
 try:
-return conn.get_uuid()
+return conn.get_uuid().encode("UTF-8")
 finally:
 self.add_connection(conn)
 return self._uuid
@@ -456,7 +456,7 @@ class SvnRaTransport(Transport):
 if self._repos_root is None:
 conn = self.get_any_connection()
 try:
-self._repos_root = conn.get_repos_root()
+self._repos_root = conn.get_repos_root().encode("UTF-8")
 finally:
 self.add_connection(conn)
 return self._repos_root

Make ~/.bazaar/plugins/svn be a symlink to the bzr-svn branch.

Now try this branch operation, with PYTHONPATH adjusted to point to
wherever you cloned subvertpy:

  PYTHONPATH=/path/to/subvertpy bzr branch 
https://svn.code.sf.net/p/truckliststudio/svn/trunk truckliststudio

The fix is rather easier than describing the setup, since it was fixed
upstream some time ago:

  https://svn.apache.org/viewvc?view=revision&revision=1712790

diff -Nru serf-1.3.9/debian/changelog serf-1.3.9/debian/changelog
--- serf-1.3.9/debian/changelog 2018-02-05 23:28:07.0 +
+++ serf-1.3.9/debian/changelog 2018-03-20 12:41:54.0 +
@@ -1,3 +1,10 @@
+serf (1.3.9-5) UNRELEASED; urgency=medium
+
+  * Backport r1712790 from upstream to fix a segfault in
+serf_bucket_aggregate_prepend when prepending a bucket to an empty list.
+
+ -- Colin Watson   Tue, 20 Mar 2018 12:41:52 +
+
 serf (1.3.9-4) unstable; urgency=medium
 
   * Mark serf_debug_closed_conn as a public symbol, since svn has been using
diff -Nru 
serf-1.3.9/debian/patches/r1712790-serf_bucket_aggregate_prepend-empty-list 
serf-1.3.9/debian/patches/r1712790-serf_bucket_aggregate_prepend-empty-list
--- serf-1.3.9/debian/patches/r1712790-serf_bucket_aggregate_prepend-empty-list 
1970-01-01 01:00:00.0 +0100
+++ serf-1.3.9/debian/patches/r1712790-serf_bucket_aggregate_prepend-empty-list 
2017-05-16 14:32:26.0 +0100
@@ -0,0 +1,34 @@
+Description: Make serf_bucket_aggregate_prepend() behave properly when 
prepending a bucket to an empty list
+Origin: upstream, https://svn.apache.org/viewvc?view=revision&revision=1712790
+
+Index: b/buckets/aggregate_buckets.c
+===
+--- a/buckets/aggregate_buckets.c
 b/buckets/aggregate_buckets.c
+@@ -149,6 +149,8 @@
+ new_list->bucket = prepend_bucket;
+ new_list->next = ctx->list;
+ 
++if (ctx->list == NULL)
++ctx->last = new_list;
+ ctx->list = new_list;
+ }
+ 
+@@ -278,6 +280,8 @@
+ 
+ /* If we have no more in our list, return EOF. */
+ if (!ctx->list) {
++ctx->last = NULL;
++
+ if (ctx->hold_open) {
+ return ctx->hold_open(ctx->hold_open_baton, bucket);
+ }
+@@ -390,6 +394,8 @@
+ 
+ /* If we have no more in our list, return EOF. */
+  

Bug#893687: ccrypt: conffiles not removed

[Paul Wise]

Package: ccrypt
Version: 1.10-5
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=ccrypt ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
ccrypt: obsolete-conffile /etc/emacs/site-start.d/50ccrypt.el
 /etc/emacs/site-start.d/50ccrypt.el 219f5b6bd014189fdaed65660c4b4c96 obsolete

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ccrypt depends on:
ii  libc6  2.27-2

ccrypt recommends no packages.

Versions of packages ccrypt suggests:
pn  elpa-ps-ccrypt  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893591: e2fsprogs: circular build dependency block build on kfreebsd

[Ansgar Burchardt]

> On Tue, Mar 20, 2018 at 08:50:43AM +0100, Petter Reinholdtsen wrote:
>> The automatic builders in Debian are unable to build e2fsprogs on
>> kfreebsd, because the build depend on libtirpc1 depending on libcomerr2
>> (>= 1.01).  Is there a good way to break this loop?
>> 
>> The missing build blocks libvorbis from building on kfreebsd.

There no longer are any kfreebsd buildds, see
https://lists.debian.org/debian-bsd/2017/12/msg8.html

Ansgar

Bug#893689: /usr/sbin/smbd: printing=bsd does not work for Win8/10 clients

[Bartos-Elekes Zsolt]

Package: samba
Version: 2:4.5.12+dfsg-2+deb9u2
Severity: normal
File: /usr/sbin/smbd

Dear Maintainer,

Printing from Win8/Win10 clients to a printer shared on a samba server
using printing=bsd does not work (printing from smbclient and WinXP/Win7
clients is OK).

The file to print is transferred to the spool directory, but
find_printer_index_by_hnd() fails with a "printer handle not found:
invalid handle" error, and printing is cancelled.

I made the following change to try to find out what's the problem
with the handle:

--- old/source3/rpc_server/rpc_handles.c2016-05-23 13:05:17 +0200
+++ new/source3/rpc_server/rpc_handles.c2018-03-09 16:21:43 +0100
@@ -346,8 +346,12 @@
count++;
}
 
-   DEBUG(4,("Policy not found: "));
-   dump_data(4, (const uint8_t *)hnd, sizeof(*hnd));
+   if (count==0)
+   DEBUG(4,("Policy list empty.\n"));
+   else {
+   DEBUG(4,("Policy not found: "));
+   dump_data(4, (const uint8_t *)hnd, sizeof(*hnd));
+   }
 
p->fault_state = DCERPC_FAULT_CONTEXT_MISMATCH;

With this change, the smbd log (level 10, attached) shows that the handle
isn't found because the policy list is empty.

Here is my smb.conf:

[global]
  netbios name=hostname
  workgroup=Workgroup
  server string=%h.example.com
  local master=no
  security=user
  passdb backend=smbpasswd
  map to guest=bad password
  wins support=yes
  name resolve order=wins lmhosts host bcast
  unix charset=ISO-8859-2
  dos charset=CP852
  acl allow execute always=yes
  printing=bsd
  load printers=no
  min print space=1024
  socket options=TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536
  use sendfile=yes
  log level=10

[printer]
  path=/var/spool/samba/printer
  printable=yes
  guest ok=yes

[nyomtato]
  path=/var/spool/samba/printer
  printable=yes
  guest ok=yes

Although printing is cancelled, and lpr isn't called by samba, the
spooled file is not deleted, so I could work around the problem by
watching the spool directory with an inotify-based tool, and calling
lpr from there, but it would be nice to fix this in samba.

If you need more details, feel free to ask.

-- 
Zsolt


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages samba depends on:
ii  adduser   3.115
ii  dpkg  1.18.24
ii  fake-update-inetd [update-inetd]  0.01
ii  init-system-helpers   1.48
ii  libbsd0   0.8.3-1
ii  libc6 2.24-11+deb9u3
ii  libldb1   2:1.1.27-1+b1
ii  libpam-modules1.1.8-3.6
ii  libpam-runtime1.1.8-3.6
ii  libpopt0  1.16-10+b2
ii  libpython2.7  2.7.13-2+deb9u2
ii  libtalloc22.1.8-1
ii  libtdb1   1.3.11-2
ii  libtevent00.9.31-1
ii  libwbclient0  2:4.5.12+dfsg-2+deb9u2
ii  lsb-base  9.20161125
ii  procps2:3.3.12-3
ii  python2.7.13-2
ii  python-dnspython  1.15.0-1
ii  python-samba  2:4.5.12+dfsg-2+deb9u2
ii  python2.7 2.7.13-2+deb9u2
ii  samba-common  2:4.5.12+dfsg-2+deb9u2
ii  samba-common-bin  2:4.5.12+dfsg-2+deb9u2
ii  samba-libs2:4.5.12+dfsg-2+deb9u2
ii  tdb-tools 1.3.11-2

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.11.0-0.1
pn  samba-dsdb-modules  
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p10+dfsg-3+deb9u2
pn  smbldap-tools  
pn  ufw
pn  winbind


log.smbd.gz
Description: application/gzip

Bug#893690: dogtag-pki: CVE-2018-1080: Mishandled ACL configuration in AAclAuthz.java reverses rules that allow and deny access

[Salvatore Bonaccorso]

Source: dogtag-pki
Version: 10.5.5-1
Severity: grave
Tags: security upstream
Forwarded: https://pagure.io/freeipa/issue/7453

Hi,

the following vulnerability was published for dogtag-pki.

CVE-2018-1080[0]:
Mishandled ACL configuration in AAclAuthz.java reverses rules that allow and 
deny access

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-2018-1080
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1080
[1] https://pagure.io/freeipa/issue/7453
[2] https://review.gerrithub.io/#/c/404435/

Regards,
Salvatore

Bug#890335: torbrowser-launcher: couldn't upload

[intrigeri]

Control: tag -1 - moreinfo
Control: retitle -1 Document which download/upload directory is supported by 
the AppArmor policy

Vladimir Stavrinov:
> On Sun, Mar 18, 2018 at 12:14 PM, intrigeri  wrote:

>> Can you please try uploading a file from the Tor Browser's "Downloads"
>> directory, that is likely:
>>
>>   
>> $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/Downloads/

> Yes, it works. Thank you.

Thanks for testing!

I think the best we can do for now is to document this in README.Debian.

Cheers,
-- 
intrigeri

Bug#890335: [Pkg-privacy-maintainers] Bug#890335: torbrowser-launcher: couldn't upload

[intrigeri]

Georg Faerber:
> I would like to, but I've hit #893308. I'm not able to currently run it
> at all, I'm happy to take any pointers over there. (I didn't debugged
> this further, time was limited, and I also didn't check if this happens
> on a clean install as well.)

FTR I try to limit the scope of my work on torbrowser-launcher to the
AppArmor-related issues so I'll let the currently active maintainers
of this package handle this problem on #893308 :)

Cheers,
-- 
intrigeri

Bug#893691: sbuild: Missing Depends on lintian after defaults change

[James Clarke]

Package: sbuild
Version: 0.74.0-1
Severity: serious

Hi,
Now that lintian defaults to enabled in 0.74.0-1, sbuild by default will
need lintian installed, but it has no dependency on it, and thus fails
with:

> Error reading configuration: LINTIAN binary 'lintian' does not exist or is 
> not executable at /usr/share/perl5/Sbuild/Conf.pm line 76

Please fix this (I don't care if it's Depends or the default) so sbuild
isn't broken out of the box.

James

Bug#893692: bcolz: uses pybuild's internal paths

[Piotr Ożarowski]

Package: bcolz
Version: 1.1.0+ds1-5
Severity: important

Dear Maintainer,

Please don't use pybuild's internal paths. They did change recently and
they might change in the future, use pybuild's --print if you really
have to. See attached patch
commit e78665a2045be2ca3a31a6df747fd316a62f159c
Author: Piotr Ożarowski 
Date:   Wed Mar 21 09:59:25 2018 +0100

do not hardcode pybuild's internal paths

diff --git a/debian/control b/debian/control
index 4fa5101..78d2746 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Science Maintainers 
 Build-Depends:
  debhelper (>= 9),
- dh-python,
+ dh-python (>= 3.20180313~),
  python-all-dev,
  python3-all-dev,
  python-setuptools,
diff --git a/debian/rules b/debian/rules
index 8223ad1..dc1b667 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,8 +16,8 @@ export SETUPTOOLS_SCM_PRETEND_VERSION = $(VERSION_UPSTREAM)
 override_dh_auto_install:
 	dh_auto_install
 ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
-	cp .pybuild/pythonX.Y_*/build/bcolz/carray_ext*.so bcolz/
-	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N docs/ debian/bcolz-doc/usr/share/doc/bcolz-doc/html/
+	PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) \
+	http_proxy='127.0.0.1:9' sphinx-build -N docs/ debian/bcolz-doc/usr/share/doc/bcolz-doc/html/
 endif
 
 override_dh_installdocs:

Bug#873227: Please upgrade to 4.1: Java 9 support

[Tiago Daitx]

Please see the attached debdiff to enable some basic OpenJDK 9 support
for gradle 3.4.1. The patches were downloaded from gradle upstream to
prevent the dreadful "Could not determine java version from '9.0.x'".

After applying the patches and rebuilding with OpenJDK 8, gradle can
then build itself with openjdk 9. I have also rebuild groovy, gant,
spock (FTBFS due to source/target 1.5), and dom4j (FTBFS due to
failing tests) which all previously failed.

Hopefully this should unblock #875336.

Please note that the debdiff includes the fix for #893487 for convenience.

thanks

On Fri, 25 Aug 2017 17:01:23 +0100 Chris West
 wrote:
> Source: gradle
> Version: 3.2.1-1
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
>
> Gradle doesn't officially support running under Java 9 until 4.1, which
> was released a fortnight ago.
>
> The version in Debian seems to actually be much better at surviving real
> builds than other random versions of Gradle I have lying around, but it
> would still be nice totally eliminate this as a java-9 blocker.
>
> Cheers,
> Chris.
>
>
>
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2017-11-29 16:09:02.0 +0100
+++ gradle-3.4.1/debian/changelog	2018-03-19 12:19:49.0 +0100
@@ -1,3 +1,15 @@
+gradle (3.4.1-3) UNRELEASED; urgency=medium
+
+  * d/p/cast-estimated-runtime-to-long.patch: fix FTBFS due to missing cast.
+(Closes: #893487)
+  * d/p/support-running-gradle-on-jdk-10-500485df3a18.patch,
+d/p/add-test-case-for-10-internal_c1fe5e40a76b.patch,
+d/p/support-zulu9-version-number_d9c35cf9d74c.patch: prevent failures when
+building projects with openjdk 9.
+
+
+ -- Tiago Stürmer Daitx   Mon, 19 Mar 2018 11:19:49 +
+
 gradle (3.4.1-2) experimental; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch
--- gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	2018-03-19 12:19:49.0 +0100
@@ -0,0 +1,21 @@
+From c1fe5e40a76b79a98e8916c2ce3b4e1e6ed3f343 Mon Sep 17 00:00:00 2001
+From: Cedric Champeau 
+Date: Thu, 13 Jul 2017 16:16:46 +0200
+Subject: [PATCH] Add test case for `10-internal`
+
+---
+ .../base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy  | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+index 75459ed3f06..fbb243ba992 100644
+--- a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
 b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+@@ -65,6 +65,7 @@ public class JavaVersionSpec extends Specification {
+ JavaVersion.toVersion("9-ea") == JavaVersion.VERSION_1_9
+ 
+ JavaVersion.toVersion("10-ea") == JavaVersion.VERSION_1_10
++JavaVersion.toVersion("10-internal") == JavaVersion.VERSION_1_10
+ }
+ 
+ def convertClassVersionToJavaVersion() {
diff -Nru gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch
--- gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	2018-03-19 12:15:47.0 +0100
@@ -0,0 +1,22 @@
+Description: gradle 3.4.1 FTBFS with a missing cast to long
+ estimatedRuntime must be cast to long otherwise gradle 3.4.1 FTBFS with
+ buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy:
+ 134: [Static type checking] - Cannot assign value of type java.math.BigDecimal
+ to variable of type long.
+Author: Tiago Stürmer Daitx 
+Bug-Debian: https://bugs.debian.org/893487
+Forwarded: no
+Last-Update: 2018-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
 b/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
+@@ -131,7 +131,7 @@ class DistributedPerformanceTest extends
+ def scenarios = scenarioList.readLines()
+ .collect { line ->
+ def parts = Splitter.on(';').split(line).toList()
+-new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]), templates: parts.subList(2, parts.size()))
++new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]) as long, templates: parts.subList(2, parts.size()))
+ }
+ .sort{ -it.estimatedRuntime }
+ 
diff -Nru gradle-3.4.1/debian/patches/series gradle-3.4.1/debian/patches/series
--- gradle-

Bug#893693: fail2ban: uses pybuild's internal paths

[Piotr Ożarowski]

Package: fail2ban
Version: 0.10.2-1
Severity: important

Dear Maintainer,

Please apply attached patch to fix FTBFS with new dh-python.
Patch also adds missing dh-python to Build-Depends
commit 3080b5a15e02056fadffc9039dc24574588c72f5
Author: Piotr Ożarowski 
Date:   Wed Mar 21 10:32:31 2018 +0100

do not use pybuild's internal paths

diff --git a/debian/control b/debian/control
index 77b32cb3..a4b4b6f4 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
 Maintainer: Yaroslav Halchenko 
 Build-Depends:
  debhelper (>= 9)
+ , dh-python (>= 3.20180313~)
  , debhelper (>= 9.20160709) | dh-systemd
  , python3
  , python3-pyinotify
diff --git a/debian/rules b/debian/rules
index 77db4aa7..bb1e8af3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,6 @@ export PYBUILD_DISABLE_python2=1
 	dh $@ --with python3,systemd --buildsystem pybuild
 
 DESTDIR=$(CURDIR)/debian/fail2ban
-PYVERSION=$(shell py3versions -dv)
 
 override_dh_clean:
 	rm -rf fail2ban.egg-info
@@ -55,7 +54,7 @@ ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	cd build && \
 	 LC_ALL=C.UTF-8 \
 	 FAIL2BAN_CONFIG_DIR="$(CURDIR)/config" \
-	 PYTHONPATH="$(CURDIR)/.pybuild/pythonX.Y_$(PYVERSION)/build/" \
+	 PYTHONPATH="$(shell pybuild --print build_dir --interpreter python3)" \
 	  scripts-*/fail2ban-testcases --no-network --verbosity=2
 endif
 

Bug#875336: FTBFS with Java 9: _ as identifier

[Tiago Daitx]

On Tue, 20 Mar 2018 23:07:13 +0800
=?UTF-8?B?5q635ZWf6IGwIHwgS2FpLUNodW5nIFlhbg==?= 
wrote:
> I just tried building it and Groovy was fine enough, but now Gradle 
> complains
>
> Theoretically, ALL Gradle packages FTBFS since the current version is too old 
> to play with Java 9's fancy version number.

Please take a look at the debdiff I attached to #873227 [1]. I would
like to get some feedback if it fixes these additional FTBFS.

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

Bug#893694: gajim: fails to start if python3-distutils is not installed (missing dependency?)

[Antonio Ospite]

Package: gajim
Version: 1.0.0-1
Severity: important

Dear Maintainer,

the new gajim version failed to start on my system with the following
messages:


  $ gajim
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gajim/gajim.py", line 146, in _startup
  from distutils.version import LooseVersion as V
  ModuleNotFoundError: No module named 'distutils'
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gajim/gajim.py", line 264, in _activate
  from gajim.gui_interface import Interface
File "/usr/lib/python3/dist-packages/gajim/gui_interface.py", line 54, in 

  from gajim.common import app
File "/usr/lib/python3/dist-packages/gajim/common/app.py", line 35, in 

  from distutils.version import LooseVersion as V
  ModuleNotFoundError: No module named 'distutils'
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gajim/gajim.py", line 316, in 
do_shutdown
  from gajim.common import app
File "/usr/lib/python3/dist-packages/gajim/common/app.py", line 35, in 

  from distutils.version import LooseVersion as V
  ModuleNotFoundError: No module named 'distutils'


Installing python3-distutils fixes the problem; does it need to be added
to the dependencies?

Ciao,
   Antonio

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

Kernel: Linux 4.15.0-1-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)
LSM: AppArmor: enabled

Versions of packages gajim depends on:
ii  gir1.2-gtk-3.03.22.29-1
ii  python3   3.6.4-1
ii  python3-gi3.26.1-2
ii  python3-gi-cairo  3.26.1-2
ii  python3-idna  2.6-1
ii  python3-nbxmpp0.6.4-1
ii  python3-openssl   17.5.0-1
ii  python3-pyasn10.4.2-3

Versions of packages gajim recommends:
ii  alsa-utils 1.1.3-1
ii  aspell-it [aspell-dictionary]  2.4-20070901-0-2.1
ii  ca-certificates20170717
ii  dbus   1.12.6-2
ii  fonts-noto-color-emoji 0~20180102-1
ii  gajim-omemo2.5.7-1
ii  gajim-pgp  1.2.2-1
ii  gir1.2-farstream-0.2   0.2.8-4
ii  gir1.2-geoclue-2.0 2.4.7-1
ii  gir1.2-gspell-11.6.1-1
ii  gir1.2-gst-plugins-base-1.01.12.4-1
ii  gir1.2-gstreamer-1.0   1.12.4-1
ii  gir1.2-gupnpigd-1.00.2.5-2
ii  gir1.2-networkmanager-1.0  1.10.6-2
ii  gir1.2-secret-10.18.5-6
ii  gnome-flashback [notification-daemon]  3.26.0-3
ii  gnome-shell [notification-daemon]  3.28.0-1
pn  gstreamer0.10-plugins-ugly 
ii  pulseaudio-utils   11.1-4
ii  python3-crypto 2.6.1-8
ii  python3-dbus   1.2.6-1
ii  python3-gnupg  0.4.1-2
ii  python3-keyring10.6.0-1
ii  python3-pil5.0.0-1
ii  python3-precis-i18n1.0.0-1

Versions of packages gajim suggests:
ii  avahi-daemon  0.7-3.1
ii  libxss1   1:1.2.2-1+b2
ii  nautilus-sendto   3.8.6-2
pn  python3-avahi 
pn  python3-gconf 
pn  python3-gnome2
pn  python3-kerberos  
ii  python3-pycurl7.43.0.1-0.2

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#877855: debootstrap does not carry --components across --foreign/--second-stage

[Hideki Yamane]

control: tags -1 +confirmed

On Fri, 06 Oct 2017 09:40:39 +0200 Michael Stapelberg  
wrote:
> This debootstrap invocation’s sources.list lacks the extra components:
> 
> % sudo debootstrap --foreign --components main,contrib,non-free \
>   --variant - testing bootstr http://deb.debian.org/debian
> % sudo chroot /tmp/bootstr /debootstrap/debootstrap --second-stage
> % sudo cat /tmp/bootstr/etc/apt/sources.list
> deb http://deb.debian.org/debian testing main
> 
> Looking at /tmp/bootstr/debootstrap/debootstrap before the chroot command 
> shows
> “USE_COMPONENTS=main”, which I believe should include contrib and non-free.

 And it lucks mirror URL that was specified by user.

> $ sudo debootstrap --foreign --components main,contrib,non-free \
>   --variant - testing bootstr http://debian-mirror.sakura.ne.jp/debian
> $ sudo chroot /tmp/bootstr /debootstrap/debootstrap --second-stage
> $ sudo cat /tmp/bootstr/etc/apt/sources.list
> deb http://deb.debian.org/debian testing main

 Since in debootstrap, $TARGET/etc/apt/sources.list is deleted at
 starting for second stage.

> if am_doing_phase second_stage; then
> if [ "$SECOND_STAGE_ONLY" = true ]; then
> required="$(cat $DEBOOTSTRAP_DIR/required)"
> base="$(cat $DEBOOTSTRAP_DIR/base)"
> all_debs="$required $base"
> fi
> 
> # second stage uses the chroot to clean itself up -- has to be able to
> # work from entirely within the chroot (in case we've booted into it,
> # possibly over NFS eg)
> 
> second_stage_install
> 
> # create sources.list
> # first, kill debootstrap.invalid sources.list
> if [ -e "$TARGET/etc/apt/sources.list" ]; then
> rm -f "$TARGET/etc/apt/sources.list"
> fi
> if [ "${MIRRORS#http://}"; != "$MIRRORS" ]; then
> setup_apt_sources "${MIRRORS%% *}"
> mv_invalid_to "${MIRRORS%% *}"
> else
> setup_apt_sources "$DEF_MIRROR"
> mv_invalid_to "$DEF_MIRROR"
> fi



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#893695: apparmor: Apparmor break firefox with psd

[rollopack]

Package: apparmor
Version: 2.12-3
Severity: normal

Hi, firefox 60 using Profile-sync-daemon is blocked by apparmor.

>From dmesg:

[126996.722983] audit: type=1400 audit(1521622991.503:1719): apparmor="DENIED"
operation="symlink" profile="/usr/lib/firefox/firefox{,*[^s][^h]}"
name="/run/user/1000/rollopack-firefox-siidzdj3.default/lock" pid=9163
comm="firefox" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

aa-disable "/usr/lib/firefox/firefox{,*[^s][^h]}" solve the problem



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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libc6  2.27-2
ii  lsb-base   9.20170808
ii  python33.6.4-1

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
ii  apparmor-utils   2.12-3

-- debconf information:
  apparmor/homedirs:

Bug#893696: libgtk-3-0: All wayland clients crash (seems to happen when the screen was locked for a while)

[Marcus Lundblad]

Package: libgtk-3-0
Version: 3.22.29-1
Severity: critical
Tags: upstream
Justification: causes serious data loss

This seems to be this upstream issue
https://gitlab.gnome.org/GNOME/gtk/issues/114

Thanks,
Marcus



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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.28.0-1
ii  hicolor-icon-theme  0.17-1
ii  libatk-bridge2.0-0  2.26.2-1
ii  libatk1.0-0 2.28.1-1
ii  libc6   2.27-2
ii  libcairo-gobject2   1.15.10-1
ii  libcairo2   1.15.10-1
ii  libcolord2  1.3.3-2
ii  libcups22.2.6-5
ii  libepoxy0   1.4.3-1
ii  libfontconfig1  2.12.6-0.1
ii  libfreetype62.8.1-2
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libglib2.0-02.54.3-2
ii  libgtk-3-common 3.22.29-1
ii  libjson-glib-1.0-0  1.4.2-3
ii  libpango-1.0-0  1.40.14-1
ii  libpangocairo-1.0-0 1.40.14-1
ii  libpangoft2-1.0-0   1.40.14-1
ii  librest-0.7-0   0.8.0-2
ii  libsoup2.4-12.62.0-1
ii  libwayland-client0  1.14.0-2
ii  libwayland-cursor0  1.14.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  17.3.6-1
ii  libx11-62:1.6.4-3
ii  libxcomposite1  1:0.4.4-2
ii  libxcursor1 1:1.1.15-1
ii  libxdamage1 1:1.1.4-3
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxi6  2:1.7.9-1
ii  libxinerama12:1.1.3-1+b3
ii  libxkbcommon0   0.8.0-1
ii  libxml2 2.9.4+dfsg1-6.1
ii  libxrandr2  2:1.5.1-1
ii  shared-mime-info1.9-2

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.22.29-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.34.1-2
ii  librsvg2-common  2.40.20-2

-- debconf-show failed

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Andreas Beckmann]

I cannot remember any bug reports regarding this upgrade problem before
yours ...

-ENOTMUCHTIMETHISWEEK :-(

Andreas

Bug#893697: sesearch needs python3-lib2to3

[Christian Göttsche]

Package: setools
Version: 4.1.1-3
Severity: Important

sesearch needs the python module lib2to3 or it fails:


Traceback (most recent call last):
  File "/usr/bin/sesearch", line 21, in 
import setools
  File "/usr/lib/python3/dist-packages/setools/__init__.py", line 77,
in 
from .infoflow import InfoFlowAnalysis
  File "/usr/lib/python3/dist-packages/setools/infoflow.py", line 22,
in 
import networkx as nx
  File "/usr/lib/python3/dist-packages/networkx/__init__.py", line 87,
in 
import networkx.readwrite
  File "/usr/lib/python3/dist-packages/networkx/readwrite/__init__.py",
line 14, in 
from networkx.readwrite.gml import *
  File "/usr/lib/python3/dist-packages/networkx/readwrite/gml.py",
line 44, in 
from lib2to3.pgen2.parse import ParseError
ModuleNotFoundError: No module named 'lib2to3'

Bug#893698: ovirt-guesta-agent 1.0.12.2.dfsg-2 does not work with oVirt 4.2

[Tomáš Golembiovský]

Package: ovirt-guest-agent
Version: 1.0.12.2.dfsg-2

Hi,

the ovirt-guest agent in stretch/stable does not work with recent oVirt
4.2 because a changed path to the virtio channel.

See this change for 1.0.13 in upstream:


https://gerrit.ovirt.org/gitweb?p=ovirt-guest-agent.git;a=commit;h=9f4d8d50ce2ca058075b6cf4b4c3862bfb411d7a

Tomas

-- 
Tomáš Golembiovský 

Bug#881847: shadowsocks-libev: Consider listening on all interfaces, and IPv6

[James Valleroy]

On 03/21/2018 04:11 AM, Roger Shimizu wrote:
> Considering currently the service only binds to localhost, for security's 
> sake,
> I think it's better to use the patch below.
> What do you think?
> 
> diff --git a/debian/config.json b/debian/config.json
> index 8ffa650..eb32b99 100644
> --- a/debian/config.json
> +++ b/debian/config.json
> @@ -1,5 +1,5 @@
>  {
> -"server":"127.0.0.1",
> +"server":["127.0.0.1", "::1"],
>  "server_port":8388,
>  "local_port":1080,
>  "password":"barfoo!",

Dear Roger,

Is there a use case where you would want to run the server only for localhost? I
guess I'm not aware of this.

--
James



signature.asc
Description: OpenPGP digital signature

Bug#733227: [Xcb] Bug#733227: libxcb1: XInput extension is not packaged

[Alexander Volkov]

ping

xcb-xinput is enabled by default in libxcb 1.13, but the package doesn't 
install it.

Bug#893556: libusb-0.1-4 has priority important

[Christian Göttsche]

2018-03-20 23:41 GMT+01:00 Aurelien Jarno :
> On 2018-03-19 22:09, Christian Göttsche wrote:
>> Package: libusb-0.1-4
>> Version: 2:0.1.12-31
>> Severity: Important
>
> Can you please tell me what is the important issue caused by this wrong
> priority?

Cause I think its against https://www.debian.org/doc/debian-policy/#s-priorities

>> Are there any reasons why this library has a priority of important?
>
> The main reason is that this package hasn't been uploaded since the
> relatively recent change of the policy. Some package with priority
> important depends on libusb-0.1-4, so the old policy required that
> libusb-0.1-4 to have at least priority optional.

Ok, I did not know.

>> If not, please lower to optional.
>
> I'll do that in the next upload.

Thanks

Bug#893699: python3-django-axes: Possibility to bypass IP limitations

[Sunil Mohan Adapa]

Package: python3-django-axes
Version: 4.1.0-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

django-axes upstream package has serious issue that IP limits can be completely
bypassed due the way IP address is retrieved from incoming HTTP headers.
https://github.com/jazzband/django-axes/issues/286

I am worried about the way upstream project is managed. They reject requests
such as GPG signing request very casually. They seriously broke the application
twice in just a few months. The first time that happened, plinth completely
broke. Patches like the one that introduced the problem seem to have been done
without much thought. They don't seem to want to acknowledge the problems like
the one that broke API in a patch release.

Because of this, I am less inclined to submit an upstream patch. Plinth, which
is the only package depending on this has a workaround ready:
https://salsa.debian.org/freedombox-team/plinth/merge_requests/1245

If this continues, it is probably better to focus our efforts on creating an
upstream fork.

Thanks,

- --
Sunil



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlqyNfMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfIsuxAAm2xT75Zhn5UcsMOE5vClyd5+LW9i/wfJ
sPDKW4s2nPUH1uSQz8DaJlCnVTry/opJrR0kX1ltZRjSnHQ4LksRmuBhF82q4Hlk
3gXfJwY22F+IQIV9ldgrfdPiQMaNDVlSWTJYj4rN13vhMDYrtey45TaU7m+fmTWJ
u0Tpe+59Mx3DLW0oAwmDUqi00LQrMkPcu6KPLlpl6LOBfmUNpZsbB+RVzkfQ3fqM
UrGggvYBMxWhtJujHbRsZTor4I6NlaFI5/cOSZrggvIh5oIboi097xNdGF2yha5I
1hXIlolvC7YcdC+rx8P/O0ZbHj91wJlxmmCmGnGWTSvW/lsQePam440EjX6Jp00f
9Tu8nLJCA5fe8Ys7Z0P7gPuZqhRke46EgLkWuxq7hnIuRznDqYM7ZDIy9AtXfZSM
G+daiLqSLVoSyCJFpyjRBg/XdjWRFInagvATHX8sQ74ZE8pSjzQDIA79f9ra3WSw
YdrVIw8U5r7Yhj1ZvG96dFH17w9prlUK1sOsNL9FWDKNrSjbociwzpTz5Mrm47gT
ll8IlVv7FGYagPuiszEfddPQHeGKs5YxKfUpT7rO/hD1871KnQT0Jp7NZ1kxE+nz
g7O2IjO7Yv0XuC2Bshns7Un8QMhXVaBDCo5DbbEDwSlbe8rT+RN0jlKuG6hGQXsh
jJiFeEV7MhM=
=Pf6c
-END PGP SIGNATURE-

Bug#868202: Remove build-depends and depends on python3-trollius

[Jérôme Lebleu]

Hi Iain,

python3-trollius is still a dependency of python3-qtile, probably an
oversight!

Also, I would be glad to help you maintaining qtile if you need so -
even if I'm not yet a DD.

Thanks in advance,

Jérôme



signature.asc
Description: OpenPGP digital signature

Bug#893700: php7.2: Would you please backport for stretch

[Frans van Berckel]

Package: libapache2-mod-php7.2
Package: libphp7.2-embed
Package: php7.2
Package: php7.2-bcmath
Package: php7.2-bz2
Package: php7.2-cgi
Package: php7.2-cli
Package: php7.2-common
Package: php7.2-curl
Package: php7.2-dba
Package: php7.2-dev
Package: php7.2-enchant
Package: php7.2-fpm
Package: php7.2-gd
Package: php7.2-gmp
Package: php7.2-imap
Package: php7.2-interbase
Package: php7.2-intl
Package: php7.2-json
Package: php7.2-ldap
Package: php7.2-mbstring
Package: php7.2-mysql
Package: php7.2-odbc
Package: php7.2-opcache
Package: php7.2-pgsql
Package: php7.2-phpdbg
Package: php7.2-pspell
Package: php7.2-readline
Package: php7.2-recode
Package: php7.2-snmp
Package: php7.2-soap
Package: php7.2-sqlite3
Package: php7.2-sybase
Package: php7.2-tidy
Package: php7.2-xml
Package: php7.2-xmlrpc
Package: php7.2-xsl
Package: php7.2-zip

Dear maintainer,

Someone has to call it someday, okay it's my turn ;-)

The web is moving fast forward, now a day's, you know. And i would be
very pleased, getting php7.2 back ported into Debian 9 (Stretch).

Ubunu does support 7.2 for 18.04 LTS as well.
What's the policy for php?

Thanks,


-- 
Frans van Berckel
Media Engineer / Linux Master
LinkedIn: https://www.linkedin.com/in/fransvberckel/

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Salvatore Bonaccorso]

Looking at the release-1.5.20 tag:

Security fix related to scripts and formulas
Security fix related to loading of mind map files
Change short cuts for MacOS to avoid collisions

The fix might be:

https://github.com/freeplane/freeplane/commit/a5dce7f9f4d29675fb256053aee3858bf8d76001

Regards,
Salvatore

Bug#866401: Please print proper error message when download fails

[Hideki Yamane]

control: tags -1 +patch

On Wed, 21 Mar 2018 18:15:06 +0900 Hideki Yamane  wrote:
>  Then, how about to change it to "-nv" (no-verbose) option?

 Here's a proposed patch.


diff --git a/functions b/functions
index bb7dae1..a4651ef 100644
--- a/functions
+++ b/functions
@@ -74,13 +74,13 @@ progress_next () {
 }
 
 wgetprogress () {
-   [ ! "$VERBOSE" ] && QSWITCH="-q"
+   [ ! "$VERBOSE" ] && NVSWITCH="-nv"
local ret=0
if [ "$USE_DEBIANINSTALLER_INTERACTION" ] && [ "$PROGRESS_NEXT" ]; then
wget "$@" 2>&1 >/dev/null | $PKGDETAILS "WGET%" $PROGRESS_NOW 
$PROGRESS_NEXT $PROGRESS_END >&3
ret=$?
else
-   wget $QSWITCH "$@" 
+   wget $NVSWITCH "$@"
ret=$?
fi
return $ret

Bug#780706: Arduino packaging

[Geert Stappers]

On Tue, Mar 20, 2018 at 12:04:58AM +0100, Geert Stappers wrote:
> On Mon, Mar 19, 2018 at 11:13:33AM -0300, Ignacio Losiggio wrote:
> > I think that org.bouncycastle.util.Iterable is in `libbcprov-java`, you can
> > see the dependency list i've come up with while trying to package arduino
> > [here](https://github.com/HuayraLinux/pkg-arduino/blob/master/debian/control),
> > i thin it's pretty complete (i use a clean pbuilder chroot to make packages
> > :P).
> 
> Seen the URL.
> Closer looking will be done after listserialportsc upload.

https://salsa.debian.org/electronics-team/arduino/arduino/commit/4e143a8cd92dc1ba2cbf41788bee0270a9160b3d



And now the longer version
* Upload of listserialportsc is done.
  If the packages still are in the NEW queue, can be seen
  at https://ftp-master.debian.org/new.html
* The arduino build dependency list of Ignacio is now at "Salsa".
  The announced "Closer looking will be done" is done  :-)


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#893052: RFS: btrfsmaintenance/0.4.1-1 [I maintain the package]

[Sven Hoexter]

On Tue, Mar 20, 2018 at 10:38:37PM -0400, Nicholas D Steeves wrote:
> Hi Sven,
> 
> On Sat, Mar 17, 2018 at 08:06:13PM +0100, Sven Hoexter wrote:
> > Hi,
> > uploaded the package. I've to make up my mind about the kind of linux 
> > specific
> > arch all packaging stuff.
> > 
> > Sven
> 
> Thank you for sponsoring this upload :-)
> 
> Should I leave filing a wishlist bug against dpkg-dev, for the
> creation of an arch: linux-all to you, or go ahead and do it myself?

I would be surprised if that's the first time we've this issue. So I
wanted to search for prior discussions first.

Sven

Bug#875914: autopkgtest: support Conflicts: in debian/tests/control

[Daniel Kahn Gillmor]

On Tue 2018-03-20 22:42:42 +0100, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Daniel,
>
> On Fri, 15 Sep 2017 17:16:15 -0400 Daniel Kahn Gillmor
>  wrote:
>> It would be nice if we could have Conflicts: in any stanza in
>> debian/tests/control, to indicate that if a given package is installed,
>> this test should not be considered a candidate to run.
>
> If I am correct, most backends already start from a minimal environment
> by default and only add the required packages. What use case do you have
> in mind where autopkgtest give you the wrong set?

afaict, the autopkgtest spec doesn't say that all
implementations/backends will start from a minimal environment.  And
some users want to run autopkgtest locally in some schroot that might
have other packages already installed.

furthermore, there are some "minimal environments" (e.g. "standard
install") which contain packages that might be conflict with some
obscure tests (e.g. a network management daemon with a normal use case
that needs testing that doesn't work when ifupdown is present).

does this help explain why an explicit conflicts would be useful in
avoiding false negatives?

 --dkg


signature.asc
Description: PGP signature

Bug#891068: im-config: Failed to setup fcitx when zsh used as login shell

[CUI Hao]

Hi,

> Hmmm SDDM change shell parsing Xsession, then things may break.
>
> Are you sure im-config is the problem?

I agree it's likely SDDM is to blame, not im-config.

Maybe I should "forward" this bug to sddm package or its upstream. I am
new to Debian's reportbug. How should I deal with this bug report?

-- 
崔灏 / CUI Hao
Homepage: i-yu.me
Twitter: @cuihaoleo

Bug#893696: libgtk-3-0: All wayland clients crash (seems to happen when the screen was locked for a while)

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/issues/114
Control: tags -1 + pending fixed-upstream

On Wed, 21 Mar 2018 at 11:08:18 +0100, Marcus Lundblad wrote:
> libgtk-3-0: All wayland clients crash (seems to happen when the screen was 
> locked for a while)
> 
> This seems to be this upstream issue
> https://gitlab.gnome.org/GNOME/gtk/issues/114

I've pushed the upstream patches to the packaging git repository, along
with a couple of other upstream fixes from the 3.22.x branch. I'm not
able to release this right now, but other GNOME team members are welcome
to do so.

I don't seem to get this myself - GNOME Terminal reliably keeps running
across long periods of the screen being locked. Do you have an unusual
input method configured, or anything else that would cause you to be
able to reproduce this crash when I can't? For now I've described it in
the changelog as "Wayland client crashes under unspecified circumstances".

smcv

Bug#893664: sambamba: Fails to build on i386

[Andreas Tille]

Control: forwarded -1 https://github.com/biod/sambamba/issues/344
Control: tags -1 upstream

Hi,

I'm just quoting Matthias Klumpp about this bug:

On Tue, Mar 20, 2018 at 06:16:54PM +0100, Matthias Klumpp wrote:
> 
> Just in case you are wondering and because I just came across the
> FTBFS: The current Sambamba build failure on i386 is highly likely an
> upstream bug.
> They apparently didn't account for people wanting to compile Sambamba
> on a non-64bit architecture, so it likely makes sense to raise this
> issue upstream.

Thus I have opened an issue upstream[1].

Kind regards

  Andreas.

[1] https://github.com/biod/sambamba/issues/344

-- 
http://fam-tille.de

Bug#893676: hurd: internal compiler error building petsc

[Drew Parsons]

On Wed, 2018-03-21 at 09:19 +0100, Samuel Thibault wrote:
> Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote:
> > The build of PETSc 3.8 triggers an internal compiler error on hurd:
> > 
> > CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o
> >   ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <=
> > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
> >   /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:
> > In function 'VecSetInf':
> >   /<>/petsc-
> > 3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: internal
> > compiler error: Aborted
> >}
> 
> Well, perhaps it's just because the current version of gcc-7 isn't
> built.

gcc-7 7.2.0-19 is built. Does it mean it's not compatible with MPFR ?

Bug#893691: [buildd-tools-devel] Bug#893691: sbuild: Missing Depends on lintian after defaults change

[Mattia Rizzolo]

Control: forcemerge -1 893226

On Wed, Mar 21, 2018 at 09:21:58AM +, James Clarke wrote:
> Hi,
> Now that lintian defaults to enabled in 0.74.0-1, sbuild by default will
> need lintian installed, but it has no dependency on it, and thus fails
> with:
> 
> > Error reading configuration: LINTIAN binary 'lintian' does not exist or is 
> > not executable at /usr/share/perl5/Sbuild/Conf.pm line 76

Already reported.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#893701: kamailio-java-modules package (GCJ based) needs to be removed or ported to OpenJDK

[Matthias Klose]

Package: src:kamailio
Version: 5.1.2-1
Severity: serious
Tags: sid buster patch

GCJ is removed in unstable. Please remove kamailio-java-modules package (GCJ
based) or port it to OpenJDK.

A patch for removal:
http://launchpadlibrarian.net/361439657/kamailio_5.1.2-1ubuntu1_5.1.2-1ubuntu2.diff.gz

Bug#893676: hurd: internal compiler error building petsc

[Samuel Thibault]

Drew Parsons, on mer. 21 mars 2018 19:25:21 +0800, wrote:
> On Wed, 2018-03-21 at 09:19 +0100, Samuel Thibault wrote:
> > Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote:
> > > The build of PETSc 3.8 triggers an internal compiler error on hurd:
> > > 
> > > CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o
> > >   ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <=
> > > ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
> > >   /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:
> > > In function 'VecSetInf':
> > >   /<>/petsc-
> > > 3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: internal
> > > compiler error: Aborted
> > >}
> > 
> > Well, perhaps it's just because the current version of gcc-7 isn't
> > built.
> 
> gcc-7 7.2.0-19 is built.

The current version of gcc-7 is 7.3.0-12

> Does it mean it's not compatible with MPFR ?

The old version, possibly yes.

Samuel

Bug#893636: libgstreamer-plugins-bad1.0-0: New version of libgstreamer-plugins-bad1.0-0 is breaking gnome package dependencies

[aiko]

On Tue, 20 Mar 2018 21:21:23 +0200 Sebastian =?ISO-8859-1?Q?Dr=F6ge?= <
sl...@debian.org> wrote:
> On Tue, 2018-03-20 at 11:39 -0700, Edmund Loo wrote:
> > Package: libgstreamer-plugins-bad1.0-0
> > Version: 1.14.0-1
> > Severity: important
> > Tags: upstream
> > 
> The relevant packages have to be rebuilt, specifically webkit2gtk.
The
> version in experimental is already rebuilt and you could install that
> as a workaround for now.
> 
> In unstable this should be just a matter of time.

Thank you for the hint.

$ sudo bash -c 'echo "deb http://ftp.debian.org/debian/ experimental
main contrib non-free" >> /etc/apt/sources.list'

$ sudo apt install -t experimental libwebkit2gtk-4.0-37

Kind regards,
Aiko

Bug#893551: listserialportsc 1.4.0-1 pending

[Geert Stappers]

Control: tag -1 pending

- Forwarded message from Debian FTP Masters -

Date: Wed, 21 Mar 2018 09:38:58 +
From: Debian FTP Masters 
To: Rock Storm , stapp...@debian.org
Subject: listserialportsc_1.4.0-1_amd64.changes is NEW

binary:liblistserialsj-dev is NEW.
binary:liblistserialsj1 is NEW.
binary:listserialportsc is NEW.
binary:liblistserialsj-dev is NEW.
binary:liblistserialsj1 is NEW.
binary:listserialportsc is NEW.
source:listserialportsc is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

- End forwarded message -

 
Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#893369: 893369

[Felix Defrance]

Hi,

I confirm this bug. It break the normal booting.

I temporary solved the problem by installing systemd in version 237-4
(the installation of 238-2 don't solve the problem)

There is my log, I hope that can help

## Logs

journalctl -alb -u systemd-udevd.service

-- Logs begin at Wed 2018-03-21 09:03:00 CET, end at Wed 2018-03-21
09:16:56 CET. --
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Main process
exited, code=killed, status=31/SYS
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Failed with
result 'signal'.
mars 21 09:03:00 stellar systemd[1]: Failed to start udev Kernel Device
Manager.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Service has
no hold-off time, scheduling restart.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Scheduled
restart job, restart counter is at 2.
mars 21 09:03:00 stellar systemd[1]: Stopped udev Kernel Device Manager.
mars 21 09:03:00 stellar systemd[1]: Starting udev Kernel Device Manager...
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Main process
exited, code=killed, status=31/SYS
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Failed with
result 'signal'.
mars 21 09:03:00 stellar systemd[1]: Failed to start udev Kernel Device
Manager.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Service has
no hold-off time, scheduling restart.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Scheduled
restart job, restart counter is at 3.
mars 21 09:03:00 stellar systemd[1]: Stopped udev Kernel Device Manager.
mars 21 09:03:00 stellar systemd[1]: Starting udev Kernel Device Manager...
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Main process
exited, code=killed, status=31/SYS
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Failed with
result 'signal'.
mars 21 09:03:00 stellar systemd[1]: Failed to start udev Kernel Device
Manager.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Service has
no hold-off time, scheduling restart.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Scheduled
restart job, restart counter is at 4.
mars 21 09:03:00 stellar systemd[1]: Stopped udev Kernel Device Manager.
mars 21 09:03:00 stellar systemd[1]: Starting udev Kernel Device Manager...
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Main process
exited, code=killed, status=31/SYS
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Failed with
result 'signal'.
mars 21 09:03:00 stellar systemd[1]: Failed to start udev Kernel Device
Manager.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Service has
no hold-off time, scheduling restart.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Scheduled
restart job, restart counter is at 5.
mars 21 09:03:00 stellar systemd[1]: Stopped udev Kernel Device Manager.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Start
request repeated too quickly.
mars 21 09:03:00 stellar systemd[1]: systemd-udevd.service: Failed with
result 'signal'.
mars 21 09:03:00 stellar systemd[1]: Failed to start udev Kernel Device
Manager.

/var/log/apt/history.log

Start-Date: 2018-03-20  14:02:40
Commandline: apt full-upgrade
Requested-By: fdef (1000)
Install: libpam0g:i386 (1.1.8-3.7, automatic), libdevmapper1.02.1:i386
(2:1.02.145-4.1, automatic), libseccomp2:i386 (2.3.1-2.1, automatic),
gir1.2-mutter-2:amd64 (3.28.0-1, automatic), libargon2-0:i386
(0~20161029-1.1, automatic), libacl1:i386 (2.2.52-3+b1, automatic),
libkmod2:i386 (25-1, automatic), libmutter-2-0:amd64 (3.28.0-1,
automatic), libapparmor1:i386 (2.12-3, automatic), libattr1:i386
(1:2.4.47-2+b2, automatic), libpam-systemd:i386 (238-2, automatic),
systemd:i386 (238-2, automatic), libcap-ng0:i386 (0.7.7-3.1+b1,
automatic), libidn11:i386 (1.33-2.1, automatic),
libcairo-gobject-perl:amd64 (1.004-2+b2, automatic),
libcryptsetup12:i386 (2:2.0.1-1, automatic), libgtk3-perl:amd64
(0.032-1, automatic), libglib-object-introspection-perl:amd64 (0.044-2,
automatic), libjson-c3:i386 (0.12.1-1.3, automatic), libip4tc0:i386
(1.6.2-1, automatic), libaudit1:i386 (1:2.8.2-1, automatic)
Upgrade: vlc-bin:amd64 (3.0.1-2, 3.0.1-3), evince:amd64 (3.26.0-3,
3.27.92-1), libgcc-7-dev:amd64 (7.3.0-5, 7.3.0-11), libmpx2:amd64
(8-20180218-1, 8-20180312-2), libopencv-photo3.2:amd64 (3.2.0+dfsg-4+b3,
3.2.0+dfsg-4+b4), vlc-plugin-video-output:amd64 (3.0.1-2, 3.0.1-3),
librpmsign8:amd64 (4.14.0+dfsg1-2, 4.14.1+dfsg1-2), python2.7-dev:amd64
(2.7.14-6, 2.7.14-7), libpython3.6-minimal:amd64 (3.6.4-4, 3.6.5~rc1-1),
libpackagekit-glib2-18:amd64 (1.1.7-1, 1.1.9-1), rpm2cpio:amd64
(4.14.0+dfsg1-2, 4.14.1+dfsg1-2), libvte-2.91-0:amd64 (0.50.2-4,
0.52.0-1), gedit:amd64 (3.27.92-1, 3.28.0-1), gir1.2-gtk-3.0:amd64
(3.22.28-1, 3.22.29-1), gedit-plugin-dashboard:amd64 (3.27.92-1,
3.28.0-1), vnstat:amd64 (1.17-1, 1.18-1), python-samba:amd64
(2:4.7.4+dfsg-1, 2:4.7.4+dfsg-2), libevdocument3-4:amd64 (3.26.0-3,
3.27.92-1), libwacom-common:amd64 (0.26-1, 0.29-1),
g

Bug#889872: show-ip: load fails: TypeError: Object is NM.IPAddress.prototype, not an object instance - cannot convert to a boxed instance

[Kyle Robbertze]

Control: notforwarded -1
Control: tags -1 - fixed-upstream

On 20/03/2018 07:03, Paul Wise wrote:
> Control: tags -1 + fixed-upstream
> Control: forwarded -1 
> https://github.com/sgaraud/gnome-extension-show-ip/commit/a2857aea4a38bb7737e1954e2bca20c35959156b
> 

This commit was included in 8-3 as suggested here [1]. Thus this issue
seems to be unrelated to that commit.

Does installing from source fix the issue? If so then it is something to
do with how I have patched it. Otherwise I will forward this upstream.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887998



signature.asc
Description: OpenPGP digital signature

Bug#893702: Please stop build-depending on pdftk

[Matthias Klose]

Package: src:diffoscope
Version: 91
Severity: serious
Tags: sid buster patch

pdftk still still depends on GCJ, and is likely to be removed when gcj is
removed. Please stop build-depending on pdftk.

patch at
http://launchpadlibrarian.net/361431924/diffoscope_91build1_91ubuntu1.diff.gz

Bug#893703: sdaps depends on pdftk (likely to be removed when gcj is removed)

[Matthias Klose]

Package: src:sdaps
Version: 1.2.1-1
Severity: serious
Tags: sid buster

sdaps depends on pdftk (likely to be removed when gcj is removed).  The sources
mention that it can be built with pyPDF instead, however it doesn't work with
the python-pypdf2 package in Debian.

Bug#893668: adminer: CVE-2018-7667

[Chris Lamb]

Hi Salvatore,

> I think there litte which upstream could do in addition to what was
> done in 4.4.0 upstream do mitigate the issue, or am I missing
> something?

I agree. I filed this bug mostly to track the uploads to wheezy,
jessie, jessie-backports and stretch :)

Can I get an ACK from you to upload those to *-security?


Regards,

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

Bug#870133: This should have been fixed in unstable.

[Paul Wise]

Control: fixed -1 0.9.6.6-1

On Wed, 2018-03-21 at 09:13 +, Lumin wrote:

> The newest version doesn't reproduce issue from tests provided
> by original post. Hence closing.

Please use a versioned -done message when closing fixed bugs:

https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#848101: [Pkg-raspi-maintainers] Bug#848101: marked as done (Package name + config.txt & cmdline.txt as conffiles)

[Arjen Balfoort]

Error on postinst raspi3-firmware 1.20180316-2:

DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware

should be:

DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/50raspi3-firmware


After fixing that the package installed correctly and I could set up a 
hook to overwrite cmdline.txt and config.txt on kernel update.
Custom package created for SolydX RPi3: 
https://github.com/SolydXK/solydx-raspi3-adjustments

Bug#893705: stretch-pu: package trafficserver/7.0.0-6+deb9u1

[Jean Baptiste Favre]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,
I'd like to upload a new version of package trafficserver into stable.
The only change is related to trafficserver-dev dependencies which currently 
break piuparts tests.

Diff is:
- --- a/debian/control
+++ b/debian/control
@@ -53,8 +53,7 @@ Description: experimental plugins for Apache Traffic Server
 
 Package: trafficserver-dev
 Architecture: any
- -Depends: ${misc:Depends}
- -Suggests: trafficserver (= ${binary:Version})
+Depends: ${misc:Depends}, trafficserver (= ${binary:Version})
 Description: Apache Traffic Server Software Developers Kit (SDK)
  This package provides the Apache Traffic Server Software  Developers Kit.
  This is a collection of development header and bindings for the C programming

Any advice or comment will be welcomed.

Cheers,
Jean Baptiste

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAlqyVe1fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hzdZfBAAssZL+jdDhKyQcZfco/9qS5m3G9XkbWZls5uG2bEU9iCpCjbnWi8eITG+
EQVavAm1D8WUFl/EdN1yeB+FGXz5lJZfAVKWE5KW634DC5tXv8yGUuZ9JuJIIeAS
L9WbX7ZBgCIO+ddXjGfw86Rn4uW4SxLlAjdBDXnrzHMJ+Kgy2mUaUnSZaJbWWCgH
tvepITViClZzZolf9cKPzta4seLF/TWVPJyhTh6dpAzNn+Osc+suStX+27PGn0F5
fx3BAKKijRt9bo3CqWioU5Lho4YzOPEgaIEQmO8V4kGO7a8pFY3CJmkTu7niXvVN
cg0fUOEyyYJkuFMBxPjWe2WkU2odkLO/gXzVq4zWPc38rd84vNI1Q83LThGLUIMJ
Lz/OaveOhdXeZS6O1EeBX9/1lcLu6PWbcU00nLwbBhb1McPBW/182U8D3rYHIlQO
NofPCKEf0C0nv/YoKkP1PYm7pvrbN9TKxm4gsNx1c2jsoDQ71E4HxnQkSUceXg5R
4Q8tyUnfRWZDsMR3mnOyRrZKeAj2t0L4eYQYG1eLXa0eNyqPdjc+YPitpIHelzF0
RUyNb7DBcSKS6mp548MbB+u9WQLAXJ78KxTpE9iLgJJzVffEB5BrKH5GOpuvdxzD
DYNRqShMayTEi9bTqnVWGS1xC2jyLyLyW5zQpkFWaduk1cdes00=
=Bkvj
-END PGP SIGNATURE-

Bug#848101: [Pkg-raspi-maintainers] Bug#848101: Bug#848101: marked as done (Package name + config.txt & cmdline.txt as conffiles)

[Michael Stapelberg]

Thanks for the hint, I missed that location. Uploaded -3 with a fix.

On Wed, Mar 21, 2018 at 1:49 PM, Arjen Balfoort 
wrote:

> Error on postinst raspi3-firmware 1.20180316-2:
>
> DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware
>
> should be:
>
> DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/50raspi3-firmware
>
>
> After fixing that the package installed correctly and I could set up a
> hook to overwrite cmdline.txt and config.txt on kernel update.
> Custom package created for SolydX RPi3: https://github.com/SolydXK/sol
> ydx-raspi3-adjustments
>
> ___
> Pkg-raspi-maintainers mailing list
> pkg-raspi-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers
>



-- 
Best regards,
Michael

Bug#893704: please remove dependency pdftk (will be removed when GCJ is removed)

[Matthias Klose]

Package: src:impressive
Version: 0.12.0-1
Severity: serious
Tags: sid buster patch

please remove the dependency on pdftk (will be removed when GCJ is removed).

patch to build without pdftk:
http://launchpadlibrarian.net/361431082/impressive_0.12.0-1_0.12.0-1ubuntu1.diff.gz

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Luca Boccassi]

On Wed, 2018-03-21 at 08:56 +0100, Philipp Kern wrote:
> On 03/20/2018 10:59 PM, Luca Boccassi wrote:
> > The problems I see are that it would make an already quite complex
> > packaging system, over which we have very little control (most of
> > it
> > it's binary blobs) even more complicated. We already have 2 layers
> > of
> > update-alternatives (mesa vs nvidia and then current vs legacy).
> > 
> > It would also mean we have to start maintaining multiple versions
> > at
> > the same time - again being all binary blobs, which will multiply
> > the
> > source of problems. Basically, it would mean that instead of having
> > current vs legacy340xx (up until a few months ago also
> > legacy304xx),
> > every single driver update would have to be maintained separately.
> 
> I don't propose this as the solution, though. I think that'd indeed
> be
> infeasible. What I'm saying is that the *binary* packages are
> versioned
> like this, not the source packages. It's like the kernel in a way,
> where
> every ABI version gets its own binary package name. Although in
> Debian
> the hesitance to change the ABI is much higher than in Ubuntu, for
> reasons that I assume have to do with the NEW queue. Cleaning up
> older
> versions is something we'd find a solution for, just like people
> clean
> up their old kernels.
> 
> So please separate out maintenance from the proposal. ;-)

Ah I see - one issue I can foresee is that it's binary blobs all the
way down - so there's really no way to know that libnvidia-foo from
version 1.1 can work with libnvidia-bar from version 2.2. So all the
packages would have to be versioned.

Isn't this sort-of-like what Ubuntu does? IIRC they lump together
everything into a single package unlike we do, and they are named after
the major revision.

How would the switch-at-boot mechanism work?

> I get it with the two layers of alternatives. Is the reason for mesa
> vs.
> nvidia because we don't put Nvidia into the library search path first
> and need to deal with the corresponding file conflicts in a sane way?
> Or
> because we want to keep co-installability between mesa and nvidia?

co-installability - it used to be that each vendor had its own version
of libGL, and they were all incompatible with each other. With libglvnd
this is changing - but sadly we need to keep shipping the non-glvnd
versions as there are often regressions (and some use cases don't work
with the glvnd versions yet, like switchable graphics on laptops).
So in reality what glvnd is doing for us right now is multiplying the
maintenance effort rather than reducing it. But I digress...

> > In the end the problem is an annoyance but not a deal breaker -
> > updates
> > can be scheduled and delayed (unlike some other OSes...), and on
> > top of
> > that, version bumps are not that common - at most once a month, and
> > only for those running unstable or testing - in stable we just ship
> > LTS
> > versions.
> 
> Actually it's a real deal breaker in mass deployments. If your users
> are
> hesitant to do reboots because it resets their work environment, you
> really need to detach nvidia updates from the rest of the package
> updates, which means having a custom-built solution to do that. That
> has
> turned out to be brittle, as it turns out that you end up installing
> pre-downloaded modules at boot, blocking it for about ten minutes.
> (It
> has gotten better with SSDs, but still.)
> 
> Even if you just ship LTS versions there are sometimes updates
> needed,
> be it for Meltdown/Spectre or new hardware. In our case we actually
> do
> use testing, but even then we had the need to push updates to
> drivers. I
> think a setup that separates out binaries for every version that
> allows
> for consistent rollbacks[1] and rollforwards would be beneficial not
> just for us but also for the whole userbase of Debian.
> 
> We'd be willing to invest some time into a solution - as our own to
> work
> around the flaws in the packaging has turned out to be a maintenance
> headache. But that only works if we at least agree on a plan. I'm
> also
> happy to clarify more that I probably missed in the proposal. :)
> 
> Kind regards and thanks
> Philipp Kern
> 
> [1] We had a bunch of regressions with newer drivers in the past that
> made them dead on arrival, like missing repaints in terminals for a
> fraction of the cards.

Ok so now I understand you have some large deployments where this is an
actual issue - I didn't get it immediately, sorry.

I'm up for talking about proposals - Andreas, what do you think?

-- 
Kind regards,
Luca Boccassi

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

Bug#893706: python2: hazmat memory leak script causes core dump (works in py3k) on x32

[Thorsten Glaser]

Package: python2.7-minimal
Version: 2.7.14-7
Severity: important

tglase@tglase:~ $ python x; echo $? 
Segmentation fault (core dumped) 
139
tglase@tglase:~ $ python3 x; echo $?
0

Test script, from src:python-cryptography_2.1.4-1, attached.

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages python2.7-minimal depends on:
ii  libc6 2.27-2
ii  libpython2.7-minimal  2.7.14-7
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages python2.7-minimal recommends:
ii  python2.7  2.7.14-7

Versions of packages python2.7-minimal suggests:
ii  binfmt-support  2.1.8-2

-- no debconf information
def func():
pass

import sys


def main(argv):
import gc
import json

from cryptography.hazmat.bindings._openssl import ffi, lib

heap = {}

@ffi.callback("void *(size_t, const char *, int)")
def malloc(size, path, line):
ptr = lib.Cryptography_malloc_wrapper(size, path, line)
heap[ptr] = (size, path, line)
return ptr

@ffi.callback("void *(void *, size_t, const char *, int)")
def realloc(ptr, size, path, line):
if ptr != ffi.NULL:
del heap[ptr]
new_ptr = lib.Cryptography_realloc_wrapper(ptr, size, path, line)
heap[new_ptr] = (size, path, line)
return new_ptr

@ffi.callback("void(void *, const char *, int)")
def free(ptr, path, line):
if ptr != ffi.NULL:
del heap[ptr]
lib.Cryptography_free_wrapper(ptr, path, line)

result = lib.Cryptography_CRYPTO_set_mem_functions(malloc, realloc, free)
assert result == 1

# Trigger a bunch of initialization stuff.
import cryptography.hazmat.backends.openssl

start_heap = set(heap)

func(*argv[1:])
gc.collect()
gc.collect()
gc.collect()

# Swap back to the original functions so that if OpenSSL tries to free
# something from its atexit handle it won't be going through a Python
# function, which will be deallocated when this function returns
result = lib.Cryptography_CRYPTO_set_mem_functions(
ffi.addressof(lib, "Cryptography_malloc_wrapper"),
ffi.addressof(lib, "Cryptography_realloc_wrapper"),
ffi.addressof(lib, "Cryptography_free_wrapper"),
)
assert result == 1

remaining = set(heap) - start_heap

if remaining:
sys.stdout.write(json.dumps(dict(
(int(ffi.cast("size_t", ptr)), {
"size": heap[ptr][0],
"path": ffi.string(heap[ptr][1]).decode(),
"line": heap[ptr][2],
})
for ptr in remaining
)))
sys.stdout.flush()
sys.exit(255)

main(sys.argv)

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[micah]

"Adam D. Barratt"  writes:

> Control: tags -1 + moreinfo
>
> On Tue, 2018-03-20 at 16:32 -0400, micah wrote:
>> The leap-archive-keyring is a simple archive keyring package that
>> contains the
>> signing key for trusting the archive of the LEAP encryption access
>> project. Unfortunately, the expiration date chosen for the key that
>> is included
>> in the package in Stretch was too low, and it has expired.
>> 
>> The newer package that is available in testing, unstable, and
>> backports provides
>> a key with a sufficient length to cover the stable release cycle.
>> 
>> I would like to propose that this package be included in the next
>> stable release point update.
>
> We'd need to see a debdiff of the proposed upload, built on and tested
> against stretch, please.

Sorry, I thought I had attached the debdiff, here it is:



debdiff
Description: Binary data


signature.asc
Description: PGP signature

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Luca Boccassi]

Control: severity -1 normal

On Wed, 2018-03-21 at 08:17 +, Michael Schaller wrote:
> Please reconsider that this is merely an annoyance and that this is a
> wishlist item.
> If a NVIDIA driver security update is pushed and security updates are
> installed unattendedly then all NVIDIA user space components will
> stop
> working immediately after the respective package updates as the
> loaded
> kernel module and the user space components have a version mismatch.
> The consequences are not immediately visible to the user as NVIDIA
> components in memory are still properly matched and hence still work.
> The
> real issue is with new processes as for an instance no OpenGL
> applications
> or CUDA workloads can be launched anymore. This is especially severe
> for
> CUDA server farms as they currently can't enable unattended security
> updates unless they specifically exclude NVIDIA driver updates.

That's fine, I didn't grok that you had large installations where this
was causing issues already, personally I'm fine with talking about
possible solutions.

Seeing your email address domain - any chance your company could use
its gargantuan soft-power to get Nvidia to publish the specs for the
missing parts of Nouveau (reclocking, power managerment, etc)? That
would solve all our problems once and for all :-P

> On Wed, Mar 21, 2018 at 9:00 AM Philipp Kern 
> wrote:
> 
> > On 03/20/2018 10:59 PM, Luca Boccassi wrote:
> > > The problems I see are that it would make an already quite
> > > complex
> > > packaging system, over which we have very little control (most of
> > > it
> > > it's binary blobs) even more complicated. We already have 2
> > > layers of
> > > update-alternatives (mesa vs nvidia and then current vs legacy).
> > > 
> > > It would also mean we have to start maintaining multiple versions
> > > at
> > > the same time - again being all binary blobs, which will multiply
> > > the
> > > source of problems. Basically, it would mean that instead of
> > > having
> > > current vs legacy340xx (up until a few months ago also
> > > legacy304xx),
> > > every single driver update would have to be maintained
> > > separately.
> > I don't propose this as the solution, though. I think that'd indeed
> > be
> > infeasible. What I'm saying is that the *binary* packages are
> > versioned
> > like this, not the source packages. It's like the kernel in a way,
> > where
> > every ABI version gets its own binary package name. Although in
> > Debian
> > the hesitance to change the ABI is much higher than in Ubuntu, for
> > reasons that I assume have to do with the NEW queue. Cleaning up
> > older
> > versions is something we'd find a solution for, just like people
> > clean
> > up their old kernels.
> > So please separate out maintenance from the proposal. ;-)
> > I get it with the two layers of alternatives. Is the reason for
> > mesa vs.
> > nvidia because we don't put Nvidia into the library search path
> > first
> > and need to deal with the corresponding file conflicts in a sane
> > way? Or
> > because we want to keep co-installability between mesa and nvidia?
> > > In the end the problem is an annoyance but not a deal breaker -
> > > updates
> > > can be scheduled and delayed (unlike some other OSes...), and on
> > > top of
> > > that, version bumps are not that common - at most once a month,
> > > and
> > > only for those running unstable or testing - in stable we just
> > > ship LTS
> > > versions.
> > Actually it's a real deal breaker in mass deployments. If your
> > users are
> > hesitant to do reboots because it resets their work environment,
> > you
> > really need to detach nvidia updates from the rest of the package
> > updates, which means having a custom-built solution to do that.
> > That has
> > turned out to be brittle, as it turns out that you end up
> > installing
> > pre-downloaded modules at boot, blocking it for about ten minutes.
> > (It
> > has gotten better with SSDs, but still.)
> > Even if you just ship LTS versions there are sometimes updates
> > needed,
> > be it for Meltdown/Spectre or new hardware. In our case we actually
> > do
> > use testing, but even then we had the need to push updates to
> > drivers. I
> > think a setup that separates out binaries for every version that
> > allows
> > for consistent rollbacks[1] and rollforwards would be beneficial
> > not
> > just for us but also for the whole userbase of Debian.
> > We'd be willing to invest some time into a solution - as our own to
> > work
> > around the flaws in the packaging has turned out to be a
> > maintenance
> > headache. But that only works if we at least agree on a plan. I'm
> > also
> > happy to clarify more that I probably missed in the proposal. :)
> > Kind regards and thanks
> > Philipp Kern
> > [1] We had a bunch of regressions with newer drivers in the past
> > that
> > made them dead on arrival, like missing repaints in terminals for a
> > fraction of the cards.
> > --
> > To unsubscribe, send mail to 889669-unsub

Bug#893707: budgie-indicator-applet: Build against support Ayatana and Ubuntu Indicators alike

[Mike Gabriel]

Package: budgie-indicator-applet
Version: 0.3-1
Tags: patch
Severity: wishlist

Dear maintainer of the Budgie Desktop,

please find attached a .debdiff that provides some new functionality  
for the Budgie Indicator Applet.


A small team is currently driving forward the development of a project  
called Ayatana Indicators. This project has been derived from the  
Indicator approach we have seen in Ubuntu now for a while.


Unfortunately, the Ubuntu Indicators are limited to the Ubuntu  
distribution, only. With Ayatana Indicators, we are currently  
undertaking an effort to make Indicators more portable and usable on  
all Linux and non-Linux-but-*nix desktops.


The attached .debdiff provides these changes (quoting myself from  
debian/changelog):


```
budgie-indicator-applet (0.3-1.1+ayatana) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  * debian/patches:
+ Add 01_ayatana-indicators.patch. Make the package build
  against Ubuntu Indicators and Ayatana Indicators alike.
+ Add 02_aytana-indicators-ng.patch. Re-enable (and fix)
  Indicators NG file support (loading indicators from service
  files.
  * debian/control:
+ Add B-Ds: libayatana-indicator3-dev, libayatana-ido3-0.4-dev.
  to support building against Ayatana Indicators on Debian. Leaving
  Ubuntu Indicators B-Ds in the control file, too, so that on Ubuntu
  we can build (see debian/rules) against Ubuntu Indicators.
  * debian/rules:
+ Select the Indicator implementation to build against based on the
  distribution the package is built for (Debian vs. Ubuntu).

 -- Mike Gabriel   Wed, 21 Mar 2018  
14:00:27 +0100

```

Please consider applying my changes to the package and promoting the  
patches upstream.


Thanks for your time!

Mike
--

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

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

diff -Nru budgie-indicator-applet-0.3/debian/changelog 
budgie-indicator-applet-0.3/debian/changelog
--- budgie-indicator-applet-0.3/debian/changelog2016-12-20 
11:27:29.0 +0100
+++ budgie-indicator-applet-0.3/debian/changelog2018-03-21 
14:00:27.0 +0100
@@ -1,3 +1,23 @@
+budgie-indicator-applet (0.3-1.1+ayatana) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches:
++ Add 01_ayatana-indicators.patch. Make the package build
+  against Ubuntu Indicators and Ayatana Indicators alike.
++ Add 02_aytana-indicators-ng.patch. Re-enable (and fix)
+  Indicators NG file support (loading indicators from service
+  files.
+  * debian/control:
++ Add B-Ds: libayatana-indicator3-dev, libayatana-ido3-0.4-dev.
+  to support building against Ayatana Indicators on Debian. Leaving
+  Ubuntu Indicators B-Ds in the control file, too, so that on Ubuntu
+  we can build (see debian/rules) against Ubuntu Indicators.
+  * debian/rules:
++ Select the Indicator implementation to build against based on the
+  distribution the package is built for (Debian vs. Ubuntu).
+
+ -- Mike Gabriel   Wed, 21 Mar 2018 14:00:27 
+0100
+
 budgie-indicator-applet (0.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru budgie-indicator-applet-0.3/debian/control 
budgie-indicator-applet-0.3/debian/control
--- budgie-indicator-applet-0.3/debian/control  2016-12-18 19:38:39.0 
+0100
+++ budgie-indicator-applet-0.3/debian/control  2018-03-21 12:08:05.0 
+0100
@@ -8,9 +8,11 @@
libtool,
libgtk-3-dev,
libindicator3-dev,
+   libayatana-indicator3-dev,
libpeas-dev,
budgie-core-dev,
-   libido3-0.1-dev
+   libido3-0.1-dev,
+   libayatana-ido3-0.4-dev,
 Standards-Version: 3.9.8
 Homepage: https://github.com/UbuntuBudgie/budgie-indicator-applet
 Vcs-Browser: 
https://github.com/UbuntuBudgie/budgie-indicator-applet/tree/debian
diff -Nru 
budgie-indicator-applet-0.3/debian/patches/01_ayatana-indicators.patch 
budgie-indicator-applet-0.3/debian/patches/01_ayatana-indicators.patch
--- budgie-indicator-applet-0.3/debian/patches/01_ayatana-indicators.patch  
1970-01-01 01:00:00.0 +0100
+++ budgie-indicator-applet-0.3/debian/patches/01_ayatana-indicators.patch  
2018-03-21 13:02:58.0 +0100
@@ -0,0 +1,363 @@
+--- a/configure.ac
 b/configure.ac
+@@ -19,25 +19,174 @@
+ budgie-1.0 >= budgie_required_version
+ )
+ 
+-INDICATOR_API_VERSION=3
+-INDICATOR_REQUIRED_VERSION=0.3.90
+-INDICATOR_NG_VERSION=0.5
+-INDICATOR_PKG=indicator$INDICATOR_API_VERSION-0.4
+-
+-PKG_CHECK_MODULES(INDICATOR, $INDICATOR_PKG >= $INDICATOR_NG_VERSION
+-  libido3-0.1 >= 0.3.4,
+-  [AC_DEFINE(HAVE_INDICATOR_NG, 1, "New style indicators 
support")])
+-  
+-

Bug#893709: ITP: node-extract-text-webpack-plugin -- Extract text from bundle into a file

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-extract-text-webpack-plugin
  Version : 3.0.2
  Upstream Author : Tobias Koppers @sokra
* URL :
http://github.com/webpack-contrib/extract-text-webpack-plugin
* License : Expat
  Programming Lang: JavaScript
  Description : Extract text from bundle into a file

 Extract text from bundle into a file
 It moves all the required *.css modules in entry chunks into a separate CSS
 file. So styles are no longer inlined into the JS bundle, but in a separate
 CSS file (styles.css). If total stylesheet volume is big, it will be faster
 because the CSS bundle is loaded in parallel to the JS bundle.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain of gitlab 10 (build dependency of katex).



signature.asc
Description: OpenPGP digital signature

Bug#893708: python-phply and python3-phply needlessly conflict with each other

[Stuart Prescott]

Source: python-phply
Version: 1.2.2-1
Severity: important

Dear Maintainer,

The python-phply and python3-phply pacakges conflict with each other because
they both include /usr/bin/phpparse and /usr/bin/phplex. This packaging is
incorrect:

 * the executables should be in a separate package phply or only in the
   python3-phply package

 * the *public* modules for phply for both Python 2 and Python 3 should be
   co-installable

 * there should be no conflicts

The current situation prevents a python-foo depending on python-phply and
python3-bar depending on python3-phply from being installed at the same
time. The next release of translate-toolkit will build-depend on both
python-phply and python3-phply and it is not currently possible to install
the necessarily build-dependencies.

regards
Stuart

Bug#893711: please provide an HTML version of the documentation

[Sébastien Villemot]

Package: src:emacs25-non-dfsg
Version: 25.2+1-1
Severity: wishlist

Dear Maintainer,

Please provide an HTML version of the Emacs documentation (keeping in mind that
HTML is the preferred documentation format in Debian, per policy 12.4).

You will have to decide whether shipping documents in a single page or in
multiple pages (upstream has both for the manual on its website¹). I tend to
favor the single page format, since that facilitates text searching within the
browser.

Cheers,

¹ https://www.gnu.org/software/emacs/manual/emacs.html

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#893710: wxhexeditor: please package 0.24 (patch included) - fixes serious bug (gcc-7 build failure)

[Norbert Preining]

Package: wxhexeditor
Version: 0.24+repack-0.1
Severity: important
Tags: patch

Hi,

please package wxhexeditor 0.24, it fixes the ftbfs with gcc7.

I attach a diff between the debian directories for a package I created
locally. It builds fine with current gcc in sid.

Thanks

Norbert


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

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

Versions of packages wxhexeditor depends on:
ii  libc6 2.27-2
ii  libdisasm00.23-6+b1
ii  libgcc1   1:8-20180320-1
ii  libgomp1  8-20180320-1
ii  libmhash2 0.9.9.9-7+b1
ii  libstdc++68-20180320-1
ii  libwxbase3.0-0v5  3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v5   3.0.3.1+dfsg2-1

wxhexeditor recommends no packages.

wxhexeditor suggests no packages.

-- no debconf information
diff -urN wxhexeditor-0.23+repack/debian/changelog 
wxhexeditor-0.24+repack/debian/changelog
--- wxhexeditor-0.23+repack/debian/changelog2015-06-10 15:30:42.0 
+0900
+++ wxhexeditor-0.24+repack/debian/changelog2018-03-21 21:58:20.0 
+0900
@@ -1,3 +1,10 @@
+wxhexeditor (0.24+repack-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+
+ -- Norbert Preining   Wed, 21 Mar 2018 21:58:20 +0900
+
 wxhexeditor (0.23+repack-2) unstable; urgency=medium
 
   * Merge wxWidgets 3.0 changes from NMUs by Olly Betts.
diff -urN 
wxhexeditor-0.23+repack/debian/patches/01-build-with-system-mhash.patch 
wxhexeditor-0.24+repack/debian/patches/01-build-with-system-mhash.patch
--- wxhexeditor-0.23+repack/debian/patches/01-build-with-system-mhash.patch 
2015-05-21 19:58:20.0 +0900
+++ wxhexeditor-0.24+repack/debian/patches/01-build-with-system-mhash.patch 
2018-03-21 21:48:19.0 +0900
@@ -1,17 +1,22 @@
 Description: Build with system mhash. Also fix the variables order.
 
 a/Makefile
-+++ b/Makefile
-@@ -5,7 +5,7 @@
- CXX = `$(WXCONFIG) --cxx`
- LDFLAGS += -lgomp
- #add this ldflags for WinConsole  "-Wl,--subsystem,console -mconsole" for 
win-debug
--WXCXXFLAGS= `$(WXCONFIG) --cxxflags` -Iudis86 -Imhash/include -MMD -fopenmp
-+WXCXXFLAGS= `$(WXCONFIG) --cxxflags` -Iudis86 -MMD -fopenmp
+---
+ Makefile   |9 ++---
+ src/HexDialogs.cpp |2 +-
+ src/HexEditor.h|2 +-
+ 3 files changed, 4 insertions(+), 9 deletions(-)
+
+--- wxHexEditor-0.24.orig/Makefile
 wxHexEditor-0.24/Makefile
+@@ -1,6 +1,6 @@
+ WXCONFIG ?= wx-config
+ HOST=
+-WXCXXFLAGS= `$(WXCONFIG) --cxxflags` -Iudis86 -Imhash/include -MMD -fopenmp 
-Wall -O2
++WXCXXFLAGS= `$(WXCONFIG) --cxxflags` -Iudis86 -MMD -fopenmp -Wall -O2
  WXLDFLAGS = `$(WXCONFIG) --libs` `$(WXCONFIG) --libs aui` `$(WXCONFIG) --libs 
core`
- RC = `$(WXCONFIG) --rescomp`
- #RC = x86_64-w64-mingw32-windres --define WX_CPU_AMD64
-@@ -25,7 +25,7 @@
+ WXCXXFLAGS += -fopenmp
+ LDFLAGS += -lgomp
+@@ -22,7 +22,7 @@
src/HexEditorCtrl/wxHexCtrl/Tag.cpp\
src/HexEditorCtrl/HexEditorCtrlGui.cpp\
src/HexEditorFrame.cpp
@@ -20,31 +25,18 @@
  OBJECTS=$(SOURCES:.cpp=.o)
  DEPENDS=$(OBJECTS:.o=.d)
  LANGUAGEDIRS=`ls -l ./locale | grep ^d | sed s/.*\ //g;`
-@@ -50,10 +50,10 @@
- MOBJECTS=$(LANGUAGES:.po=.mo)
- 
- $(EXECUTABLE): $(OBJECTS)
--  $(CXX) ${LDFLAGS} $(OBJECTS) $(LIBS) ${CXXFLAGS} ${OPTFLAGS} 
$(WXLDFLAGS) -o $@
-+  $(CXX) ${CXXFLAGS} ${CPPFLAGS} ${LDFLAGS} $(OBJECTS) $(LIBS) 
$(WXLDFLAGS) -o $@
- 
- .cpp.o: $(LIBS)
--  $(CXX) -c $(WXCXXFLAGS) $(OPTFLAGS) $(CXXFLAGS) $(CPPFLAGS) $< -o $@
-+  $(CXX) -c $(CXXFLAGS) $(CPPFLAGS) $(WXCXXFLAGS) $< -o $@
- 
- %.o : %.rc
-   $(RC) $(RCFLAGS) $< -o $@
-@@ -68,10 +68,6 @@
-   cd udis86;./configure --host=$(HOST) CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)"
+@@ -73,10 +73,6 @@
+   cd udis86;./configure --host=$(HOST) CC="$(CC)" CXX="$(CXX)" 
CFLAGS="$(CFLAGS) ${OPTFLAGS}" CXXFLAGS="$(CXXFLAGS) ${OPTFLAGS}" 
CPPFLAGS="$(CPPFLAGS)"
cd udis86/libudis86; $(MAKE) $(MFLAGS)
  
 -mhash/lib/.libs/libmhash.a:
--  cd mhash; ./configure --host=$(HOST) CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)"
+-  cd mhash; ./configure --host=$(HOST) CC="$(CC)" CXX="$(CXX)" 
CFLAGS="$(CFLAGS) ${OPTFLAGS}" CXXFLAGS="$(CXXFLAGS) ${OPTFLAGS}" 
CPPFLAGS="$(CPPFLAGS)"
 -  cd mhash; $(MAKE) $(MFLAGS)
 -
- win: $(RESOURCES) $(EXECUTABLE_WIN)
+ src/windrv.o:
+   $(CXX) $(LIBS) ${CXXFLAGS} ${OPTFLAGS} $(WXCXXFLAGS) $(WXLDFLAGS) 
${LDFLAGS} -c src/windrv.cpp -o src/windrv.o
  
- #Stack override required for file comparison function...
-@@ -173,7 +169,6 @@
+@@ -193,7 +189,6 @@
rm -f locale/*/wxHexEdito

Bug#878101: nemo: Nemo segfault on thumbnailing of a moved file

[Zeljko Culek]

Hello,

The issue was fixed in later versions of nemo (think 3.4+, but not 100% 
sure), and I think this was the fix, which was already reported here:


https://github.com/linuxmint/nemo/commit/b58bea5384436fda9cb6b31f7010f72d3c74e76a#diff-53011b366ae6f19d5347ce06d362d6ca

I'll test your patched version and report the results.

Can we expect the fix to be pushed to Stretch repos? This bug is really 
annoying. And man, Debian always has some buggy nemo version in stable 
branches - with Jessie, I switched to pcmanfm, as I couldn't live with 
the bugs in nemo. I'm really close to switching to pcmanfm in Stretch 
too, because of this bug, as nemo is almost unusable.

Bug#893708: python-phply and python3-phply needlessly conflict with each other

[Stuart Prescott]

Control: tags -1 patch

>  * the executables should be in a separate package phply or only in the
>python3-phply package
> 
>  * the *public* modules for phply for both Python 2 and Python 3 should be
>co-installable
> 
>  * there should be no conflicts

The attached patch implements this, only installing the executables in the 
python3-phply package.

regards
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7diff -Nru python-phply-1.2.2/debian/changelog python-phply-1.2.2/debian/changelog
--- python-phply-1.2.2/debian/changelog	2018-01-18 20:57:35.0 +1100
+++ python-phply-1.2.2/debian/changelog	2018-03-22 00:21:24.0 +1100
@@ -1,3 +1,10 @@
+python-phply (1.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix conflicts between python-phply and python3-phply (Closes: #893708).
+
+ -- Stuart Prescott   Thu, 22 Mar 2018 00:21:24 +1100
+
 python-phply (1.2.2-1) unstable; urgency=medium
 
   * New upstream version 1.2.2
diff -Nru python-phply-1.2.2/debian/control python-phply-1.2.2/debian/control
--- python-phply-1.2.2/debian/control	2018-01-18 20:57:35.0 +1100
+++ python-phply-1.2.2/debian/control	2018-03-22 00:21:24.0 +1100
@@ -19,7 +19,6 @@
 
 Package: python-phply
 Architecture: all
-Conflicts: python3-phply
 Depends: ${python:Depends}, ${misc:Depends}
 Description: PHP parser written in Python using PLY
  phply is a parser for the PHP programming language written using PLY,
@@ -33,7 +32,6 @@
 
 Package: python3-phply
 Architecture: all
-Conflicts: python-phply
 Depends: ${python3:Depends}, ${misc:Depends}
 Description: PHP parser written in Python 3 using PLY
  phply is a parser for the PHP programming language written using PLY,
@@ -43,4 +41,4 @@
- Run PHP templates in a Python environment
- Learn more about parsing "industrial" languages, warts and all
  .
- This is the Python 3 version of the package.
+ This is the Python 3 version of the package and the executables.
diff -Nru python-phply-1.2.2/debian/rules python-phply-1.2.2/debian/rules
--- python-phply-1.2.2/debian/rules	2015-08-26 19:16:02.0 +1000
+++ python-phply-1.2.2/debian/rules	2018-03-22 00:21:24.0 +1100
@@ -4,3 +4,7 @@
 export PYBUILD_NAME=phply
 %:
 	dh $@ --with python2,python3 --buildsystem=pybuild
+
+override_dh_auto_install:
+	dh_auto_install
+	rm -rf debian/python-phply/usr/bin
>From 3baf5f523ba5331683224c4781cb6d3c29c27024 Mon Sep 17 00:00:00 2001
From: Stuart Prescott 
Date: Thu, 22 Mar 2018 00:23:00 +1100
Subject: [PATCH 4/4] Add changelog for upload

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a052509..1985e7a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-phply (1.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix conflicts between python-phply and python3-phply (Closes: #893708).
+
+ -- Stuart Prescott   Thu, 22 Mar 2018 00:21:24 +1100
+
 python-phply (1.2.2-1) unstable; urgency=medium
 
   * New upstream version 1.2.2
-- 
2.11.0

>From 1eee6a08561be697a7244bf0e848a13c01de0007 Mon Sep 17 00:00:00 2001
From: Stuart Prescott 
Date: Thu, 22 Mar 2018 00:22:34 +1100
Subject: [PATCH 1/4] Only install binaries in Python3 package

---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index a799204..8c6610c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,3 +4,7 @@
 export PYBUILD_NAME=phply
 %:
 	dh $@ --with python2,python3 --buildsystem=pybuild
+
+override_dh_auto_install:
+	dh_auto_install
+	rm -rf debian/python-phply/usr/bin
-- 
2.11.0

>From b6a961dc68f881b8711a84278903388f53a7abb3 Mon Sep 17 00:00:00 2001
From: Stuart Prescott 
Date: Thu, 22 Mar 2018 00:31:41 +1100
Subject: [PATCH 2/4] Remove conflicts between packages

---
 debian/control | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/control b/debian/control
index 77bd6f3..274ffb5 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,6 @@ Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-phply.git
 
 Package: python-phply
 Architecture: all
-Conflicts: python3-phply
 Depends: ${python:Depends}, ${misc:Depends}
 Description: PHP parser written in Python using PLY
  phply is a parser for the PHP programming language written using PLY,
@@ -33,7 +32,6 @@ Description: PHP parser written in Python using PLY
 
 Package: python3-phply
 Architecture: all
-Conflicts: python-phply
 Depends: ${python3:Depends}, ${misc:Depends}
 Description: PHP parser written in Python 3 using PLY
  phply is a parser for the PHP programming language written using PLY,
-- 
2.11.0

>From bafd5a93a0a6490e759f3c9519059cd262f5599d Mon Sep 17 00:00:00 2001
From: Stuart Prescott 
Date: Thu, 22 Mar 2018 00:31:57 +1100
Subject: [PATCH 3/4] Extend d

Bug#893625: xpdf: missspelling in xpdfrc-japanese

[Florian Schlichting]

Control: tags 893625 +pending

On Wed, Mar 21, 2018 at 01:16:26AM +0900, NIDE, Naoyuki wrote:
> xpdfrc-japanese in package xpdf has a misspelling.
> In line 13, GothicBBB-Meidum should be GothicBBB-Medium.
> Due to this error, xpdf sometimes cannot correctly display the letters
> using GothicBBB-Medium font in a PDF file.

thank you for pointing this out! I have just committed a fix to Debian's
gitlab instance, so that it should be included in the next upload of
xpdf:
https://salsa.debian.org/debian/xpdf/commit/ab0bb99c4131f6b2d0fb7d5ebeec70cc5399c63a

Florian

Bug#872225: libtss-dev: broken symlink: /usr/lib/x86_64-linux-gnu/libtss.so -> /debian/libtss0/usr/lib/x86_64-linux-gnu/libtss.so.0

[Luca Boccassi]

On Wed, 07 Feb 2018 23:29:36 + Luca Boccassi 
wrote:
> On Tue, 15 Aug 2017 10:35:34 +0200 Andreas Beckmann 
> wrote:
> > Package: libtss-dev
> > Version: 1045-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package ships (or
creates)
> > a broken symlink.
> > 
> > >From the attached log (scroll to the bottom...):
> > 
> > 0m10.9s ERROR: FAIL: Broken symlinks:
> >   /usr/lib/x86_64-linux-gnu/libtss.so ->
> /debian/libtss0/usr/lib/x86_64-linux-gnu/libtss.so.0
> > 
> > 
> > The target looks like an (incorrect) build-time path.
> > 
> > 
> > cheers,
> > 
> > Andreas
> 
> Dear maintainer,
> 
> The fix for this is quite simple, patch inlined.
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> 
> --- a/debian/rules
> +++ b/debian/rules
> @@ -115,7 +115,7 @@ override_dh_auto_install:
>   dh_install -Pdebian/$(LIBPKG) -p$(LIBPKG)
$(USRLIB)/$(VERSIONED_LIB) $(USRLIB)
>  
>   dh_link -Pdebian/$(LIBPKG) -p$(LIBPKG)
$(USRLIB)/$(VERSIONED_LIB) $(USRLIB)/$(LIBSONAME)
> - dh_link -Pdebian/$(DEVPKG) -p$(DEVPKG)
debian/$(LIBPKG)/$(USRLIB)/$(LIBSONAME) $(USRLIB)/$(LIBSYM)
> + dh_link -Pdebian/$(DEVPKG) -p$(DEVPKG)
$(USRLIB)/$(LIBSONAME) $(USRLIB)/$(LIBSYM)
>  
>  
>   cp -p $(TMP)/$(MAN1)/* $(DESTMAN1)

Dear Maintainer,

I'm quite interested on having this package available in testing and
buster, so I'll do an NMU to delayed/10 sometimes this week with the
above patch unless I receive an objection.

-- 
Kind regards,
Luca Boccassi

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

Bug#893369: 893369

[Michael Biebl]

Am 21.03.2018 um 13:18 schrieb Felix Defrance:

> Start-Date: 2018-03-20  14:02:40
> Commandline: apt full-upgrade
> Requested-By: fdef (1000)
> Install: libpam0g:i386 (1.1.8-3.7, automatic), libdevmapper1.02.1:i386
> (2:1.02.145-4.1, automatic), libseccomp2:i386 (2.3.1-2.1, automatic),
> gir1.2-mutter-2:amd64 (3.28.0-1, automatic), libargon2-0:i386
> (0~20161029-1.1, automatic), libacl1:i386 (2.2.52-3+b1, automatic),
> libkmod2:i386 (25-1, automatic), libmutter-2-0:amd64 (3.28.0-1,
> automatic), libapparmor1:i386 (2.12-3, automatic), libattr1:i386
> (1:2.4.47-2+b2, automatic), libpam-systemd:i386 (238-2, automatic),
> systemd:i386 (238-2, automatic), libcap-ng0:i386 (0.7.7-3.1+b1,

[..]

> Remove: systemd:amd64 (237-4)

Be careful with full-upgrade, it does potentially bad things like in
this case replacing systemd:amd64 with systemd:i386 and always
double-check what it is going to do. For normal operation, apt upgrade
is safer, especially for sid, where packages can be temporarily not
installable. Still curious, why apt decided to do that in this case.

To fix your breakage, please switch systemd back to your native
architectue by running

apt install systemd:amd64


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



signature.asc
Description: OpenPGP digital signature

Bug#681726: Time to remove eclipse from Testing?

[Hans-Christoph Steiner]

Markus Koschany:
> On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk  wrote:
> [...]
>> I tried to sort out what I could find as required for getting the
>> ancient eclipse out of testing in [1]:
>>
>> 1. src:bnd
>> You fixed that already.
>>
>> 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
>> Is there some good way to break this dependency chain?
>>
>> 3. split libequinox-osgi-java out of src:eclise
>> Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.
> 
> I have spent some time this weekend on Eclipse again. I have created a
> standalone src:libequinox-osgi-java package and successfully rebuilt all
> reverse-dependencies. We only have to make a small adjustment in
> src:netbeans and src:libnb-platform18-java and update the osgi patch.
> 
> If there are no objections I could go ahead and upload
> libequinox-osgi-java to NEW.
> 
> eclipse-rcp:
> 
> * svnkit:
> 
> There are two Eclipse specific classes that fail to build. As a
> workaround we could remove one of them and patch SVNWCUtil.
> 
> * android-sdktools and android-platform-tools-swt
> 
> According to [1] both packages should be removed anyway.
> 
> After that there would be only three packages left (not counting the
> eclipse plugins) that build-depend on either eclipse-platform (aspectj)
> or eclipse-jdt (lombok, biogenesis)
> 
> Next I'm going to try if a separate eclipse-jdt package from [2] could
> be a drop-in-replacement for our current package. The latest stable
> release appears to be S4_8_0_M5.
> 
> Regards,
> 
> Markus
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879175#10
> [2] https://github.com/eclipse/eclipse.jdt.core

As far as I know, android-sdktools and android-platform-tools-swt are
both deprecated by Google.  So it should be fine to remove them also.
There is a chance that other parts of the Android SDK depend on JARs
from Eclipse, but I guess that's not likely/

.hc

Bug#893712: libfm-qt: please use arch-bits=32/arch-bits=64 in symbol files

[YunQiang Su]

Package: src:libfm-qt
Version: 0.12.0-14

dpkg-gensymbols supports a new syntax,
   arch-bits=32
or
   arch-bits=64

in symbol files.

It just fits for libfm-qt, please use this syntax,
it will be helpful for port to new architectures.


-- 
YunQiang Su

Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Hideki Yamane]

Package: debootstrap-udeb
Severity: minor

Hi,

 It contains meaningless scripts as below.


drwxr-xr-x root/root 0 2018-03-17 23:46 ./usr/share/debootstrap/scripts/
-rw-r--r-- root/root  6016 2018-03-17 23:46 
./usr/share/debootstrap/scripts/aequorea
-rw-r--r-- root/root  6296 2018-03-17 23:46 
./usr/share/debootstrap/scripts/etch
-rw-r--r-- root/root  7461 2018-03-17 23:46 
./usr/share/debootstrap/scripts/gutsy
-rw-r--r-- root/root  6233 2018-03-17 23:46 
./usr/share/debootstrap/scripts/sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/artful -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/bartholomea -> aequorea
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/bionic -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/bullseye -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/buster -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/chromodoris -> aequorea
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/dasyatis -> aequorea
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/etch-m68k -> etch
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/hardy -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/intrepid -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/jaunty -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/jessie -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/jessie-kfreebsd -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/karmic -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/lenny -> etch
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/lucid -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/maverick -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/natty -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/oldoldstable -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/oldstable -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/oneiric -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/precise -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/quantal -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/raring -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/saucy -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/squeeze -> etch
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/stretch -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/trusty -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/utopic -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/vivid -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/wheezy -> sid
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/wily -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/xenial -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/yakkety -> gutsy
lrwxrwxrwx root/root 0 2018-03-17 23:46 
./usr/share/debootstrap/scripts/zesty -> gutsy

 Not harm but messy.

Bug#893369: 893369

[Felix Defrance]

Le 21/03/2018 à 15:04, Michael Biebl a écrit :
> Am 21.03.2018 um 14:47 schrieb Michael Biebl:
>> Am 21.03.2018 um 13:18 schrieb Felix Defrance:
>>
>>> Start-Date: 2018-03-20  14:02:40
>>> Commandline: apt full-upgrade
>>> Requested-By: fdef (1000)
>>> Install: libpam0g:i386 (1.1.8-3.7, automatic), libdevmapper1.02.1:i386
>>> (2:1.02.145-4.1, automatic), libseccomp2:i386 (2.3.1-2.1, automatic),
>>> gir1.2-mutter-2:amd64 (3.28.0-1, automatic), libargon2-0:i386
>>> (0~20161029-1.1, automatic), libacl1:i386 (2.2.52-3+b1, automatic),
>>> libkmod2:i386 (25-1, automatic), libmutter-2-0:amd64 (3.28.0-1,
>>> automatic), libapparmor1:i386 (2.12-3, automatic), libattr1:i386
>>> (1:2.4.47-2+b2, automatic), libpam-systemd:i386 (238-2, automatic),
>>> systemd:i386 (238-2, automatic), libcap-ng0:i386 (0.7.7-3.1+b1,
>> [..]
>>
>>> Remove: systemd:amd64 (237-4)
> Felix, are you using sid or buster
buster
>
>

-- 
Félix Defrance
PGP: 0x0F04DC57




signature.asc
Description: OpenPGP digital signature

Bug#893369: 893369

[Michael Biebl]

Am 21.03.2018 um 14:47 schrieb Michael Biebl:
> Am 21.03.2018 um 13:18 schrieb Felix Defrance:
> 
>> Start-Date: 2018-03-20  14:02:40
>> Commandline: apt full-upgrade
>> Requested-By: fdef (1000)
>> Install: libpam0g:i386 (1.1.8-3.7, automatic), libdevmapper1.02.1:i386
>> (2:1.02.145-4.1, automatic), libseccomp2:i386 (2.3.1-2.1, automatic),
>> gir1.2-mutter-2:amd64 (3.28.0-1, automatic), libargon2-0:i386
>> (0~20161029-1.1, automatic), libacl1:i386 (2.2.52-3+b1, automatic),
>> libkmod2:i386 (25-1, automatic), libmutter-2-0:amd64 (3.28.0-1,
>> automatic), libapparmor1:i386 (2.12-3, automatic), libattr1:i386
>> (1:2.4.47-2+b2, automatic), libpam-systemd:i386 (238-2, automatic),
>> systemd:i386 (238-2, automatic), libcap-ng0:i386 (0.7.7-3.1+b1,
> 
> [..]
> 
>> Remove: systemd:amd64 (237-4)

Felix, are you using sid or buster


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



signature.asc
Description: OpenPGP digital signature

Bug#892539: pdftk: Depends on GCJ which is going away

[Petter Reinholdtsen]

I use pdftk regularly, and really hope we can manage to keep it in
Debian.

Is there a plan for adressing this before gcj is removed?
-- 
Happy hacking
Petter Reinholdtsen

Bug#893369: 893369

[Felix Defrance]

Le 21/03/2018 à 14:47, Michael Biebl a écrit :
> Am 21.03.2018 um 13:18 schrieb Felix Defrance:
>
>> Start-Date: 2018-03-20  14:02:40
>> Commandline: apt full-upgrade
>> Requested-By: fdef (1000)
>> Install: libpam0g:i386 (1.1.8-3.7, automatic), libdevmapper1.02.1:i386
>> (2:1.02.145-4.1, automatic), libseccomp2:i386 (2.3.1-2.1, automatic),
>> gir1.2-mutter-2:amd64 (3.28.0-1, automatic), libargon2-0:i386
>> (0~20161029-1.1, automatic), libacl1:i386 (2.2.52-3+b1, automatic),
>> libkmod2:i386 (25-1, automatic), libmutter-2-0:amd64 (3.28.0-1,
>> automatic), libapparmor1:i386 (2.12-3, automatic), libattr1:i386
>> (1:2.4.47-2+b2, automatic), libpam-systemd:i386 (238-2, automatic),
>> systemd:i386 (238-2, automatic), libcap-ng0:i386 (0.7.7-3.1+b1,
> [..]
>
>> Remove: systemd:amd64 (237-4)
> Be careful with full-upgrade, it does potentially bad things like in
> this case replacing systemd:amd64 with systemd:i386 and always
> double-check what it is going to do. For normal operation, apt upgrade
> is safer, especially for sid, where packages can be temporarily not
> installable. Still curious, why apt decided to do that in this case.
Ok I don't unknow that, I'll use upgrade ;)

And I don't unknow why systemd:amd64 was marked as removed..  I'm still
curious too!
>
> To fix your breakage, please switch systemd back to your native
> architectue by running
>
> apt install systemd:amd64


Another things important, I told a misstake! When my system broken this
morning, to solve the problem I have installed systemd:amd64 in version
238-2 by executing :

dpkg -i /var/cache/apt/archives/systemd_238-2_amd64.deb

After that, I got other problem with gnome-shell and I needed to
downgrade lot of packages...

So I'm confuse, I answered to quickly at this bug :/


>
>
> Michael

-- 
Félix Defrance
PGP: 0x0F04DC57




signature.asc
Description: OpenPGP digital signature

Bug#893369: 893369

[Felipe Sateler]

On Wed, Mar 21, 2018 at 9:18 AM, Felix Defrance  wrote:

> Hi,
>
> I confirm this bug. It break the normal booting.
>
> I temporary solved the problem by installing systemd in version 237-4 (the
> installation of 238-2 don't solve the problem)
>

Can you tell us if this works, and post the output?

apt install systemd:amd64=238-2



-- 

Saludos,
Felipe Sateler

Bug#538692: Hoia

[jessica u meir]

Hola, mi nombre es Gen.Jessica U Meir, soldado del estado
norteamericano de Estados Unidos, tengo algo muy importante que
discutir contigo, por favor mándame un correo electrónico
(jessicaumei...@gmail.com) para que sepa si recibes mi correo o tú me
puede enviar su dirección de correo electrónico para que lo contacte
gracias.

Bug#762355: Packaging Raccoon

[Hans-Christoph Steiner]

please go right ahead and do it :-)  let us know if you need help

Bug#877001: should be in contrib since it requires GitHub API

[Hans-Christoph Steiner]

I totally agree that grip is free software, that is why I'm proposing it
go into contrib.  "Contrib" means that it is free software, but requires
non-free software to work.

Bug#893714: python-phply: Please package version 1.2.4

[Stuart Prescott]

Source: python-phply
Version: 1.2.2
Severity: wishlist

Dear Maintainer,

As part of translate-toolkit moving to use python-phply for the l10n of php
source code, various improvements were made to phply by the translate-toolkit
developers. These improvements are needed for the next version of
translate-toolkit so an upload of version 1.2.4 (that incorporates the
changes) would be appreciated.

(It's a trivial update from a packagers perspective, no changes required.)

thanks
Stuart

Bug#877001: should be in contrib since it requires GitHub API

[Hans-Christoph Steiner]

But if y'all want to keep it in 'main', then please, at the very least,
document that 'grip' will upload all data to the proprietary GitHub API.

Bug#893715: Please provide package libnethogs

[Yangfl]

Source: nethogs
Version: 0.8.5-2
Severity: wishlist
Control: block 870447 by -1

The package deepin-system-monitor which I'm working on depends on
libnethogs. Since there's already a Makefile target that makes
libnethogs, please consider adding package libnethogs.

Thanks,

Bug#884095: flag to force file types

[Hans-Christoph Steiner]

Chris Lamb:
> severity 884095 wishlist
> thanks
> 
> Hi hc,
> 
>> Something like --force=apk would solve both.
> 
> So, I'm a little nervous about introducing such a directive.
> 
> This is primarily in terms that diffoscope should really just Do The
> Right Thing by default in all cases and not need magic flags to get a
> the desired result. :)
> 
> This is just a better user experience but also has real practical
> implications; it is not tidy (or even possible) to specify such flags
> in automated or hosted CI environments such as tests.reproducible-builds.org, 
> try.diffoscope.org. Travis CI, etc. on a per-package basis.
> 
> Whilst we might have other flags that you could point to that would
> violate this informal "rule", I would certainly cheer their removal.
> 
> (There are also — entirely secondary — concerns around whether this
> flag would change the behaviour in nested files as well, but we can
> leave that for now..)
> 
> Have we really exhausted the detection route for this? :)
> 
> 
> Regards,
> 

I think the detection route has been exhausted.  It seems that no one
wants to do what it takes to reliably detect APKs.  I understand why
libfile does not want to include more elaborate checks like:

* ZIP file
* with AndroidManifest.xml in it

There are also often cases when working with malware samples that they
are deliberately created to avoid being detected as APKs, for example
the "Janus" vuln https://github.com/odensc/janus.  That works by making
the APK seem like a DEX file.

Bug#874848: Patch attached, will NMU to delayed/10 in some days

[Lisandro Damián Nicanor Pérez Meyer]

I'm attaching a very simple patch to achieve this. The packaging can
be highly improved by updating debhelper compatibility, standards
version, etc, but I preferred to keep it minimal.

If I have no replies in some days I'll upload it to delayed/10.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
diff --git a/debian/changelog b/debian/changelog
index a8e4e35..4005353 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+convertall (0.7.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Switch to Qt 5 (Closes: #874848).
+- Build depend upon qtbase5-dev and python3-qt5.
+- Export QT_SELECT = qt5 in debian/rules.
+  * Refresh 02_remove_module_shebang.patch.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Wed, 21 Mar 2018 11:44:49 -0300
+
 convertall (0.6.1-2) unstable; urgency=medium
 
   * debian/convertall.desktop: Fix icon location
diff --git a/debian/control b/debian/control
index 1d35ceb..ff7267d 100644
--- a/debian/control
+++ b/debian/control
@@ -3,8 +3,11 @@ Section: x11
 Priority: optional
 Maintainer: Python Applications Packaging Team 
 Uploaders: Jackson Doak 
-Build-Depends: debhelper (>= 9), python3, python3-pyqt4 (>= 4.6),
- libqt4-dev (>= 4.6), dpkg (>= 1.15.6~)
+Build-Depends: debhelper (>= 9),
+   dpkg (>= 1.15.6~),
+   qtbase5-dev (>= 4.6),
+   python3,
+   python3-pyqt5 (>= 4.6)
 Standards-Version: 3.9.7
 Homepage: http://convertall.bellz.org/
 Vcs-Svn: svn://anonscm.debian.org/python-apps/packages/convertall/trunk/
@@ -12,9 +15,9 @@ Vcs-Browser: https://anonscm.debian.org/viewvc/python-apps/packages/convertall/t
 
 Package: convertall
 Architecture: all
-Depends: ${python3:Depends}, ${misc:Depends}, python3-pyqt4
+Depends: python3-pyqt5, ${misc:Depends}, ${python3:Depends}
 Description: very flexible unit converter
  With ConvertAll, you can convert any unit in the large database to any other
  compatible unit. If you want to convert from inches per decade, that's fine.
  Or from meter-pounds. Or from cubic nautical miles. The units don't have to
- make sense to anyone else. 
+ make sense to anyone else.
diff --git a/debian/convertall.manpages b/debian/convertall.manpages
index 8f138a0..893d96e 100644
--- a/debian/convertall.manpages
+++ b/debian/convertall.manpages
@@ -1 +1 @@
-debian/convertall.1
\ No newline at end of file
+debian/convertall.1
diff --git a/debian/copyright b/debian/copyright
index afd22e4..2375fb2 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -45,4 +45,3 @@ License: GPL-3+
  .
  On Debian systems, you can find the complete text of the GNU General
  Public License version 3 in `/usr/share/common-licenses/GPL-3'.
-
diff --git a/debian/dirs b/debian/dirs
index 8a53a92..294259b 100644
--- a/debian/dirs
+++ b/debian/dirs
@@ -1,2 +1,2 @@
-usr/share/pixmaps
 usr/share/applications
+usr/share/pixmaps
diff --git a/debian/patches/02_remove_module_shebang.patch b/debian/patches/02_remove_module_shebang.patch
index 6e5ced7..3d06790 100644
--- a/debian/patches/02_remove_module_shebang.patch
+++ b/debian/patches/02_remove_module_shebang.patch
@@ -3,22 +3,31 @@
 
 ---
  source/cmdline.py|2 --
- source/convertdlg.py |2 --
- source/finddlg.py|2 --
- source/helpview.py   |2 --
- source/icondict.py   |2 --
- source/modbutton.py  |2 --
- source/numedit.py|2 --
+ source/convertall.py |1 -
+ source/convertdlg.py |1 -
+ source/helpview.py   |1 -
+ source/icondict.py   |1 -
+ source/numedit.py|1 -
  source/option.py |2 --
- source/optiondefaults.py |2 --
- source/optiondlg.py  |2 --
- source/unitatom.py   |2 --
- source/unitdata.py   |2 --
- source/unitedit.py   |2 --
+ source/optiondefaults.py |1 -
+ source/optiondlg.py  |1 -
+ source/recentunits.py|1 -
+ source/setup.py  |1 -
+ source/unitatom.py   |1 -
+ source/unitdata.py   |1 -
+ source/unitedit.py   |1 -
  source/unitgroup.py  |2 --
- source/unitlistview.py   |2 --
- 15 files changed, 30 deletions(-)
+ source/unitlistview.py   |1 -
+ 16 files changed, 19 deletions(-)
 
+--- a/source/unitgroup.py
 b/source/unitgroup.py
+@@ -1,5 +1,3 @@
+-#!/usr/bin/env python3
+-
+ #
+ # unitgroup.py, provides a group of units and does conversions
+ #
 --- a/source/cmdline.py
 +++ b/source/cmdline.py
 @@ -1,5 +1,3 @@
@@ -27,54 +36,41 @@
  #
  # cmdline.py, provides a class to read and execute command line arguments
  #
+--- a/source/convertall.py
 b/source/convertall.py
+@@ -1,4 +1,3 @@
+-#!/usr/bin/env python3
+ """
+ *

Bug#893716: RFS: deepin-screen-recorder/2.7.3-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "deepin-screen-recorder"

 * Package name: deepin-screen-recorder
   Version : 2.7.3-1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://www.deepin.org/
 * License : GPLv3
   Section : utils

It builds those binary packages:

  deepin-screen-recorder - Simple recorder tools for deepin

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

https://mentors.debian.net/package/deepin-screen-recorder


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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-screen-recorder/deepin-screen-recorder_2.7.3-1.dsc


Regards,
 Yangfl

Bug#887304: linux-image-4.14.0-0.bpo.2-amd64: Error crypto/algapi.c:348 and a long system boot.

[LeJacq, Jean Pierre]

I've tested the following two kernels from sid on a stretch system and they 
both DO NOT exhibit this bug:

linux-image-4.15.0-1-amd64
linux-image-4.15.0-2-amd64

Instead of the kernel null pointer exception, I see the following in the boot 
log:

kernel: usb 1-7: New USB device found, idVendor=8087, idProduct=0a2b
kernel: usb 1-7: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
kernel: alg: ecdh: test failed on vector 3, err=-14
kernel: Bluetooth: Core ver 2.22

My bluetooth devices now work while they didn't with the 4.14.0 kernels.

-- 
JP

Bug#864184: Raising severity

[Barak A. Pearlmutter]

Just uploaded fix.

> I'm happy to upload an NMU if you're busy.

In the future please feel free to just NMU, 0 day, I don't mind.

For historic reasons the packaging repo is on github; I should really
move it to salsa Debian, and just mirror on github, to make this sort
of thing easier.

--Barak.

Bug#893369: systemd-udevd is killed at startup

[Michael Biebl]

Am 19.03.2018 um 16:36 schrieb LEDUQUE Mickaël:
> Start-Date: 2018-03-15  09:28:21
> Commandline: apt dist-upgrade

[..]

> Remove: bundler:amd64 (1.15.1-1), systemd:amd64 (237-4),
> ruby-bundler:amd64 (1.15.1-1)
> End-Date: 2018-03-15  09:28:29
> 
> Also it seems at some point I had systemd:amd64 237-4 and many other
> packages as 238-2.
> Strangely I find no mention of removing system:amd64 even though

See above: Remove: ...  systemd:amd64 (237-4)

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



signature.asc
Description: OpenPGP digital signature

Bug#893717: gnome-shell: Poor performance with wayland after upgrading to 3.28

[Sam Morris]

Package: gnome-shell
Version: 3.28.0-1
Severity: normal

Since upgrading to 3.28, performance of gnome-shell as a wayland
compositor is very bad. It seems that drawing to the screen causes a
brief stutter that is easy to observe by moving the mouse cursor over
regions that react to being hovered over.

Compare how smoothly the mouse cursor moves in the following two videos:

https://youtu.be/KJbrkJsqcSk
https://youtu.be/O-rR6u9ukN8

The first video is using wayland, the second Xorg. This is on a Lenovo
P50 with (regretably) an NVIDIA card:

01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro 
M2000M] (rev a2)

I've tried to reproduce this with Xwayland running under weston, and
performance seems fine, so I'm suspecting gnome-shell/mutter or a
dependency at this stage.

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  evolution-data-server3.26.5-2
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.28.0-1
ii  gir1.2-freedesktop   1.54.1-4
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.0-1
ii  gir1.2-gdm-1.0   3.28.0-1
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-glib-2.0  1.54.1-4
ii  gir1.2-gnomebluetooth-1.03.28.0-2
ii  gir1.2-gnomedesktop-3.0  3.27.92-1
ii  gir1.2-gtk-3.0   3.22.29-1
ii  gir1.2-gweather-3.0  3.28.0-2
ii  gir1.2-ibus-1.0  1.5.17-3
ii  gir1.2-mutter-2  3.28.0-1
ii  gir1.2-nm-1.01.10.6-2
ii  gir1.2-nma-1.0   1.8.10-2
ii  gir1.2-pango-1.0 1.40.14-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-rsvg-2.0  2.40.20-2
ii  gir1.2-soup-2.4  2.62.0-1
ii  gir1.2-upowerglib-1.00.99.7-2
ii  gjs  1.50.3-2
ii  gnome-backgrounds3.28.0-1
ii  gnome-settings-daemon3.26.2-1+b1
ii  gnome-shell-common   3.28.0-1
ii  gsettings-desktop-schemas3.28.0-1
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.26.5-2
ii  libedataserver-1.2-223.26.5-2
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libgirepository-1.0-11.54.1-4
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.52.0-2
ii  libglib2.0-0 2.54.3-2
ii  libglib2.0-bin   2.54.3-2
ii  libgstreamer1.0-01.12.4-1
ii  libgtk-3-0   3.22.29-1
ii  libical3 3.0.1-5
ii  libjson-glib-1.0-0   1.4.2-3
ii  libmutter-2-03.28.0-1
ii  libnm0   1.10.6-2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  11.1-4
ii  libpulse011.1-4
ii  libsecret-1-00.18.5-6
ii  libstartup-notification0 0.12-5
ii  libsystemd0  238-3
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.28.0-1
ii  python3  3.6.4-1

Versions of packages gnome-shell recommends:
ii  chrome-gnome-shell