Bug#882309: should wrap lines in message body

[Ola Lundqvist]

Thank you. Applied, will upload soon.

On 29 November 2017 at 12:09, Marc Haber
 wrote:
> Package: cron-apt
> Version: 0.11.0
> Followup-For: Bug #882309
>
> Here we are.
>
> Greetings
> Marc



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#876103: systemd-nspawn: --read-only is broken

[Lauri Tirkkonen]

Hi,

On Sun, Dec 03 2017 13:47:29 +0100, Michael Biebl wrote:
> > There is an upstream fix for this in
> > https://github.com/systemd/systemd/pull/4693 --
> > acbbf69b718260755a5dff60dd68ba239ac0d61b is the commit that actually
> > fixes read-only containers, but it requires two other commits to apply
> > cleanly. I applied the following sequence to systemd-container on
> > stretch:
> > 
> > https://github.com/systemd/systemd/commit/bdb4e0cb646ff33ecbb1cf4b502870f84bf4016d
> > https://github.com/systemd/systemd/commit/4f086aab52812472a24c9b8b627589880a38696e
> > https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b
> > 
> > and it solved my problem. Could you backport these patches to stretch?
> > 
> 
> Those patches looks a bit invasive for a stretch stable upload.
> But we do provide updated systemd versions with this fix via
> stretch-backports:
> https://packages.debian.org/source/stable-backports/systemd
> 
> Would that be sufficient for your case?

It turned out that we needed a couple other patches for
systemd-container, including one yet to be released, so for our case
it's sufficient to do nothing since we now use our own systemd-container
package :)

However, I don't think the patches I listed are that invasive -- note
that they only affect the systemd-nspawn binary. Anyone else having a
problem with --read-only can move to the backports package, yes, but we
explicitly did not want to upgrade all of systemd just to get a few
patches to nspawn.

Bug#883447: ITP: node-css-tree -- toolset to work with CSS

[Pirate Praveen]

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

* Package name: node-css-tree
  Version : 1.0.0-alpha.26
  Upstream Author : Roman Dvornov 
(https://github.com/lahmatiy)
* URL : https://github.com/csstree/csstree
* License : Expat
  Programming Lang: JavaScript
  Description : toolset to work with CSS

 CSSTree is a tool set to work with CSS, including fast detailed parser
 (string->AST), walker (AST traversal), generator (AST->string) and lexer
 (validation and matching) based on knowledge of spec and browser
 implementations.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain of gitlab 9.5 (dependency of css-loader).



signature.asc
Description: OpenPGP digital signature

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Christian Ehrhardt]

On Fri, Dec 1, 2017 at 7:14 PM, Gerald Turner  wrote:
> Hi Christian,
>
> I don't want to distract from the purpose of this bug report, but I have
> a question regarding one particular piece...

Hi Gerald,
thank you so much - perfect question and not distracting from the
purpose of the bug at all.
I was in this case carrying forward an old change which was (in
Ubuntu) separate from some other changes.
In one of our last runs to synchronize between Ubuntu and Debian this
particular Delta was already taken as 9e71a108
 "add and install apparmor profiles" into v5.5.1-3

So I obviously have to drop it from this series  ... updated the branch.
Thanks a lot to trigger me spotting this issue.

> On Thu, Nov 30 2017, Christian Ehrhardt wrote:
>> The TL;DR of the remaining changes are:
>> - some fixes (like the stroke apparmor profile)
>
> Do the Ubuntu packages install AppArmor profiles for charon-systemd and
> swanctl as well?
>

As you already outlined below the usr.sbin.charon-systemd profile was
added in 5.6.0-1 and we don't have it (yet).
I'm working on a recent merge, once done we will have the same profile
as in debian (it works fine for me in tests so far).

For usr.sbin.swanctl we already had the same file as in latest Debian.

> FYI, earlier this year I copied the existing usr.lib.ipsec.charon
> profile to usr.sbin.charon-systemd, and created a usr.sbin.swanctl from
> scratch (although it's similar to usr.lib.ipsec.stroke).  Filed bug
> #866327.  Yves-Alexis applied changes in 5.6.0-1.
>
> I suppose that if there are usr.lib.ipsec.charon or usr.lib.ipsec.stroke
> specific changes coming from Ubuntu, that these should be synchronized
> with the usr.sbin.charon-systemd or usr.sbin.swanctl variants in Debian.

I checked and so far we have no difference left to the profiles uses in Debian.
So we should all be good in the sense that no one knows better yet how
to improve the profiles.

Looking towards hopefully enabling apparmor in Buster [1] by default
strongswan should be in good shape.

[1]: https://lists.debian.org/debian-devel/2017/08/msg00090.html

Bug#883446: restic: Add zsh completions

[Bart Libert]

Package: restic
Version: 0.8.0-1
Severity: wishlist

Dear Maintainer,

Starting with restic 0.8, the program can generate zsh completions (restic 
generate --zsh-completion), next to bash completions.
It would be nice if these were installed by the package as well.

Thanks for considering this!


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

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

Versions of packages restic depends on:
ii  libc6  2.25-2

restic recommends no packages.

Versions of packages restic suggests:
ii  libjs-jquery  3.2.1-1
ii  libjs-underscore  1.8.3~dfsg-1

-- no debconf information

Bug#883444: debuerreotype: debootstrap needed as a test dependency

[Steve Langasek]

Package: debuerreotype
Version: 0.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Hi Tianon,

Since the upload of 0.4-1 to unstable, the debuerrotype autopkgtest has been
failing in the CI environment:

autopkgtest [22:14:21]: test stretch: [---
+ debuerreotype-init /tmp/tmp.YatKejiXqF stretch 2017-01-01T00:00:00Z
/usr/sbin/debuerreotype-init: line 83: debootstrap: command not found
+ rm -rf /tmp/tmp.YatKejiXqF
autopkgtest [22:14:21]: test stretch: ---]
autopkgtest [22:14:22]: test stretch:  - - - - - - - - - - results - - - - - - 
- - - -
stretch  FAIL non-zero exit status 127

(https://ci.debian.net/packages/d/debuerreotype/unstable/amd64/)

debootstrap is only a Recommends: of debuerrotype, but clearly is required
by the tests; so it should be explicitly listed in debian/tests/control.

This bug was detected in Ubuntu, which gates release on failing
autopkgtests.  Unfortunately Debian does not gate on autopkgtest
regressions, so debuerreotype 0.4-1 is in testing, leaving you without a
clean test baseline currently.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru debuerreotype-0.4/debian/tests/control 
debuerreotype-0.4/debian/tests/control
--- debuerreotype-0.4/debian/tests/control  2017-05-22 23:14:59.0 
-0700
+++ debuerreotype-0.4/debian/tests/control  2017-12-03 22:31:19.0 
-0800
@@ -1,3 +1,3 @@
 Tests: stretch
-Depends: debuerreotype
+Depends: debuerreotype, debootstrap
 Restrictions: allow-stderr, needs-root

Bug#883445: RM: ros-geometry-experimental -- ROM; source package renamed to ros-geometry2

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal

Hi,

upstream renamed the package to geometry2 and this is now the reflected
in the Debian package ros-geometry2, providing the same binary package.
Please remove ros-geometry-experimental from unstable.

Thanks

Jochen

Bug#882755: Debian mirror debian.mirror.iweb.ca: ftpsync version

[Bastian Blank]

Hi

On Thu, Nov 30, 2017 at 11:18:01PM +, Benjamin Navaro wrote:
> Please note that debian.mirror.iweb.ca has now been updated with the latest 
> ftpsync script.

It seems it did not finish any sync since then.  Please make sure you
receive error mails.

Bastian

-- 
Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0

Bug#819371: Please depend on "firefox | firefox-esr" rather than the reverse

[Jeremy Bicha]

I apologize for not commenting more recently, but chromium-browser has
been an alternative dependency in gnome-core since relatively soon
after Antonio's comment.

I think Epiphany is not because the Debian Security team does not
offer security support for webkit2gtk in Debian stable releases.
There's a chance that could change for Debian 10 "Buster" and
webkit2gtk is well-maintained in Debian Testing, so maybe it's worth
reconsidering.

As for the original bug here, I think the ordering of firefox-esr over
firefox reflects the intent of the Debian Firefox maintainer. The
firefox package is completely unsupported in Debian Testing (it won't
receive any updates). I don't want someone to accidentally figure that
out when they try to do an unsupported downgrade from Unstable to
Testing.

Thanks,
Jeremy Bicha

Bug#876299: ulimit change didn't work

[Matthew Vernon]

On 03/12/17 22:27, Matthew Vernon wrote:

2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't 
seem to have worked on on s390, despite the build being known to work if 
called entirely with ulimit -s unlimited. I think I'd like some help 
from the s390 people here - how am I driving the buildd wrong?


The latter is, I think, that make is calling ulimit in a subprocess, so 
it doesn't affect the calling process (and so doesn't affect the stack 
limit for the test run). Hmph.


Matthew

Bug#883409: webpack: depends on non-existing package node-uglifyjs-webpack-plugin

[Pirate Praveen]

On Sun, 03 Dec 2017 17:44:20 +0100 Jonas Smedegaard  wrote:
> The binary package webpack depends on non-existing package
> node-uglifyjs-webpack-plugin, making the former impossible to install.

Both webpack and node-uglifyjs-webpack-plugin was in NEW, but webpack
was accepted before node-uglifyjs-webpack-plugin, making webpack
uninstallable. Once node-uglifyjs-webpack-plugin clears NEW, this bug
can be closed.



signature.asc
Description: OpenPGP digital signature

Bug#883443: rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or directory

[積丹尼 Dan Jacobson]

Package: libreoffice-common
Version: 1:5.4.3-3

# aptitude purge ~i~nlibreoffice
Removing libreoffice-common (1:5.4.3-3) ...
rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or 
directory
rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or directory
rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
directory
rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
rmdir: failed to remove '/var/lib/libreoffice': No such file or directory

Bug#883442: debconf: Switch GNOME frontend to GTK3

[Jeremy Bicha]

Source: debconf
Version: 1.5.65

debconf's GNOME backend is one of the last things in a default Debian
GNOME (or Ubuntu 18.04) install that still needs gtk2. Here's a
wishlist tracker bug requesting that debconf's GNOME backend be
switched to gtk3.

Thanks,
Jeremy Bicha

Bug#882512: marked as done (kwin-x11: stops drawing window content after some time)

[tony mancill]

On Mon, Dec 04, 2017 at 12:25:39AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Maybe you made a typo when closing the bug? I don't think Java has anything
> to do with kwin ;-)

Oops!  Thank you for pointing that out.  I'll reopen it.

> El 3 dic. 2017 10:21 p.m., "Debian Bug Tracking System" <
> ow...@bugs.debian.org> escribió:
> 
> > Your message dated Mon, 04 Dec 2017 01:19:01 +
> > with message-id 
> > and subject line Bug#882512: fixed in commons-jci 1.1-5
> > has caused the Debian Bug report #882512,
> > regarding kwin-x11: stops drawing window content after some time
> > to be marked as done.
> >
> > This means that you claim that the problem has been dealt with.
> > If this is not the case it is now your responsibility to reopen the
> > Bug report if necessary, and/or fix the problem forthwith.
> >
> > (NB: If you are a system administrator and have no idea what this
> > message is talking about, this may indicate a serious mail system
> > misconfiguration somewhere. Please contact ow...@bugs.debian.org
> > immediately.)
> >
> >
> > --
> > 882512: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882512
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> >
> >
> > -- Forwarded message --
> > From: Andreas Beckmann 
> > To: Debian Bug Tracking System 
> > Cc:
> > Bcc:
> > Date: Thu, 23 Nov 2017 16:31:20 +0100
> > Subject: kwin-x11: stops drawing window content after some time
> > Package: kwin-x11
> > Version: 4:5.8.6-1
> > Severity: important
> > Forwarded: https://bugs.kde.org/show_bug.cgi?id=343661
> >
> > Hi,
> >
> > after some time my kde session stops redrawing some windows. I see this
> > mostly in konsole and firefox (which are the majority of my long-running
> > open windows). Clicking and typing is still working, but updates causes
> > by this are only seen after forcing a redraw by e.g.
> > minimizing+unminimizing, switching to another tab and back in konsole,
> > ...
> > Sometimes a firefox window also becomes completely black (but title and
> > border are still OK), which can be fixed by minimizing and unminimizing.
> >
> > This time it took 4 days since the last reboot and X session start for
> > the problem to show up for the first time.
> >
> > The workaround from the corresponding upstream bug is
> >
> > KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &
> >
> > This is working, but not a permanent fix, it may need to be repeated
> > after some days since the problem reappears from time to time (within
> > the same X session).
> >
> > I haven't played with any compositing options since I upgraded to
> > stretch, not sure if I changed something in wheezy or jessie.
> >
> >
> > Andreas
> >
> > -- System Information:
> > Debian Release: 9.2
> >   APT prefers stable-updates
> >   APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'),
> > (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
> > 'stable-debug'), (500, 'oldstable-updates'), (500,
> > 'oldstable-proposed-updates'), (500, 'oldoldstable-updates'), (500,
> > 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500,
> > 'oldstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
> > (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: sysvinit (via /sbin/init)
> >
> >
> > -- Forwarded message --
> > From: tony mancill 
> > To: 882512-cl...@bugs.debian.org
> > Cc:
> > Bcc:
> > Date: Mon, 04 Dec 2017 01:19:01 +
> > Subject: Bug#882512: fixed in commons-jci 1.1-5
> > Source: commons-jci
> > Source-Version: 1.1-5
> >
> > We believe that the bug you reported is fixed in the latest version of
> > commons-jci, which is due to be installed in the Debian FTP archive.
> >
> > A summary of the changes between this version and the previous one is
> > attached.
> >
> > Thank you for reporting the bug, which will now be closed.  If you
> > have further comments please address them to 882...@bugs.debian.org,
> > and the maintainer will reopen the bug report if appropriate.
> >
> > Debian distribution maintenance software
> > pp.
> > tony mancill  (supplier of updated commons-jci
> > package)
> >
> > (This message was generated automatically at their request; if you
> > believe that there is a problem with it please contact the archive
> > administrators by mailing ftpmas...@ftp-master.debian.org)
> >
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Format: 1.8
> > Date: Sun, 03 Dec 2017 16:57:29 -0800
> > Source: commons-jci
> > Binary: libcommons-jci-java libcommons-jci-rhino-java
> > libcommons-jci-groovy-java libcommons-jci-janino-java
> > libcommons-jci-eclipse-java libcommons-jci-java-doc
> > Architecture: source all
> > Version: 1.1-5

Bug#883441: gnome: Don't install gimp and inkscape by default

[Jeremy Bicha]

Package: gnome
Version:

In my opinion, gimp and inkscape are specialized graphical design apps
that don't need to be installed by default. I feel that gimp's
interface in particular is difficult to use for casual computer users.
(I'm not criticizing the app's design; I only mean to say that is a
complex powerful app that takes some effort to use effectively.) I
think gimp and inkscape are so well-known that anyone that thinks they
need them can easily install them from the GNOME Software app.

Additionally, gimp and inkscape are the only 2 gtk2 apps in the
default Debian GNOME install. (Firefox is mostly gtk3 but uses gtk2
for Flash support and a couple minor things. Also, there are some
libraries and library-like things installed by default that still
require gtk2.)

Even if they are ported to gtk3, I still think it is better that they
not be installed by default. We don't need to install every useful app
by default.

Ubuntu included gimp by default until 10.04 LTS and never included
inkscape by default (except in a relatively unknown "DVD" variation of
Ubuntu).

Thanks,
Jeremy Bicha

Bug#882512: marked as done (kwin-x11: stops drawing window content after some time)

[Lisandro Damián Nicanor Pérez Meyer]

Maybe you made a typo when closing the bug? I don't think Java has anything
to do with kwin ;-)

El 3 dic. 2017 10:21 p.m., "Debian Bug Tracking System" <
ow...@bugs.debian.org> escribió:

> Your message dated Mon, 04 Dec 2017 01:19:01 +
> with message-id 
> and subject line Bug#882512: fixed in commons-jci 1.1-5
> has caused the Debian Bug report #882512,
> regarding kwin-x11: stops drawing window content after some time
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 882512: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882512
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Andreas Beckmann 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Thu, 23 Nov 2017 16:31:20 +0100
> Subject: kwin-x11: stops drawing window content after some time
> Package: kwin-x11
> Version: 4:5.8.6-1
> Severity: important
> Forwarded: https://bugs.kde.org/show_bug.cgi?id=343661
>
> Hi,
>
> after some time my kde session stops redrawing some windows. I see this
> mostly in konsole and firefox (which are the majority of my long-running
> open windows). Clicking and typing is still working, but updates causes
> by this are only seen after forcing a redraw by e.g.
> minimizing+unminimizing, switching to another tab and back in konsole,
> ...
> Sometimes a firefox window also becomes completely black (but title and
> border are still OK), which can be fixed by minimizing and unminimizing.
>
> This time it took 4 days since the last reboot and X session start for
> the problem to show up for the first time.
>
> The workaround from the corresponding upstream bug is
>
> KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &
>
> This is working, but not a permanent fix, it may need to be repeated
> after some days since the problem reappears from time to time (within
> the same X session).
>
> I haven't played with any compositing options since I upgraded to
> stretch, not sure if I changed something in wheezy or jessie.
>
>
> Andreas
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers stable-updates
>   APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'),
> (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
> 'stable-debug'), (500, 'oldstable-updates'), (500,
> 'oldstable-proposed-updates'), (500, 'oldoldstable-updates'), (500,
> 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500,
> 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
>
> -- Forwarded message --
> From: tony mancill 
> To: 882512-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 04 Dec 2017 01:19:01 +
> Subject: Bug#882512: fixed in commons-jci 1.1-5
> Source: commons-jci
> Source-Version: 1.1-5
>
> We believe that the bug you reported is fixed in the latest version of
> commons-jci, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 882...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> tony mancill  (supplier of updated commons-jci
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sun, 03 Dec 2017 16:57:29 -0800
> Source: commons-jci
> Binary: libcommons-jci-java libcommons-jci-rhino-java
> libcommons-jci-groovy-java libcommons-jci-janino-java
> libcommons-jci-eclipse-java libcommons-jci-java-doc
> Architecture: source all
> Version: 1.1-5
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Java Maintainers  alioth.debian.org>
> Changed-By: tony mancill 
> Description:
>  libcommons-jci-eclipse-java - common Java interface for various compilers
> - Eclipse JDT
>  libcommons-jci-groovy-java - common Java interface for various compilers
> - Groovy
>  

Bug#883367: RFS: roadfighter/1.0.0-1 [ITP] -- Drive a car in a death race

[Adam Borowski]

[Somehow this bug didn't reach the debian-mentors mailing list]

> * Package name: roadfighter
>   Version : 1.0.0-1
>   Upstream Author : Carlos Donizete Froes 
> * URL : https://github.com/coringao/roadfighter

>  It builds those binary packages:
>
>  roadfighter - Drive a car in a death race
>  roadfighter-data - Drive a car in a death race (Data)

Alas, the game segfaults on start, unless ran from a directory containing
the source tree.  This looks like the same problem as in April 2016.

There's also the unfixed problem of some assets: the .ogg files bear
metadata saying they come from Konami.

Also, fullscreening doesn't work on multi-monitor setups.  It doesn't obey
settings such as which monitor is primary, orientation or positions (most
programs that fail here at least go to (0,0)).  This puts the game on the
wrong monitor, rotated.  Even worse, it permanently destroys randr settings
-- desktop environments (at least XFCE) save modifications, thus setting
everything from scratch is required.

Some displays don't allow non-native resolutions at all.

As far as I know, fixing this is possible but quite tricky in SDL1.2, a
non-issue in SDL2 which doesn't ever try to change resolutions (impossible
on non-CRTs anyway) but tells the GPU to scale.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820...;
⠈⠳⣄ (same for all links)

Bug#883440: gnome: Don't require gtk2

[Jeremy Bicha]

Package: gnome
Version: 1:3.22+6
Tags: buster

I think it would be a nice goal if Debian GNOME didn't install gtk2 by
default for the Buster release. Therefore, I'm opening this tracker
bug so we can easily see how close we are to achieving that goal.

The GTK developers declared gtk3 as stable with its 3.22 release in
September 2016.

The corresponding Ubuntu tracker bug is https://launchpad.net/bugs/1585903

Thanks,
Jeremy Bicha

Bug#883439: dh_elpa_test chokes on 'Invalid field given (X_Python3_Version)' for mixed --with elpa,python packages

[Nicholas D Steeves]

Package: dh-elpa
Version: 1.11~bpo9+1
Severity: normal

This might actually be a libdebian-source-perl bug.  Please reassign
this bug to that package if this is the case.

To reproduce:

git clone ssh://git.debian.org/git/pkg-emacsen/pkg/elpy.git
cd elpy && git checkout reproduce-elpa-bug
build the package

...
writing manifest file 'elpy.egg-info/SOURCES.txt'
   debian/rules override_dh_elpa_test
make[1]: Entering directory '/build/elpy-1.17.0'
dh_elpa_test
Invalid field given (X_Python3_Version) at /usr/share/perl5/Debian/Control.pm 
line 122.
debian/rules:16: recipe for target 'override_dh_elpa_test' failed
make[1]: *** [override_dh_elpa_test] Error 255
make[1]: Leaving directory '/build/elpy-1.17.0'
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
...

If dh_elpa_test is overridden to not run dh_elpa_test, then the error
does not occur.

Resolution: I think libdebian-source-perl needs to be taught about the
X-Python3-Version/X_Python3_Version field, and that this will allow
dh_elpa_test to execute for packages that use --with elpa,python3.
For completeness, supporting X-Python-Version (eg: python2) might also
be nice.

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

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

Versions of packages dh-elpa depends on:
ii  debhelper   10.2.5
ii  dh-make-perl0.94
ii  emacs25 25.1+1-4+deb9u1
ii  libarray-utils-perl 0.5-1
ii  libconfig-tiny-perl 2.23-1
ii  libdebian-source-perl   0.94
ii  libdpkg-perl1.18.24
ii  libfile-find-rule-perl  0.34-1
ii  libtext-glob-perl   0.10-1
ii  perl5.24.1-3+deb9u2

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information


Regards,
Nicholas

Bug#883438: ert-helper.el does not execute configured alternative for (ert-run-tests-batch-and-exit)

[Nicholas D Steeves]

Package: dh-elpa
Version: 1.11~bpo9+1
Severity: important

Hi Sean,

This bug specifically addresses the persistence of '--eval
\(ert-run-tests-batch-and-exit\)'.  It is currently blocking my
attempts to run ert tests through ert-runner rather than directly with
ert-run-tests-batch-and-exit.  It affects elpy, ert-runner (and
several of its dependencies), and self-tests for other packages from
http://github.com/rejeep.

I upgraded the severity of this bug, because I believe we're in
agreement about how debian/ert-runner.el is supposed to allow
overriding of --eval \(ert-run-tests-batch-and-exit\).  Feel free to
downgrade the severity as appropriate.  I think the existence
ert-helper.el is supposed to override the entire dh_elpa_test: emacs
-batch -Q -l...--eval \(run-self-test-function\) command, but I could
be wrong.

Steps to reproduce:

1. Pick a package that has ert tests.
2. echo '(exit)' > debian/ert-helper.el
   * or try another function like (pwd)
   * or try a specific function defined in tests/*.el
3. build the package
4. Observer how '--eval \(ert-run-tests-batch-and-exit\)' is always executed

Expected behaviour:

(exit) executes rather than (ert-run-tests-batch-and-exit)

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

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

Versions of packages dh-elpa depends on:
ii  debhelper   10.2.5
ii  dh-make-perl0.94
ii  emacs25 25.1+1-4+deb9u1
ii  libarray-utils-perl 0.5-1
ii  libconfig-tiny-perl 2.23-1
ii  libdebian-source-perl   0.94
ii  libdpkg-perl1.18.24
ii  libfile-find-rule-perl  0.34-1
ii  libtext-glob-perl   0.10-1
ii  perl5.24.1-3+deb9u2

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information

Regards,
Nicholas

Bug#883375: qtbase-opensource-src: Please add private headers in /src/plugins/platforms/xcb/

[张继德]

qt5dxcb-plugin is a functionality extension based of qt xcb plugin, and is not 
a complete independent plugin, which depends on libqt5xcbqpa5 to work.





--


武汉深之度科技有限公司
Wuhan Deepin Technology Co., Ltd.

　　张继德　　

手机：+8613014623572

武汉：武汉市光谷大道77号光谷金融港B18栋6楼 
北京：北京西城区新街口外大街28号院普天德胜B座603室
上海：上海市长宁区愚园路1258号15A01室

Bug#883437: rsnapshot dependencies seem wrong

[Richard James Salts]

Package: rsnapshot
Version: 1.4.2-1
Severity: normal

Dear Maintainer,

The dependencies of rsnapshot seem to be out of alignment with the
default configuration. rsnapshot's default is to use /usr/bin/logger to
log to syslog, however there is no dependency on bsdutils. A file in 
/etc/logrotate.d/rsnapshot to rotate a log file which will not be created. 
I believe this is the reason for the dependency on logrotate.

I think that the dependency on logrotate should be downgraded to
recommends and that there should be a new dependency on bsdutils.
Obviously this will depend on the config file in /etc/rsnapshot.conf
logging to syslog or not.

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

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

Versions of packages rsnapshot depends on:
ii  liblchown-perl  1.01-3+b2
ii  logrotate   3.11.0-0.1
ii  perl5.24.1-3+deb9u2
ii  rsync   3.1.2-1

Versions of packages rsnapshot recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10+deb9u1

rsnapshot suggests no packages.

-- no debconf information

Bug#883360: python-astroid: missing dependency on python-backports.functools-lru-cache

[Sandro Tosi]

adding piotr

hey Piotr,
is it possible dh-python needs to be extended to support requires.txt
in a format like

```
$ cat astroid.egg-info/requires.txt
lazy_object_proxy
six
wrapt

[:python_version<"3.3"]
backports.functools_lru_cache

[:python_version<"3.4"]
enum34>=1.1.3
singledispatch
```

looking at pydist.py:parse_pydep it doesnt seem dh-python is able to
understand that syntax

On Sat, Dec 2, 2017 at 5:40 PM, Adrian Bunk  wrote:
> Package: python-astroid
> Version: 1.5.3-1
> Severity: serious
> Control: affects -1 src:python-requirements-detector src:pylint-celery
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pylint-celery.html
>
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/1st/pylint-celery-0.3'
> PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="PYTHONDONTWRITEBYTECODE=1 
> PYTHONPATH=. {interpreter} test/test_func.py" dh_auto_test
> I: pybuild base:184: PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=. python2.7 
> test/test_func.py
> Traceback (most recent call last):
>   File "test/test_func.py", line 5, in 
> from pylint.testutils import make_tests, LintTestUsingModule, 
> LintTestUsingFile, cb_test_gen, linter
>   File "/usr/lib/python2.7/dist-packages/pylint/testutils.py", line 37, in 
> 
> import astroid
>   File "/usr/lib/python2.7/dist-packages/astroid/__init__.py", line 57, in 
> 
> from astroid.nodes import *
>   File "/usr/lib/python2.7/dist-packages/astroid/nodes.py", line 30, in 
> 
> from astroid.node_classes import (
>   File "/usr/lib/python2.7/dist-packages/astroid/node_classes.py", line 24, 
> in 
> from astroid import bases
>   File "/usr/lib/python2.7/dist-packages/astroid/bases.py", line 25, in 
> 
> MANAGER = manager.AstroidManager()
>   File "/usr/lib/python2.7/dist-packages/astroid/util.py", line 24, in 
> 
> lambda: importlib.import_module('.' + module_name, 'astroid'))
>   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
>   File "/usr/lib/python2.7/dist-packages/astroid/manager.py", line 21, in 
> 
> from astroid.interpreter._import import spec
>   File 
> "/usr/lib/python2.7/dist-packages/astroid/interpreter/_import/spec.py", line 
> 19, in 
> from backports.functools_lru_cache import lru_cache
> ImportError: No module named backports.functools_lru_cache
> E: pybuild pybuild:283: test: plugin custom failed with: exit code=1: 
> PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=. python2.7 test/test_func.py
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:10: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#883436: mirror submission for mirror.solnode.io

[Ben Babich]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.solnode.io
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ben Babich 
Country: AU Australia
Location: Sydney
Sponsor: SolNode https://solnode.com




Trace Url: http://mirror.solnode.io/debian/project/trace/
Trace Url: http://mirror.solnode.io/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.solnode.io/debian/project/trace/mirror.solnode.io

Bug#883435: akonadi-backend-postgresql: akonadictl start fails with Postgresql 10 installed, likely needs a rebuild

[Diederik de Haas]

Package: akonadi-backend-postgresql
Version: 4:17.08.0-1
Severity: important

Now that qt does support Postgresql 10 (#876421) I upgraded my
Postgresql packages to 10 and migrated the cluster (from 9.6).
After that I did 'akonadictl start' and noticed it was still using
Postgresql 9.6. So I purged that (and rebooted) and after that, akonadi
didn't want to start anymore. For some reason it's explicitly trying to
use pg_ctl from 9.6, but it should use the 10 version.

Konsole output:

$ akonadictl start
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Could not start database server!
org.kde.pim.akonadiserver: executable: "/usr/lib/postgresql/9.6/bin/pg_ctl"
org.kde.pim.akonadiserver: arguments: ("start", "-w", "--timeout=10", 
"--pgdata=/home/diederik/.local/share/akonadi/db_data", "-o 
\"-k/tmp/akonadi-diederik.IOXa0T\" -h ''")
org.kde.pim.akonadiserver: process error: "execvp: No such file or directory"
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...

So my guess is that akonadi-backend-postgresql needs to be rebuild so
that it gets linked to the current Postgresql version, which is 10 (in
both testing and sid).

(Even better would be if it would use the most recent version, but that
may be stretching it)

Cheers,
  Diederik

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

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 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 akonadi-backend-postgresql depends on:
ii  libqt5sql5-psql  5.9.2+dfsg-5

Versions of packages akonadi-backend-postgresql recommends:
ii  akonadi-server  4:17.08.0-1+b1
ii  postgresql  10+188

akonadi-backend-postgresql suggests no packages.

-- no debconf information

Bug#883434: emacs25: Silent file corruption on file with BOM: BOM gets removed

[Vincent Lefevre]

Package: emacs25
Version: 25.2+1-6
Severity: grave
Justification: causes non-serious data loss

Under some conditions, when saving a file with a BOM, the BOM
*silently* gets removed, which is a major change (some applications,
such as Firefox, are BOM-sensitive, so that this bug breaks things
without knowing the cause).

To reproduce the bug:

0. Uncompress the attached file (I used compression to make sure that
   it doesn't get corrupted by the mail system): unxz a.html.xz

1. cp a.html b.html

2. emacs -Q b.html

3. Type M-: (set-buffer-modified-p t) to mark the buffer as modified
   (so that one can save it).

4. Save the file with C-x C-s.

5. Quit with C-x C-c.

6. cmp a.html b.html

This gives:

a.html b.html differ: char 1, line 1

$ hd a.html | head -n 1
  ef bb bf 3c 21 44 4f 43  54 59 50 45 20 68 74 6d  |...

a.html.xz
Description: Binary data

Bug#882512: Pending fixes for bugs in the commons-jci package

[pkg-java-maintainers]

tag 882512 + pending
thanks

Some bugs in the commons-jci package are closed in revision
f280763ce572cb8fd6f543cbd1c3833cacf82229 in branch 'master' by tony
mancill

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/commons-jci.git/commit/?id=f280763

Commit message:

Add wagon-ssh-external to maven.ignoreRules (Closes: #882512)

Bug#875511: RFS: qmdnsengine/0.1.0-1 [ITP]

[Adam Borowski]

On Mon, Sep 11, 2017 at 02:33:31PM -0700, Nathan Osman wrote:
> I am looking for a sponsor for my package "qmdnsengine"
> 
>  * Package name: qmdnsengine
>Version : 0.1.0-1
>Upstream Author : Nathan Osman 
>  * URL : https://github.com/nitroshare/qmdnsengine

> It builds those binary packages:
> 
>   libqmdnsengine-dev - Multicast DNS library for Qt applications -
> development files
>   libqmdnsengine-doc - Multicast DNS library for Qt applications -
> documentation
>   libqmdnsengine-examples - Multicast DNS library for Qt applications -
> examples
>   libqmdnsengine0 - Multicast DNS library for Qt applications

Hi!
It looks like there's quite a backlog of ITP packages.  Yeah, it's
disheartening...

Your package seems to be in a quite good shape.

I'm not sure if a mix of sources and binaries in
/usr/lib/$ARCH_TRIPLET/qmdnsengine/examples is the best place, but I don't
really have a better suggestion.

Alas, while the testsuite during build works, autopkgtest fails:

autopkgtest [01:23:41]: test command1: ctest
autopkgtest [01:23:41]: test command1: [---
bash: ctest: command not found
autopkgtest [01:23:41]: test command1: ---]
autopkgtest [01:23:42]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127
autopkgtest [01:23:42]: test command1:  - - - - - - - - - - stderr - - - - - - 
- - - -
bash: ctest: command not found
autopkgtest [01:23:42]:  summary

It's not just a matter of adding a test dependency on cmake.

There's documentation at:
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html

Note, however, that autopkgtest is something that's nice to have, but
as these are the same stuff as you already run during the build, it's not as
vital.

Also, lintian has something to say.  This is not your fault as there were
recent changes to the policy, but it'd be good to fix them in the next try:
* redundant test headers
* priority: extra
* newest and greatest standards version


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail"
⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah
⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820...;
⠈⠳⣄ (same for all links)

Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.

[Jamie Zawinski]

> Haha, what are you smoking? I don't even bother to look it up,

I guess what I'm smoking are called "facts"?

You said "Sometimes it goes more than a year between upstream's releases". This 
is false. The longest period ever between releases was 8.8 months, and the 
average time between releases has been 52 days.


 1.31:  May 18  1997 - I don't have exact dates for anything older.
 1.32:  May 24  1997 -6 days elapsed
 1.33:  May 30  1997 -6 days elapsed
 1.34:  May 31  1997 -1 days elapsed
 1.35:  Jun  4  1997 -4 days elapsed
 2.00:  Jun  7  1997 -3 days elapsed
 2.01:  Jun 12  1997 -5 days elapsed
 2.02:  Jun 17  1997 -5 days elapsed
 2.03:  Jun 24  1997 -7 days elapsed
 2.04:  Jun 29  1997 -5 days elapsed
 2.05:  Jul  7  1997 -8 days elapsed
 2.06:  Jul 23  1997 -   16 days elapsed
 2.07:  Aug  4  1997 -   12 days elapsed
 2.08:  Oct  7  1997 -  2.1 months elapsed
 2.09:  Oct  7  1997 -0 days elapsed
 2.10:  Oct 18  1997 -   11 days elapsed
 2.11:  Nov 17  1997 -   30 days elapsed
 2.12:  Nov 25  1997 -8 days elapsed
 2.13:  Dec  3  1997 -8 days elapsed
 2.14:  Dec 21  1997 -   18 days elapsed
 2.15:  Jan 17  1998 -   27 days elapsed
 2.16:  Feb 21  1998 -   35 days elapsed
 2.17:  Jun  1  1998 -  3.3 months elapsed
 2.18:  Jun  4  1998 -3 days elapsed
 2.19:  Jun  4  1998 -0 days elapsed
 2.20:  Jun 10  1998 -6 days elapsed
 2.21:  Jun 14  1998 -4 days elapsed
 2.22:  Jun 20  1998 -6 days elapsed
 2.23:  Jun 21  1998 -1 days elapsed
 2.24:  Jun 30  1998 -9 days elapsed
 2.25:  Jul 25  1998 -   25 days elapsed
 2.26:  Jul 25  1998 -0 days elapsed
 2.27:  Aug  4  1998 -   10 days elapsed
 2.28:  Sep 21  1998 -   48 days elapsed
 2.29:  Sep 23  1998 -2 days elapsed
 2.30:  Sep 23  1998 -0 days elapsed
 2.31:  Oct  2  1998 -9 days elapsed
 2.32:  Oct  4  1998 -2 days elapsed
 2.33:  Oct  5  1998 -1 days elapsed
 2.34:  Oct  8  1998 -3 days elapsed
 2.35:  Oct 19  1998 -   11 days elapsed
 3.00:  Oct 20  1998 -1 days elapsed
 3.01:  Oct 24  1998 -4 days elapsed
 3.02:  Oct 25  1998 -1 days elapsed
 3.03:  Nov 15  1998 -   21 days elapsed
 3.04:  Nov 15  1998 -0 days elapsed
 3.05:  Nov 20  1998 -5 days elapsed
 3.06:  Nov 21  1998 -1 days elapsed
 3.07:  Jan  2  1999 -   42 days elapsed
 3.08:  Mar 15  1999 -  2.4 months elapsed
 3.09:  Apr 11  1999 -   26 days elapsed
 3.10:  Apr 27  1999 -   16 days elapsed
 3.11:  May  7  1999 -   10 days elapsed
 3.12:  May 10  1999 -3 days elapsed
 3.13:  May 31  1999 -   21 days elapsed
 3.14:  Jun  5  1999 -5 days elapsed
 3.15:  Jun 20  1999 -   15 days elapsed
 3.16:  Jun 23  1999 -3 days elapsed
 3.17:  Jul 15  1999 -   22 days elapsed
 3.18:  Oct 13  1999 -  3.0 months elapsed
 3.19:  Oct 30  1999 -   17 days elapsed
 3.20:  Nov 12  1999 -   13 days elapsed
 3.21:  Nov 17  1999 -5 days elapsed
 3.22:  Dec  8  1999 -   21 days elapsed
 3.23:  Jan 30  2000 -   53 days elapsed
 3.24:  Apr  3  2000 -  2.1 months elapsed
 3.25:  Jul 18  2000 -  3.5 months elapsed
 3.26:  Nov 10  2000 -  3.8 months elapsed
 3.27:  Jan 19  2001 -  2.3 months elapsed
 3.28:  Jan 23  2001 -4 days elapsed
 3.29:  Feb  5  2001 -   13 days elapsed
 3.30:  Mar 19  2001 -   42 days elapsed
 3.31:  Mar 28  2001 -9 days elapsed
 3.32:  Apr 14  2001 -   16 days elapsed
 3.33:  May 19  2001 -   35 days elapsed
 3.34:  Oct 25  2001 -  5.2 months elapsed
 4.00:  Nov 21  2001 -   27 days elapsed
 4.01:  Feb 24  2002 -  3.1 months elapsed
 4.02:  Mar 18  2002 -   22 days elapsed
 4.03:  Apr 30  2002 -   42 days elapsed
 4.04:  May 28  2002 -   28 days elapsed
 4.05:  Jun  8  2002 -   11 days elapsed
 4.06:  Oct 23  2002 -  4.5 months elapsed
 4.07:  Feb  3  2003 -  3.4 months elapsed
 4.08:  Feb 18  2003 -   15 days elapsed
 4.09:  Mar 17  2003 -   27 days elapsed
 4.10:  May 20  2003 -  2.1 months elapsed
 4.11:  Jun 23  2003 -   34 days elapsed
 4.12:  Aug 14  2003 -   52 days elapsed
 4.13:  Sep  7  2003 -   24 days elapsed
 4.14:  Oct 25  2003 -   48 days elapsed
 4.15:  Feb 26  2004 -  4.1 months elapsed
 4.16:  May 12  2004 -  2.5 months elapsed
 4.17:  Aug 14  2004 -  3.1 months elapsed
 4.18:  Aug 14  2004 -0 days elapsed
 4.19:  Dec 16  2004 -  4.1 months elapsed
 4.20:  Feb 23  2005 -  2.3 months elapsed
 4.21:  Mar 20  2005 -   25 days elapsed
 4.22:  Jun 22  2005 -  3.1 months elapsed
 4.23:  Oct 21  2005 -  4.0 months elapsed
 4.24:  Feb  8  2006 -  3.6 months elapsed
 5.00:  May 23  2006 -  3.4 months elapsed
 5.01:  Sep 18  2006 -  3.9 months elapsed
 5.02:  Apr 20  2007 -  7.0 months elapsed
 5.03:  Jul 17  2007 -  2.9 months elapsed
 5.04:  Nov 13  2007 -  3.9 months elapsed
 5.05:  Mar  1  2008 -  3.6 months elapsed
 5.06:  Jul 16  2008 -  4.5 months elapsed
 5.07:  Aug 10  2008 -   25 days elapsed
 5.08:  Dec 27  2008 -  4.6 months elapsed
 5.09:  Sep  3  2009 -  8.2 months elapsed
 5.10:  Sep  7  2009 -4 days elapsed

Bug#854691: xscreensaver user unit

[Daniel Kahn Gillmor]

On Mon 2017-12-04 00:14:05 +0100, Tormod Volden wrote:
> I am not so into systemd "units", but possibly relevant to your
> question is that it is fully possible that the xscreensaver package is
> installed on a system, but that individual users don't want to have it
> running. Whether it should start by default for a user depends on the
> desktop environment.

I think if xscreensaver is installed, it should be enabled by default.
desktop environments that don't want it enabled can explicitly disable
it for users which launch them, as can users who for whatever reason
want it disabled.

Most systems won't have xscreensaver installed at all unless the user
has requested it, right?

--dkg

Bug#883433: gcc-7: Please include patch to implement __builtin_trap() on SH

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.2.0-16
Severity: important
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

Both src:linux and src:glibc currently FTBFS on sh4 with gcc-7 because
the compiler is missing the implementation of __builtin_trap(). Upstream
has suggested a patch in [1] which I have verified to work.

Since both src:linux and src:glibc are essential packages, I would like
to ask to have this patch merged into src:gcc-7 already even though
upstream has not merged the patch yet in its current form.

I have slightly modified the patch so it applies against src:gcc-7
and I actually tested the patch with Debian's gcc-7 package.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: a/src/gcc/config/sh/sh-c.c
===
--- a/src/gcc/config/sh/sh-c.c  (revision 234258)
+++ b/src/gcc/config/sh/sh-c.c  (working copy)
@@ -147,4 +147,7 @@
 
   cpp_define_formatted (pfile, "__SH_ATOMIC_MODEL_%s__",
selected_atomic_model ().cdef_name);
+
+  if (TARGET_SH4_TRAPA_SLEEP_BUG)
+builtin_define ("__SH4_TRAPA_SLEEP_BUG__");
 }
Index: a/src/gcc/config/sh/sh-protos.h
===
--- a/src/gcc/config/sh/sh-protos.h (revision 234258)
+++ b/src/gcc/config/sh/sh-protos.h (working copy)
@@ -88,6 +88,46 @@
 #define TARGET_ATOMIC_SOFT_IMASK \
   (selected_atomic_model ().type == sh_atomic_model::soft_imask)
 
+/* __builtin_trapa handling options.  */
+struct sh_builtin_trap_handler
+{
+  enum enum_type
+  {
+none = 0,
+libcall,
+trapa,
+
+num_handlers
+  };
+
+  enum_type type;
+  int trapa_imm_val;
+};
+
+extern const sh_builtin_trap_handler& selected_builtin_trap_handler (void);
+
+#define TARGET_BUILTIN_TRAP_NONE \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::none)
+
+#define TARGET_BUILTIN_TRAP_TRAPA \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::trapa)
+
+#define TARGET_BUILTIN_TRAP_TRAPA_VAL_RTX \
+  GEN_INT (selected_builtin_trap_handler ().trapa_imm_val)
+
+#define TARGET_BUILTIN_TRAP_LIBCALL \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::libcall)
+
+#ifdef SH4_TRAPA_SLEEP_BUG_DEFAULT
+#define TARGET_SH4_TRAPA_SLEEP_BUG \
+  (sh4_trapa_sleep_bug_option == -1 ? (SH4_TRAPA_SLEEP_BUG_DEFAULT != 0) \
+   : (sh4_trapa_sleep_bug_option != 0))
+#else
+#define TARGET_SH4_TRAPA_SLEEP_BUG \
+  ((sh4_trapa_sleep_bug_option == -1 && TARGET_SH4 && !TARGET_SH4A) \
+   || sh4_trapa_sleep_bug_option == 1)
+#endif
+
 #ifdef RTX_CODE
 extern rtx sh_fsca_sf2int (void);
 extern rtx sh_fsca_int2sf (void);
Index: a/src/gcc/config/sh/sh.c
===
--- a/src/gcc/config/sh/sh.c(revision 234258)
+++ b/src/gcc/config/sh/sh.c(working copy)
@@ -785,6 +785,102 @@
 #undef err_ret
 }
 
+/* Information on the currently selected __builtin_trap handler.  */
+static sh_builtin_trap_handler selected_builtin_trap_handler_;
+
+const sh_builtin_trap_handler&
+selected_builtin_trap_handler (void)
+{
+  return selected_builtin_trap_handler_;
+}
+
+static sh_builtin_trap_handler
+parse_validate_builtin_trap_option (const char* str)
+{
+  const char* names[sh_builtin_trap_handler::num_handlers];
+  names[sh_builtin_trap_handler::none] = "none";
+  names[sh_builtin_trap_handler::libcall] = "libcall";
+  names[sh_builtin_trap_handler::trapa] = "trapa";
+
+  sh_builtin_trap_handler ret;
+
+  #if defined (SH_BUILTIN_TRAP_DEFAULT_TRAPA)
+#if SH_BUILTIN_TRAP_DEFAULT_TRAPA < 0 || SH_BUILTIN_TRAP_DEFAULT_TRAPA > 
255
+  #error default builtin trap trapa handler value out of range
+#endif
+ret.type = sh_builtin_trap_handler::trapa;
+ret.trapa_imm_val = SH_BUILTIN_TRAP_DEFAULT_TRAPA;
+  #elif defined (SH_BUILTIN_TRAP_DEFAULT_LIBCALL)
+ret.type = sh_builtin_trap_handler::libcall;
+ret.trapa_imm_val = 0;
+  #else
+ret.type = sh_builtin_trap_handler::none;
+ret.trapa_imm_val = 0;
+  #endif
+
+  /* Handle empty string as 'none'.  */
+  if (str == NULL || *str == '\0')
+return ret;
+
+#define err_ret(...) do { error (__VA_ARGS__); return ret; } while (0)
+
+  std::vector tokens;
+  for (std::stringstream ss (str); ss.good (); )
+  {
+tokens.push_back (std::string ());
+std::getline (ss, tokens.back (), ',');
+  }
+
+  if (tokens.empty ())
+err_ret ("invalid builtin trap handler option");
+
+  /* The first token must be the handler name.  */
+  {
+for (size_t i = 0; i < sh_builtin_trap_handler::num_handlers; ++i)
+  if (tokens.front () == names[i])
+   {
+ ret.type = (sh_builtin_trap_handler::enum_type)i;
+ goto 

Bug#883432: Enable CRASH_DUMP for ppc64el/ppc64

[Thadeu Lima de Souza Cascardo]

Source: linux
Severity: wishlist
Tags: patch

kdump won't work on ppc64el, as CRASH_DUMP is not enabled. This has been
used for IBM Power systems for a long time on other OSes, so it should
be safe to enable on 64-bit PPC.

Changes in kdump-tools and makedumpfile that make sense only on ppc64
are in progress to get good kdump support on Debian 64-bit PPC.

The attached patch might have been mangled, sorry about that.
commit 0a2ddd58d9deff60663c7340b8f912c093e9ef24 (HEAD -> master)
Author: Thadeu Lima de Souza Cascardo 
Date:   Thu Nov 30 08:39:00 2017 -0200

[ppc64el,ppc64] Enable CRASH_DUMP

Signed-off-by: Thadeu Lima de Souza Cascardo 

diff --git a/debian/config/kernelarch-powerpc/config-arch-64 
b/debian/config/kernelarch-powerpc/config-arch-64
index 329e7a225a48..e47804aa2b61 100644
--- a/debian/config/kernelarch-powerpc/config-arch-64
+++ b/debian/config/kernelarch-powerpc/config-arch-64
@@ -2,7 +2,7 @@
 ## file: arch/powerpc/Kconfig
 ##
 CONFIG_PPC_TRANSACTIONAL_MEM=y
-# CONFIG_CRASH_DUMP is not set
+CONFIG_CRASH_DUMP=y
 CONFIG_IRQ_ALL_CPUS=y
 CONFIG_NUMA=y
 ## choice: Page size

Bug#883431: eureka: grabs focus when I mouse over the map view subwindow

[Martin Read]

Package: eureka
Version: 1.11-2+b1
Severity: important

Dear Maintainer,

I don't use focus-follows-mouse (because I find explicit focus control
far more congenial than implicit focus control).

All other GUI programs I can remember invoking on Debian have respected
this.

The map view subwindow in Eureka does not; it grabs focus (and,
consequently, *raises Eureka's window*) whenever I pass my mouse over it.

Based on the behaviour of a locally-built binary compiled from the upstream
source code, I believe this bug to also be present in 1.21.

I will therefore be uninstalling it shortly.

Have a nice day.

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

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

Versions of packages eureka depends on:
ii  libc6  2.24-11+deb9u1
ii  libfltk-images1.3  1.3.4-4
ii  libfltk1.3 1.3.4-4
ii  libgcc11:6.3.0-18
ii  libstdc++6 6.3.0-18
ii  libx11-6   2:1.6.4-3
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages eureka recommends:
ii  doom-wad [doom-wad]  37
ii  doom2-wad [doom-wad] 37
ii  game-data-packager   49.1
ii  plutonia-wad [doom-wad]  37
ii  tnt-wad [doom-wad]   37

eureka suggests no packages.

-- no debconf information

Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.

[Tormod Volden]

Haha, what are you smoking? I don't even bother to look it up, I guess
there is not even dates in your changelog. It is more like 1-2 per
calendar year maximum. The one that went into Debian's previous stable
release and you made so much fuzz about, had been the last release for
I don't know how long. Of course if there is a release in February one
year, and July and September the next year, there is one in every
calendar year, but it would be more than a year between.

Tormod

Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.

[Jamie Zawinski]

> Sometimes it goes more than a year between upstream's releases also, 

This has literally never happened.

There are typically 4-8 releases a year, but there have never been fewer than 2 
per year, since 1992.

Bug#883419: python3-requests: RequestsDependencyWarning urllib3 (1.21.1) or chardet (2.3.0) doesn't match a supported version

[Daniele Tricoli]

Hello xiscu,
thanks for the report.

On Sunday, December 3, 2017 8:39:41 PM CET xiscu wrote:
> Package: python3-requests
> Version: 2.12.4-1
> Severity: important
> 
> Dear Maintainer,
> importing requests on python3 raises a dependency warning:
> 
> $ python3
> Python 3.5.3 (default, Jan 19 2017, 14:11:04)
> [GCC 6.3.0 20170118] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> import requests
> 
> /home/ci/.local/lib/python3.5/site-packages/requests/__init__.py:80:
> RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.3.0) doesn't
> match a supported version! RequestsDependencyWarning)
> 
> Is it possible to update urllib3 at least to version 1.21.1 as recomended ?

As far I can see from the warning, it seems that you are using a local 
installed version of requests. Are you mixing system packages with local 
installed one? This use case is not supported on Debian, can you use a 
virtualenv instead?
I suppose you are using Debian stable, right? urllib3 is at version 1.21.1 in 
testing.

Cheers,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

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

Bug#854691: xscreensaver user unit

[Tormod Volden]

On Fri, Oct 27, 2017 at 4:23 AM, Daniel Kahn Gillmor wrote:
> On Thu 2017-08-31 12:07:10 +1000, Jeremy Visser wrote:
>> I've attached a patch which fixes the issue.

Thanks for the patch, and for forwarding it here (don't know where it was sent).

>
> Jeremy's patch (below) looks reasonable to me.  Even better would be to
> have it include other useful metadata in the [Unit] section, like:
>
> Documentation=man:xscreensaver(1)
> Documentation=man:xscreensaver-command(1)
> Documentation=man:xscreensaver-demo(1)
> PartOf=graphical-session.target
>

Thanks.

> xscreensaver(1) currently has a suggestion for this file.  It should
> probably also be adjusted to remove the example, and explain
> specifically that all the user needs to do is:
>
>systemctl --user enable xscreensaver
>
> Arguably, this user unit should be enabled by default.  Is there any
> reason to ship it disabled?

I am not so into systemd "units", but possibly relevant to your
question is that it is fully possible that the xscreensaver package is
installed on a system, but that individual users don't want to have it
running. Whether it should start by default for a user depends on the
desktop environment.

Regards,
Tormod


>
> --dkg
>
>> From 76072fa4cba00e6a6009324d6b9e0cf1d3fdc82f Mon Sep 17 00:00:00 2001
>> From: Jeremy Visser 
>> Date: Thu, 31 Aug 2017 11:53:00 +1000
>> Subject: [PATCH] Fix broken systemd unit
>>
>> The ExecStart= line must be an absolute path as per systemd.service(5),
>> but is currently a relative path. This change points it to
>> /usr/bin/xscreensaver.
>> ---

Bug#883430: ITP: stex -- stex to latex and latex to html converters and associated tools

[Göran Weinholt]

Package: wnpp
Severity: wishlist
Owner: Göran Weinholt 

* Package name: stex
  Version : 1.2.1
  Upstream Author : R. Kent Dybvig and Oscar Waddell
* URL or Web page : https://github.com/dybvig/stex
* License : MIT/Expat
  Programming Lang: Scheme, TeX
  Description : stex to latex and latex to html converters and associated 
tools

This is a build dependency of Chez Scheme.

Bug#823425: Processed: retitle to RFP: chez-scheme -- Implementation of the R6RS Scheme language

[Göran Weinholt]

retitle 823425 ITP: chezscheme -- Implementation of the R6RS Scheme language
owner 823425 !
thanks

"Barak A. Pearlmutter"  writes:

> Thanks for the retitle etc. When I got my teeth into it three were
> some subsidiary unpackaged tools used in the chez build and so I went
> down a rabbit hole of packaging them and never emerged.

> That was a while ago so upstream may have simplified the situation in
> the meantime.

Hello Barak,

I'm "stealing" this ITP/RFP (but you may have it back if you so wish).
As a big user of Chez Scheme, I really want to see it packaged in
Debian.

You may have noticed that I used "chezscheme" in the new title rather
than "chez-scheme". The "chezscheme" designation is used everywhere by
upstream, so I believe it is more appropriate.

The build dependencies are a bit tricky to get right, but I think I have
it handled. I will submit ITPs for them.

My Debian account has emeritus status. I've sent a message to
da-manager@ about it. We'll see how that goes. Would you be willing to
sponsor my uploads until my account is re-activated?

Regards,

-- 
Göran Weinholt 
73 de SA6CJK


signature.asc
Description: PGP signature

Bug#883429: ITP: nanopass-framework-scheme -- Embedded DSL for writing compilers in Scheme

[Göran Weinholt]

Package: wnpp
Severity: wishlist
Owner: Göran Weinholt 

* Package name: nanopass-framework-scheme
  Version : 1.9
  Upstream Author : Dipanwita Sarkar, Andrew W. Keep, R. Kent Dybvig, Oscar 
Waddell
* URL : https://github.com/nanopass/nanopass-framework-scheme
* License : MIT/Expat
  Programming Lang: Scheme
  Description : Embedded DSL for writing compilers in Scheme

This is a build dependency of Chez Scheme.

Bug#883426: transition: confuse

[Aurelien Jarno]

On 2017-12-03 23:41, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 03/12/17 23:28, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > I would like to request a transition slot for the libconfuse1 to
> > libconfuse2 transition. I have already uploaded the package to
> > experimental, so there is already a tracker entry available:
> > 
> >   https://release.debian.org/transitions/html/auto-confuse.html
> > 
> > There are 14 reverse dependencies, and I have checked that they all
> > currently build (on amd64) against libconfuse2.
> 
> Please go ahead.

Thanks, I have just uploaded it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.

[Tormod Volden]

Hi,
With regards to the latest XScreenSaver release, which I hope will fix
this issue, I was fast getting it packaged up in git, but it has
sitting there for a while because I need to check all the Debian QA
stuff, new policies, etc, and get someone to review it, but most
importantly real life got in the way. Anyway from the changelog it
doesn't seem so crucial to get it out. Sometimes it goes more than a
year between upstream's releases also, I don't think a few months of
"ripening" is a big problem.

Regards,
Tormod


On Sun, Oct 15, 2017 at 3:26 AM, Beardy Face wrote:
> On Sat, 14 Oct 2017 17:37:26 -0700 Jamie Zawinski wrote:
>> Well,
>>
>> 5.36 was released on 11 Oct 2016, which, as of the date of this bug
>> report, was 1 year and 3 days old.
>>
>> 5.37, which contains webcollage updates, was released on 5 July 2017.
>>
>> The latency with which distros package it up for you is entirely out of my
>> hands.
>>

Bug#883428: dolphin: Please provide the option to drag and drop files/folders

[annadane]

Package: dolphin
Version: 4:17.08.3-1
Severity: wishlist

Dear Maintainer,

As far as I can tell, there is no drag and drop option for folders/files in 
Dolphin. There's a variety of sorting options, but nothing that allows you to 
manually rearrange via the mouse. I would like this very much, thanks

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

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

Versions of packages dolphin depends on:
ii  baloo-kf5  5.37.0-2
ii  kinit  5.37.0-2
ii  kio5.37.0-2
ii  libc6  2.25-3
ii  libdolphinvcs5 4:17.08.3-1
ii  libkf5baloo5   5.37.0-2
ii  libkf5baloowidgets54:17.08.3-1
ii  libkf5bookmarks5   5.37.0-2
ii  libkf5codecs5  5.37.0-2
ii  libkf5completion5  5.37.0-2
ii  libkf5configcore5  5.37.0-2
ii  libkf5configgui5   5.37.0-2
ii  libkf5configwidgets5   5.37.0-2
ii  libkf5coreaddons5  5.37.0-2
ii  libkf5crash5   5.37.0-2
ii  libkf5dbusaddons5  5.37.0-2
ii  libkf5filemetadata35.37.0-2
ii  libkf5i18n55.37.0-2
ii  libkf5iconthemes5  5.37.0-2
ii  libkf5itemviews5   5.37.0-2
ii  libkf5jobwidgets5  5.37.0-2
ii  libkf5kcmutils55.37.0-2
ii  libkf5kiocore5 5.37.0-2
ii  libkf5kiofilewidgets5  5.37.0-2
ii  libkf5kiowidgets5  5.37.0-2
ii  libkf5newstuff55.37.0-2
ii  libkf5notifications5   5.37.0-2
ii  libkf5parts5   5.37.0-2
ii  libkf5service-bin  5.37.0-2
ii  libkf5service5 5.37.0-2
ii  libkf5solid5   5.37.0-2
ii  libkf5textwidgets5 5.37.0-2
ii  libkf5widgetsaddons5   5.37.0-2
ii  libkf5xmlgui5  5.37.0-2
ii  libphonon4qt5-44:4.9.0-4
ii  libqt5core5a   5.9.2+dfsg-5
ii  libqt5dbus55.9.2+dfsg-5
ii  libqt5gui5 5.9.2+dfsg-5
ii  libqt5widgets5 5.9.2+dfsg-5
ii  libqt5xml5 5.9.2+dfsg-5
ii  libstdc++6 7.2.0-16
ii  phonon4qt5 4:4.9.0-4

Versions of packages dolphin recommends:
ii  kio-extras  4:16.08.3-1
ii  ruby1:2.3.3

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#878379: xscreensaver-screensaver-webcollage: Please provide a means to set safe seach levels for those image search mehods that support it.

[Tormod Volden]

Hi,
Thanks for the suggestion. It's legitimate wish, but nothing I will
look into unless someone sends a patch. I also share upstream opinion
on this to a large degree, and people can refrain from installing
webcollage if they are afraid of what internet can come up with.
Personally I am skeptical to the judgment of $SEARCHENGINE to what is
considered offending, politically incorrect or just unpleasant and
easiest censored away, and I always turn off those filters as much as
I can.

Regards,
Tormod

Bug#883427: virtualbox-dkms: patch for 5.2.2-dfsg-2

[Carlo Valenti]

Package: virtualbox-dkms
Version: 5.2.2-dfsg-2

'r0drv/linux/timer-r0drv-linux.c' fails to build for kernel versions
>=~4.14.0 (git commit 185981d5), due to 'include/linux/timer.h'
recently dropping init_timer_pinned() in favor of newer timer_setup()

Patch:

--- tstdir/usr/src/virtualbox-5.2.2/r0drv/linux/timer-r0drv-linux.c
2017-11-23 04:22:25.0 -0500
+++ /home/deb/timer-r0drv-linux.c 2017-12-03 16:47:35.627778217 -0500
@@ -720,9 +720,15 @@
  *
  * @param   ulUser  Address of the sub-timer structure.
  */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 14, 0)
+static void rtTimerLinuxStdCallback(struct timer_list *t)
+{
+PRTTIMERLNXSUBTIMER pSubTimer = from_timer(pSubTimer, t, u.Std.LnxTimer);
+#else
 static void rtTimerLinuxStdCallback(unsigned long ulUser)
 {
 PRTTIMERLNXSUBTIMER pSubTimer = (PRTTIMERLNXSUBTIMER)ulUser;
+#endif /* => KERNEL_VERSION(4, 14, 0) */
 PRTTIMERpTimer= pSubTimer->pParent;

 RTTIMERLNX_LOG(("stdcallback %p\n", pTimer));
@@ -1584,15 +1590,19 @@
 else
 #endif
 {
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0)
-init_timer_pinned(>aSubTimers[iCpu].u.Std.LnxTimer);
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 14, 0)
+timer_setup(>aSubTimers[iCpu].u.Std.LnxTimer,
rtTimerLinuxStdCallback, TIMER_PINNED);
 #else
+  #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0)
+init_timer_pinned(>aSubTimers[iCpu].u.Std.LnxTimer);
+  #else
 init_timer(>aSubTimers[iCpu].u.Std.LnxTimer);
-#endif
+  #endif /* >= KERNEL_VERSION(4, 8, 0) */
 pTimer->aSubTimers[iCpu].u.Std.LnxTimer.data=
(unsigned long)>aSubTimers[iCpu];
 pTimer->aSubTimers[iCpu].u.Std.LnxTimer.function=
rtTimerLinuxStdCallback;
 pTimer->aSubTimers[iCpu].u.Std.LnxTimer.expires = jiffies;
 pTimer->aSubTimers[iCpu].u.Std.u64NextTS= 0;
+#endif /* => KERNEL_VERSION(4, 14, 0) */
 }
 pTimer->aSubTimers[iCpu].iTick  = 0;
 pTimer->aSubTimers[iCpu].pParent= pTimer;

Bug#883426: transition: confuse

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 03/12/17 23:28, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to request a transition slot for the libconfuse1 to
> libconfuse2 transition. I have already uploaded the package to
> experimental, so there is already a tracker entry available:
> 
>   https://release.debian.org/transitions/html/auto-confuse.html
> 
> There are 14 reverse dependencies, and I have checked that they all
> currently build (on amd64) against libconfuse2.

Please go ahead.

Emilio

Bug#883425: linux-image-4.14.0-1-amd64: stale Android device entries in Thunar after USB disconnection

[Ben Caradoc-Davies]

Note that USB mass storage devices such as thumb drives are not 
affected: their Thunar entries disappear when they are disconnected.


Note also that the stale Android device entries persist until system 
reboot. Exiting all Thunar instances does not fix.


lsusb does not show the stale entries.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

On 03/12/2017 17:37, Clément Hermann wrote:
> On 21/11/2017 12:48, Clément Hermann wrote:
>> When I wanted to build the package, I realized it's not using
>> git-buildpackage, as the other Go packages do.
>>
>> Is it intentional, or do you plan to use graft or something like that to
>> rewrite history and have the proper branches ? I had a look at it, and
>> I'm not really comfortable enough with git
>> to do it without messing things up, so I wonder what the options are.
> 
> So, looking at it more closely, I found out that the initial commit is
> actually the upstream source, which means we can just branch from it for
> the upstream branch.
> 
> While waiting for the workflow changes following DebConf17 BoF [0], I
> guess the best is to be as standard as possible, even if it's a bit
> painful in this case, since uscan doesn't allow arbitrary snapshots yet
> [1] and upstream stopped doing releases ages ago. So I guess manual
> snapshot and pristine-tar is the way to go.
> 
> Of course if you have upstream and pristine-tar branch locally it would
> be great to push them ;)
> 
> 
> I asked to join the pkg-go project on alioth, because I have a couple
> commits ready locally for trivial nitpick, but I guess this package is
> not far from upload, and I'm preparing an ITP for
> golang-gopkg-lxc-go-lxc.v2-dev.
> 
> Would anyone mind rewieving / uploading ? Jonathan, are you still
> working on this, or should I take over the ITP ?
> 

I just uploaded my fixes and pushed the missing branches/tags.

All it needs now is rewiewing, signed tag and upload, hopefully.


Cheers,

-- 
nodens

Bug#878318: nyquist FTBFS with gcc 7: undefined references

[Juhani Numminen]

On Thu, 12 Oct 2017 22:32:20 +0300 Adrian Bunk  wrote:


ffts/src/fftlib.o: In function `fftrecurs':
fftlib.c:(.text+0xcf8): undefined reference to `bfstages'
ffts/src/fftlib.o: In function `ffts1':
fftlib.c:(.text+0x1441): undefined reference to `bfstages'
ffts/src/fftlib.o: In function `ifftrecurs':
fftlib.c:(.text+0x250a): undefined reference to `ibfstages'
ffts/src/fftlib.o: In function `iffts1':
fftlib.c:(.text+0x2d30): undefined reference to `ibfstages'
ffts/src/fftlib.o: In function `.L186':
fftlib.c:(.text+0x3cd2): undefined reference to `bfstages'
ffts/src/fftlib.o: In function `riffts1':
fftlib.c:(.text+0x4c5c): undefined reference to `ibfstages'


A FreeBSD bug from 2012 looks similar, there the fix was
s|inline void|static inline void|.[1]
That change entered upstream repository earlier in 2012.[2]
Debian's version doesn't have it.[3]

Regards,
Juhani

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174376
https://sourceforge.net/p/nyquist/code/73/
https://sources.debian.org/src/nyquist/3.05-2.1/ffts/src/fftlib.c/#L64

Bug#883426: transition: confuse

[Aurelien Jarno]

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

Dear release team,

I would like to request a transition slot for the libconfuse1 to
libconfuse2 transition. I have already uploaded the package to
experimental, so there is already a tracker entry available:

  https://release.debian.org/transitions/html/auto-confuse.html

There are 14 reverse dependencies, and I have checked that they all
currently build (on amd64) against libconfuse2.

Ben file:

title = "confuse";
is_affected = .depends ~ "libconfuse1" | .depends ~ "libconfuse2";
is_good = .depends ~ "libconfuse2";
is_bad = .depends ~ "libconfuse1";

Thanks,
Aurelien

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

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

Bug#876299: pcre3: ftbfs on s390x, test failures

[Matthew Vernon]

On 11/10/17 08:39, Gianfranco Costamagna wrote:

control: tags -1 -moreinfo


Could you try re-running this test on s390x with a higher stack limit
set, please?

ulimit -s unlimited && dpkg-buildpackage works on zelenka (s390x porterbox)


I thought I'd modified the build script to have the same effect (up 
ulimit before running tests), would you care to tell me what I did 
wrong, please?


Thanks,

Matthew

Bug#876299: ulimit change didn't work

[Matthew Vernon]

control: reopen -1
quit

2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't 
seem to have worked on on s390, despite the build being known to work if 
called entirely with ulimit -s unlimited. I think I'd like some help 
from the s390 people here - how am I driving the buildd wrong?


Regards,

Matthew

Bug#876087: xscreensaver: source-less and unlicensed code at hacks/images/m6502/dmsc.asm

[Tormod Volden]

On Sun, Sep 24, 2017 at 9:02 PM, Daniel Serpell wrote:
> Attached is the source to the demo, in 6502 assembly, with a GPL
> license.

Daniel and Daniel,
Thanks a lot for sorting this out. Sometimes someone just has to ask
and it is as easy as that.

Regards,
Tormod

Bug#880701: lintian: Please update the Debian archive sections

[Clément Hermann]

Control: reopen -1

Control: block -1 847520

reopening since it's not fixed after all ;)

(just noticed this because I was bit by the "resolution")

Cheers,

-- 
nodens

Bug#876299: (no subject)

[Matthew Vernon]

control: reopen -1
quit

2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't 
seem to have worked on on s390, despite the build being known to work if 
called entirely with ulimit -s unlimited. I think I'd like some help 
from the s390 people here - how am I driving the buildd wrong?


Regards,

Matthew

Bug#883425: linux-image-4.14.0-1-amd64: stale Android device entries in Thunar after USB disconnection

[Ben Caradoc-Davies]

Package: src:linux
Version: 4.14.2-1
Severity: normal

Dear Maintainer,

since upgrade to linux-image-4.14.0-1-amd64 4.14.2-1, USB disconnection of
Android devices leaves stale entries in Thunar. Repeated connection and
disconnection leaves multiple stale device entries. Only the most recent device
entry is usable. Booting into linux-image-4.13.0-1-amd64 4.13.13-1 removes this
behaviour.

journalctl reveals new upowerd "unhandled action" log entries under linux-
image-4.14.0-1-amd64 4.14.2-1.


Bug seen with:

Linux ripley 4.14.0-1-amd64 #1 SMP Debian 4.14.2-1 (2017-11-30) x86_64
GNU/Linux

journalctl excerpt:

Dec 04 10:44:06 ripley kernel: usb 1-9: new high-speed USB device number 4
using xhci_hcd
Dec 04 10:44:06 ripley kernel: usb 1-9: New USB device found, idVendor=18d1,
idProduct=4ee1
Dec 04 10:44:06 ripley kernel: usb 1-9: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Dec 04 10:44:06 ripley kernel: usb 1-9: Product: Nexus 5X
Dec 04 10:44:06 ripley kernel: usb 1-9: Manufacturer: LGE
Dec 04 10:44:06 ripley kernel: usb 1-9: SerialNumber: [...]
Dec 04 10:44:06 ripley gvfs-gphoto2-vo[1096]: device (null) has no BUSNUM
property, ignoring
Dec 04 10:44:06 ripley upowerd[1037]: unhandled action 'bind' on
/sys/devices/pci:00/:00:14.0/usb1/1-9
Dec 04 10:44:10 ripley kernel: usb 1-9: USB disconnect, device number 4
Dec 04 10:44:10 ripley upowerd[1037]: unhandled action 'unbind' on
/sys/devices/pci:00/:00:14.0/usb1/1-9


Bug not seen with:

Linux ripley 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64
GNU/Linux

journalctl excerpt:

Dec 04 10:40:53 ripley kernel: usb 1-9: new high-speed USB device number 4
using xhci_hcd
Dec 04 10:40:53 ripley kernel: usb 1-9: New USB device found, idVendor=18d1,
idProduct=4ee1
Dec 04 10:40:53 ripley kernel: usb 1-9: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Dec 04 10:40:53 ripley kernel: usb 1-9: Product: Nexus 5X
Dec 04 10:40:53 ripley kernel: usb 1-9: Manufacturer: LGE
Dec 04 10:40:53 ripley kernel: usb 1-9: SerialNumber: [...]
Dec 04 10:40:53 ripley gvfs-gphoto2-vo[1080]: device (null) has no BUSNUM
property, ignoring
Dec 04 10:40:57 ripley kernel: usb 1-9: USB disconnect, device number 4


Kind regards,
Ben.



-- Package-specific info:
** Version:
Linux version 4.14.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-16)) #1 SMP Debian 4.14.2-1 (2017-11-30)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-1-amd64 root=/dev/mapper/vg-root ro quiet 
net.ifnames=0 splash

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 3404
board_vendor: ASUSTeK COMPUTER INC.
board_name: H110I-PLUS
board_version: Rev X.0x

** Loaded modules:
ctr
ccm
arc4
ip6t_REJECT
nf_reject_ipv6
nf_conntrack_ipv6
nf_defrag_ipv6
ip6table_filter
ip6_tables
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nf_conntrack_ipv4
nf_defrag_ipv4
xt_conntrack
nf_conntrack
iptable_filter
binfmt_misc
snd_hda_codec_hdmi
nls_ascii
nls_cp437
vfat
fat
snd_hda_codec_realtek
snd_hda_codec_generic
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
hci_uart
btqca
kvm_intel
btintel
bluetooth
kvm
ath9k_htc
ath9k_common
irqbypass
ath9k_hw
intel_cstate
snd_hda_intel
ath
intel_uncore
snd_hda_codec
mac80211
snd_hda_core
snd_hwdep
snd_pcm
drbg
joydev
snd_timer
cfg80211
ansi_cprng
intel_rapl_perf
pcspkr
efi_pstore
eeepc_wmi
snd
asus_wmi
sparse_keymap
wmi_bmof
efivars
mei_me
soundcore
iTCO_wdt
sg
shpchp
iTCO_vendor_support
mei
battery
ecdh_generic
rfkill
intel_lpss_acpi
intel_lpss
mfd_core
acpi_als
evdev
kfifo_buf
industrialio
acpi_pad
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
btrfs
zstd_decompress
zstd_compress
xxhash
algif_skcipher
af_alg
dm_crypt
dm_mod
hid_generic
usbhid
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
sd_mod
mxm_wmi
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
aesni_intel
aes_x86_64
crypto_simd
glue_helper
cryptd
i915
ahci
libahci
xhci_pci
i2c_algo_bit
libata
xhci_hcd
drm_kms_helper
r8169
i2c_i801
mii
usbcore
scsi_mod
drm
usb_common
fan
thermal
wmi
video
i2c_hid
hid
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Intel Kaby Lake Host Bridge 
[8086:591f] (rev 05)
Subsystem: ASUSTeK Computer Inc. Intel Kaby Lake Host Bridge [1043:8694]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 
[8086:5912] (rev 04) (prog-if 00 [VGA controller])

Bug#875776: Pending fixes for bugs in the openid4java package

[pkg-java-maintainers]

tag 875776 + pending
thanks

Some bugs in the openid4java package are closed in revision
dc21ba4166ffc0a12a2fc810a580694cfc6e87ab in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/openid4java.git/commit/?id=dc21ba4

Commit message:

Removed the -java-doc package (Closes: #875776)

Bug#800984: Pending fixes for bugs in the openid4java package

[pkg-java-maintainers]

tag 800984 + pending
thanks

Some bugs in the openid4java package are closed in revision
5772d42ee51a07a95790b008cb089bb3cae0d0c2 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/openid4java.git/commit/?id=5772d42

Commit message:

Removed the dependency on libcommons-httpclient-java (Closes: #800984)

Bug#873108: xscreensaver does not trap errors from intltool-update

[Tormod Volden]

On Thu, Aug 24, 2017 at 6:00 PM, Helmut Grohne  wrote:
> Source: xscreensaver
> Version: 5.36-1
> Severity: serious
> Justification: policy 4.6
> User: helm...@debian.org
> Usertags: rebootstrap
>
> The debian policy section 4.6 requires that when build commands fail,
> the build should abort. In case xscreensaver's intltool-update aborts,
> the error is ignored and the build attempts to continue potentially
> resulting in a broken package. Adding "set -e; " (as suggested by the
> policy) or chaining the commands with "&&" fixes this issue.

Hi Helmut,
In which cases can the inttool-update fail on Debian? In any case, I
have nothing against adding set -e if that can help.

Regards,
Tormod

Bug#873106: xscreensaver FTCBFS: fails to detect a working c compiler

[Tormod Volden]

On Thu, Aug 24, 2017 at 5:57 PM, Helmut Grohne  wrote:
>
> xscreensaver fails to cross build from source, because it insists on
> using AC_TRY_RUN to verify that the compiler works. That's generally a
> bad idea and can simply be discarded. It also uses the build
> architecture pkg-config. After fixing both, it cross builds
> successfully. Please consider applying the attached patch.
>
> Helmut

Hi Helmut,
Thanks for the patch, looks good.

Note that the xscreensaver packaging is maintained in git, so git
format patches are welcome, as an alternative to debdiffs.

Regards,
Tormod

Bug#853708: wxhexeditor: ftbfs with GCC-7

[Juhani Numminen]

On Tue, 31 Jan 2017 09:36:48 + Matthias Klose  wrote:


...
 from src/HexDialogs.cpp:25:
src/HexEditorCtrl/HexEditorCtrl.h: In member function 'uint64_t 
Select::GetSize()':
src/HexEditorCtrl/HexEditorCtrl.h:63:39: error: call of overloaded 
'abs(uint64_t)' is ambiguous


This is probably fixed upstream.
https://github.com/EUA/wxHexEditor/commit/581fdbf36e818803f1adffe2c62fb797482b2bca

Thanks,
Juhani

Bug#879853: netcat-openbsd: support -s with -l

[Guilhem Moulin]

Control: tag -1 pending

On Thu, 23 Nov 2017 at 20:33:10 +0100, Uwe Kleine-König wrote:
> Hmm, regarding the above command the man page claims:
> 
>   It is an error to use [-l] in conjunction with the -p, -s, or -z
>   options.
> 
> which isn't treated as an error but does the same as
> 
>   nc -l 12345
> 
> (which in turn does something else when using netcat-traditional that
> needs -p to specify the (more suitable named) "local port number").

Using -l together with -p is in fact a Debian specific patch, but we
forgot to edit the manpage accordingly.  I just fixed that, and also
allow the use of -l in conjunction with -s for consistency with
netcat-traditional.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#883124: stretch-pu: package golang-github-go-ldap-ldap/2.4.1-1

[Adam D. Barratt]

On Sun, 2017-12-03 at 22:20 +0100, Dr. Tobias Quathamer wrote:
> Am 02.12.2017 um 13:12 schrieb Adam D. Barratt:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2017-11-29 at 23:53 +0100, Dr. Tobias Quathamer wrote:
> > > I've prepared a fix for CVE-2017-14623, Debian BTS #876404. The
> > > security team does not intend to publish a DSA for this minor
> > > issue,
> > > so I'm asking here if you would accept an upload for stable-
> > > proposed-
> > > updates.
> > 
> > As this doesn't appear to affect anything else in-archive at least,
> > please go ahead.
> 
> Thanks, the package has been uploaded and just accepted into
> proposed-updates.

It's been accepted into the stable-new queue. It won't be accepted into
proposed-updates until a member of the Release Team asks the archive
software to do that (which now won't be until at least next weekend, as
things are frozen in preparation for the upcoming point releases).

Regards,

Adam

Bug#882365: osspd FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

On Sun, Dec 03, 2017 at 10:11:06PM +0100, Ralf Jung wrote:
> However, this fails: gbp buildpackage --git-builder=sbuild --dist
> unstable --host i386 --add-depends=libc-dev,libstdc++-dev
> 
> I pasted the log below.

Thank you. Unfortunately, i386 is broken as a cross build host. You may
know that it receives a waiver from the release team when the question
of porters arises. I am eager to meet our plethora of i386 porters, but
thus far I failed to locate any of them. If you happen to find some,
please send them to me. I'm afraid you'll have to use a different host
for testing for now.  For mips64el, the toolchain is currently broken
(#882263). Most other release architectures (but amd64) should really
just work. At least for arm64, armel, armhf, mips, mipsel, s390x, and
ppc64el, I've recently performed successful cross builds. The slower
architectures occasionally are prone to version skews. Thus I tend to
use ppc64el for testing.

Helmut

Bug#879801: ftbfs with icu from experimental

[Hilmar Preuße]

Am 26.10.2017 um 09:42 teilte Matthias Klose mit:

Hi Laszlo,


icu from experimental dropped the icu-config binary, and texlive-bin
doesn't have a fallback for pkg-config icu-i18n.


changelog of icu:

icu (59.1-1) experimental; urgency=low

  * New major upstream release.
  * Remove icu-config from libicu-dev :
- make the package 'Multi-Arch: same' again (closes: #837898).
  * Don't fail on i386 self-tests, known problem.

 -- Laszlo Boszormenyi (GCS)   Fri, 12 May 2017 
15:34:54 +


We now that icu-config is not recommended any more, but still supported 
upstream[1] . Do see a change to provide the script in any way? Yes, I 
know you removed it to solve another bug.


Thanks a lot!

Hilmar

[1] http://userguide.icu-project.org/howtouseicu
--
#206401 http://counter.li.org

Bug#883124: stretch-pu: package golang-github-go-ldap-ldap/2.4.1-1

[Dr. Tobias Quathamer]

Am 02.12.2017 um 13:12 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Wed, 2017-11-29 at 23:53 +0100, Dr. Tobias Quathamer wrote:
>> I've prepared a fix for CVE-2017-14623, Debian BTS #876404. The
>> security team does not intend to publish a DSA for this minor issue,
>> so I'm asking here if you would accept an upload for stable-proposed-
>> updates.
> 
> As this doesn't appear to affect anything else in-archive at least,
> please go ahead.

Thanks, the package has been uploaded and just accepted into
proposed-updates.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#883424: build-essential: Please enable Debian Ports architectures for cross-build-essential

[John Paul Adrian Glaubitz]

Source: build-essential
Version: 12.4
Severity: normal
Tags: patch

Hi!

I have been in the situation many times where I wanted to cross-build
a package for any of the Debian Ports architectures only to find out
there is no cross-build-essential-$ARCH package for a given ports
architecture $ARCH.

The attached patch enables all ports architectures in the build-essential
package and allows cross-building packages for ports architectures using
sbuild --host=$ARCH.

Alternatively, just comment out alpha, hppa, m68k, powerpcspe, ppc64, sh4,
sparc64 and x32 in debian/cross-targets and run debian/rules debian/control
to regenerate the control file. Although, I'm not sure whether it actually
makes sense to include x32 here.

Either way, would be awesome to have this finally resolved.

Thanks,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru build-essential-12.4/debian/control 
build-essential-12.4/debian/control
--- build-essential-12.4/debian/control 2017-09-17 13:06:17.0 +0200
+++ build-essential-12.4/debian/control 2017-09-17 13:06:39.0 +0200
@@ -31,6 +31,25 @@
  most people need.   However, if this package and the manual disagree,
  the manual is correct.
 
+Package: crossbuild-essential-alpha
+Architecture: all
+Depends: ${cross-essential}, ${misc:Depends}
+Description: Informational list of cross-build-essential packages
+ If you do not plan to cross build Debian packages, you don't need
+ this package.  Starting with sbuild (>= 0.63.0) this package is
+ required for cross building Debian packages in a chroot.
+ .
+ This package contains an informational list of packages which are
+ considered essential for cross building Debian packages.  This
+ package also depends on the packages on that list, to make it easy to
+ have the cross-build-essential packages installed.
+ .
+ If you have this package installed, you only need to install whatever
+ a package specifies as its build-time dependencies to cross build the
+ package.  Conversely, if you are determining what your package needs
+ to build-depend on, you can always leave out the packages this
+ package depends on.
+
 Package: crossbuild-essential-arm64
 Architecture: all
 Depends: ${cross-essential}, ${misc:Depends}
@@ -88,6 +107,44 @@
  to build-depend on, you can always leave out the packages this
  package depends on.
 
+Package: crossbuild-essential-hppa
+Architecture: all
+Depends: ${cross-essential}, ${misc:Depends}
+Description: Informational list of cross-build-essential packages
+ If you do not plan to cross build Debian packages, you don't need
+ this package.  Starting with sbuild (>= 0.63.0) this package is
+ required for cross building Debian packages in a chroot.
+ .
+ This package contains an informational list of packages which are
+ considered essential for cross building Debian packages.  This
+ package also depends on the packages on that list, to make it easy to
+ have the cross-build-essential packages installed.
+ .
+ If you have this package installed, you only need to install whatever
+ a package specifies as its build-time dependencies to cross build the
+ package.  Conversely, if you are determining what your package needs
+ to build-depend on, you can always leave out the packages this
+ package depends on.
+
+Package: crossbuild-essential-m68k
+Architecture: all
+Depends: ${cross-essential}, ${misc:Depends}
+Description: Informational list of cross-build-essential packages
+ If you do not plan to cross build Debian packages, you don't need
+ this package.  Starting with sbuild (>= 0.63.0) this package is
+ required for cross building Debian packages in a chroot.
+ .
+ This package contains an informational list of packages which are
+ considered essential for cross building Debian packages.  This
+ package also depends on the packages on that list, to make it easy to
+ have the cross-build-essential packages installed.
+ .
+ If you have this package installed, you only need to install whatever
+ a package specifies as its build-time dependencies to cross build the
+ package.  Conversely, if you are determining what your package needs
+ to build-depend on, you can always leave out the packages this
+ package depends on.
+
 Package: crossbuild-essential-mips
 Architecture: all
 Depends: ${cross-essential}, ${misc:Depends}
@@ -164,6 +221,44 @@
  to build-depend on, you can always leave out the packages this
  package depends on.
 
+Package: crossbuild-essential-powerpcspe
+Architecture: all
+Depends: ${cross-essential}, ${misc:Depends}
+Description: Informational list of cross-build-essential packages
+ If you do not plan to cross build Debian packages, you don't need
+ this package.  Starting with sbuild (>= 0.63.0) this package is
+ required for cross building Debian packages in a chroot.
+ .
+ This package contains an 

Bug#882365: osspd FTCBFS: uses the build architecture pkg-config

[Ralf Jung]

Hi,

> On Sun, Dec 03, 2017 at 07:36:22PM +0100, Ralf Jung wrote:
>> I don't have the environment to test those.  Please let me know if this
>> looks like it should be working.
> 
> How do you build packages?

gbp buildpackage --git-builder=sbuild

> Most people I know use either sbuild or
> pbuilder. If you do, you do have the environment. For sbuild[1] it is
> `--host=...' and for pbuilder it is `--host-arch=...'. No extra setup
> beyond the one for native builds required. If you are aware of any other
> builder that doesn't support cross building please tell.

Oh, I don't need to set up special sbuild chroots for the each target
architecture?  Wow, I had no idea.  (I was also briefly confused by
terminology, but it seems "host" here is what I have seen called
"target" elsewhere.)

However, this fails: gbp buildpackage --git-builder=sbuild --dist
unstable --host i386 --add-depends=libc-dev,libstdc++-dev

I pasted the log below.

Kind regards,
Ralf

> gbp:info: Exporting 'HEAD' to '/home/r/src/debian/osspd/build-area/osspd-tmp'
> gbp:info: Moving '/home/r/src/debian/osspd/build-area/osspd-tmp' to 
> '/home/r/src/debian/osspd/build-area/osspd-1.3.2'
> dh clean --parallel --with=systemd
>dh_auto_clean -O--parallel
>   make -j5 clean
> make[1]: Entering directory '/home/r/src/debian/osspd/build-area/osspd-1.3.2'
> Package fuse was not found in the pkg-config search path.
> Perhaps you should add the directory containing `fuse.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'fuse' found
> Package fuse was not found in the pkg-config search path.
> Perhaps you should add the directory containing `fuse.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'fuse' found
> Package libpulse was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libpulse.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libpulse' found
> Package libpulse was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libpulse.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libpulse' found
> Package alsa was not found in the pkg-config search path.
> Perhaps you should add the directory containing `alsa.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'alsa' found
> Package alsa was not found in the pkg-config search path.
> Perhaps you should add the directory containing `alsa.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'alsa' found
> rm -f *.o *.a osspd ossp-padsp ossp-alsap osstest
> make[1]: Leaving directory '/home/r/src/debian/osspd/build-area/osspd-1.3.2'
>dh_clean -O--parallel
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: applying 
> 0001-Fix-compilation-with-Werror-format-security.patch
> dpkg-source: info: applying 0002-honor-CPPFLAGS.patch
> dpkg-source: info: applying 
> 0003-PA-recommends-users-not-to-be-in-the-audio-group-so-.patch
> dpkg-source: info: applying 
> 0004-Allow-to-set-slave-installation-path-during-compilat.patch
> dpkg-source: info: applying 0005-Add-pthread-compiler-and-linker-flag.patch
> dpkg-source: info: applying 0006-cross.patch
> dpkg-source: info: building osspd using existing ./osspd_1.3.2.orig.tar.gz
> dpkg-source: info: building osspd in osspd_1.3.2-9.debian.tar.xz
> dpkg-source: info: building osspd in osspd_1.3.2-9.dsc
> sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on r-thinktop
> 
> +==+
> | osspd 1.3.2-9 (i386) Sun, 03 Dec 2017 21:08:39 
> + |
> +==+
> 
> Package: osspd
> Version: 1.3.2-9
> Source Version: 1.3.2-9
> Distribution: unstable
> Machine Architecture: amd64
> Host Architecture: i386
> Build Architecture: amd64
> Build Type: full
> 
> I: NOTICE: Log filtering will replace 
> 'var/run/schroot/mount/unstable-amd64-sbuild-96eb71fd-f170-4d78-b615-70adab12e7a3'
>  with '<>'
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> Hit:1 http://cdn-fastly.deb.debian.org/debian unstable InRelease
> Get:2 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 
> [7799 kB]
> Fetched 7799 kB in 12s (616 kB/s)
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Local sources
> -
> 
> 

Bug#844939: Yup, fixed.

[Chris West]

Control: tags -1 + fixed-upstream

Mark has kindly fixed the bug upstream, and the package now builds
correctly (after adding locales-all). My repo[1] now builds successfully
inside gbp with pbuilder.

I've also bumped the standards version, as I believe it only requires a
trivial change.

1: https://github.com/FauxFaux/git-remote-hg

Bug#883423: Same with avx512vbmi2vlintrin.h

[Sylvestre Ledru]

avx512vbmi2vlintrin.h

Bug#883423: gcc-8: avx512vbmi2intrin.h is missing

[Sylvestre Ledru]

Source: gcc-8
Severity: important


Hello

Just like list time:
41:18.80 /usr/lib/gcc/x86_64-linux-gnu/8/include/immintrin.h:77:10: fatal 
error: avx512vbmi2intrin.h: No such file or directory
41:18.80  #include 
41:18.80   ^
41:18.80 compilation terminated.

Cheers,
S

Bug#883422: debian.vim: maparg() invalid argument

[Sergey Vlasov]

Package: vim-common
Version: 2:8.0.0197-4+deb9u1
Severity: important

After upgrade to Stretch my  mapping in .vimrc stopped working.
In debian.vim there is a check for existing  mapping using maparg()
function. The second argument to this function is invalid. According to vim
documentation, {mode} argument can be either a single character string or an
empty string. Instead, a string with several characters is used, but the check
happens always against the first character only. Finally, as a result,
some existing mappings may become overridden.

Here is a proposed fix:

--- /usr/share/vim/vim80/debian.vim-orig2017-12-03 22:29:53.939533583 +0200
+++ /usr/share/vim/vim80/debian.vim2017-12-03 22:34:17.520734735 +0200
@@ -26,12 +26,21 @@ if  =~ "xterm-debian" ||  =~ "
   set t_Sb= [4%dm
 endif

+function! MapExists(name, modes)
+  for mode in split(a:modes, '\zs')
+if !empty(maparg(a:name, mode))
+  return 1
+endif
+  endfor
+  return 0
+endfunction
+
 " Some Debian-specific things
 if has("autocmd")
   if has('gui')
 " Make shift-insert work like in Xterm
-autocmd GUIEnter * if empty(maparg("", "nvso")) |
execute "map  " | endif
-autocmd GUIEnter * if empty(maparg("", "ic")) | execute
"map!  " | endif
+autocmd GUIEnter * if !MapExists("", "nvso") |
execute "map  " | endif
+autocmd GUIEnter * if !MapExists("", "ic") |
execute "map!  " | endif
   endif
 endif


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (1000, 'stable'), (900, 'stable'), (750, 'testing'),
(500, 'stable-updates'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages vim-common depends on:
ii  xxd  2:8.0.0197-4+deb9u1

Versions of packages vim-common recommends:
ii  vim-gtk [vim]  2:8.0.0197-4+deb9u1
ii  vim-tiny   2:8.0.0197-4+deb9u1

vim-common suggests no packages.

-- no debconf information

Bug#882365: osspd FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

On Sun, Dec 03, 2017 at 07:36:22PM +0100, Ralf Jung wrote:
> I don't have the environment to test those.  Please let me know if this
> looks like it should be working.

How do you build packages? Most people I know use either sbuild or
pbuilder. If you do, you do have the environment. For sbuild[1] it is
`--host=...' and for pbuilder it is `--host-arch=...'. No extra setup
beyond the one for native builds required. If you are aware of any other
builder that doesn't support cross building please tell.

Helmut

[1] sbuild does not work around #815172, so you may have to also pass
--add-depends=libc-dev,libstdc++-dev to get a working build.

Bug#881339: poor yarn

[Don Armstrong]

On Sat, 02 Dec 2017, Paolo Greppi wrote:
> @don: yarn is a javascript package manager like npm which we already have in 
> debian, as we have pip, gem, composer, go get etc.
>
> Both yarn and npm are probably not useful during packaging, but they
> happen to be popular tools among front-end developers at the moment,
> that's why I filed the ITP for yarn. And that's also why people keep
> asking for a more recent npm in debian ...

Sorry, I realize now that my message was unclear.

I meant that yarn and lerna shouldn't be necessary to bootstrap babel,
because the dependencies should be satisfied at bootstrap time.

-- 
Don Armstrong  https://www.donarmstrong.com

"She decided what she wished to happen and then assumed that reality
would bend to her wishes." [...] "Reality doesn't indulge wishes."
 -- Terry Goodkind _Phantom_ p133

Bug#883421: RFS: mwc/2.0.4-2 [RC]

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: important


  Dear mentors,

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

   Package name: mwc
   Version : 2.0.4-2
   Upstream Author : Michael Till Beck 
   URL : https://github.com/Debianguru/MailWebsiteChanges
   License : GPL-2+
   Section : utils

  It builds those binary packages:

mwc   - Powerful website-tracking tool

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/m/mwc/mwc_2.0.4-2.dsc


  Changes since the last upload:

  * debian/mwc.install:
- Install mwctools.py to /usr/share/mwc (Closes: #877924).
  * New debian/NEWS.Debian about the new config file syntax.
  * New debian/patches/0001-config.patch:
- Add loading config from every path (Closes: #877927).
  * Change to my new email-address:
- debian/control,
- debian/copyright.
  * Remove trailing white spaces:
- debian/changelog
- debian/control
  * Declare compliance with Debian Policy 4.1.2.0 (No changes needed).



  Regards,
   Jörg Frings-Fürst


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

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

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

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

IRC: j_...@freenode.net
 j_...@oftc.net

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

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlokYO8ACgkQCfifPIyh
0l3lnQ/6A3kf+p/dSFfMky1vZ0GpDsS+JOPHwv4JwzozyYKTj8RuU1CZSOZhZ2ND
mcFo4mxtlHWUqFK3D3xqm3DZcHXba6Cnotc3alAfKbLeGxaAvdYwLGrt5gZbjOql
g9ZP+Tabl91B3ALvYXMtBqT9rUWNxrsVpKb/b8pkgfr6gzv5rRgqRs4yulgRPNvn
XXGBXpDpD3Rv26mAYwZby2LI42sFqXCaLi0wXApaWg7YUbjAzzfTVGEWQpChGl2b
roq60X/f6lXGqtQoOQvOindYOlldD9Cjb3iCZXyxnSbpivxhlM1k8CNAsxCw65zC
4rNQkPCyBQRoxye6sKxolpI7ms5wKJGt57gmhS4N7YiSTDcaJAK9t/kWiRkOLIGW
ZvYWZrQh/5EHQJpwVs5snehZuImWATxQQNjPm30vLU9Y9EoI4G4rAFmB1EoBR7/W
YKis3Bcvv6xzmIRzTed91mx4ToPj6I+Qe+pqEa8Qafs+avByXrsKhoNiGV9bLMFX
XU3SRT3HJJfLKXvM71vDttN6+xqBzbUv+5TrNXFdgokWEB3lvKd68u54IRwSHlyh
9CUMT1UBko+Dib3QEC+LtQytLeVIpvI87+hkhHr8LRQg1EI1aVIdNMrxTiqQiJgG
zWffDJrh7gmefIAEZYlX3lcnrF5FBixeJhvdPQK0Y6dRyfcexK0=
=+TXI
-END PGP SIGNATURE-

Bug#883382: we would like tothankyou21572067

[Kathleen Deno]

Quit emailing this address you scamming idiots

On Dec 3, 2017 12:12 PM, "amazon finalNotice"  wrote:

Notice.for.you













































































































































































Your message dated Sun, 3 Dec 2017 18:22:41 + with message-id
<20171203182241.GO7960@cherubino> and subject line Re: Bug#883382: neomutt
defaults to SENDMAIL="false" has caused the Debian Bug report #883382,
regarding neomutt defaults to SENDMAIL="false" to be marked as done. This
means that you claim that the problem has been dealt with. If this is not
the case it is now your responsibility to reopen the Bug report if
necessary, and/or fix the problem forthwith. (NB: If you are a system
administrator and have no idea what this message is talking about, this may
indicate a serious mail system misconfiguration somewhere. Please contact
ow...@bugs.debian.org immediately.) -- 883382: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=883382 Debian Bug Tracking System Contact
ow...@bugs.debian.org with problems

-- Forwarded message --
From: Joerg Dorchain 
To: sub...@bugs.debian.org
Cc:
Bcc:
Date: Sun, 3 Dec 2017 11:56:08 +0100
Subject: neomutt defaults to SENDMAIL="false"
Package: neomutt
Version: 20171027+dfsg.1-1

neomutt is compiled with SENDMAIL="false" (output from neomutt -v)

This effectivley disables sendmail mail.

Please compile with SENDMAIL="/usr/sbin/sendmail", as the mutt
package is.

Bye,

Joerg



-- Forwarded message --
From: Antonio Radici 
To: Joerg Dorchain , 883382-d...@bugs.debian.org
Cc:
Bcc:
Date: Sun, 3 Dec 2017 18:22:41 +
Subject: Re: Bug#883382: neomutt defaults to SENDMAIL="false"
fixed -1 20171027+dfsg.1-4
thanks

On Sun, Dec 03, 2017 at 11:56:08AM +0100, Joerg Dorchain wrote:
> Package: neomutt
> Version: 20171027+dfsg.1-1
>
> neomutt is compiled with SENDMAIL="false" (output from neomutt -v)
>
> This effectivley disables sendmail mail.
>
> Please compile with SENDMAIL="/usr/sbin/sendmail", as the mutt
> package is.
>

Hi Joerg,
this is fixed in the latest upload.

Bug#883420: gnome-power-manager: Fills log with not authorized messages

[Thomas Renard]

Package: gnome-power-manager
Version: 3.25.90-1
Severity: normal

Dear Maintainer,

on a running gnome session /var/log/messages is continuous filled with

Dec  3 21:05:22 myhost org.gnome.SettingsDaemon.Power.desktop[8465]: Error 
executing command as another user: Not authorized
Dec  3 21:05:22 myhost org.gnome.SettingsDaemon.Power.desktop[8465]: This 
incident has been reported.

ps axu shows:

myuser8321  0.3  0.2 512592 23076 tty2 Sl+  21:04   0:00 
/usr/lib/gnome-settings-daemon/gsd-power
Debian-+  8465  0.3  0.2 512472 22928 tty1 Sl+  21:05   0:00 
/usr/lib/gnome-settings-daemon/gsd-power

(I expect it is Debian-gdm)

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

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

Versions of packages gnome-power-manager depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-1
ii  gnome-settings-daemon 3.26.2-1
ii  libc6 2.25-2
ii  libcairo2 1.15.8-2
ii  libglib2.0-0  2.54.1-1
ii  libgtk-3-03.22.24-3
ii  libpango-1.0-01.40.12-1
ii  libpangocairo-1.0-0   1.40.12-1
ii  libupower-glib3   0.99.6-1
ii  upower0.99.6-1

gnome-power-manager recommends no packages.

gnome-power-manager suggests no packages.

-- no debconf information

Bug#883363: linux-compiler-gcc-7-x86: incorrect GCC version number in package description

[Ben Hutchings]

On Sun, 2017-12-03 at 19:49 +, Ben Hutchings wrote:
> On Sun, 2017-12-03 at 09:34 +0800, Paul Wise wrote:
> > Package: linux-compiler-gcc-7-x86
> > Version: 4.14.2-1
> > Severity: minor
> > 
> > The linux-compiler-gcc-7-x86 package depends on GCC 7 but
> > declares in the description that it depends on GCC 6:
> > 
> > Package: linux-compiler-gcc-7-x86
> > Depends: gcc-7
> > Description: Compiler for Linux on x86 (meta-package)
> >  This package depends on gcc 6 of the appropriate architecture for Linux on
> >  amd64, i386 and x32.
> > 
> > I suggest changing the information to something like this:
> > 
> > Package: linux-compiler-gcc-x86
> > Depends: gcc-7
> > Description: Compiler for Linux on x86 (meta-package)
> >  This package depends on GCC of the appropriate version and architecture
> >  for Linux on amd64, i386 and x32.
> 
> [...]
> 
> Thanks, this seems like a good idea.

Ah, but not the name change.  The purpose of linux-compiler-* packages
is allow linux-headers-* packages to indirectly depend on a suitable
compiler, which can belong to one of several Debian architectures.  The
major version of gcc needs to match that used to build the kernel.

If we took take compiler version out of the package names, the
dependencies on them will need to be versioned.  But we shouldn't use
exact version dependencies for that because they're cross-architecture.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#882975: android-tools FTBFS with glibc 2.25

[Juhani Numminen]

Control: tags -1 patch

On Tue, 28 Nov 2017 11:05:03 +0200 Adrian Bunk  wrote:> 
/build/1st/android-tools-5.1.1.r38/system/core/adb/usb_linux_client.c:38:25: 
error: initializer element is not constant

 #define cpu_to_le32(x)  htole32(x)
 ^


There is a patch that makes the package build again. It can be applied 
to the current debian package.

http://cgit.openembedded.org/meta-openembedded/plain/meta-oe/recipes-devtools/android-tools/android-tools/fix-big-endian-build.patch

BTW, I noticed upstream git master doesn't contain the file 
adb/usb_linux_client.c anymore.

https://android.googlesource.com/platform/system/core/+/master/adb

Cheers,
Juhani

Bug#883357: Pending fixes for bugs in the undertow package

[pkg-java-maintainers]

tag 883357 + pending
thanks

Some bugs in the undertow package are closed in revision
640ce0c584b1c1cd22f9f742ad59395a420faac7 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/undertow.git/commit/?id=640ce0c

Commit message:

Add websockets-jsr.patch and implement a yet unsupported new method

introduced by the recent update of libtomcat8-java to version 8.5.24.

Closes: #883357
Thanks: Adrian Bunk for the report.

Bug#870721: chromium-l10n: datetime-local input fields

[Michael Gilbert]

control: tag -1 upstream

> The datetime-local[0] html input fields use full (i.e. segunda) instead
> of abbreviated (i.e. seg) weekday names in the pt-PT translation.

This is an upstream issue, please submit a bug there and link to it here.

You could also try debugging it yourself, webkit's datatimelocal
implementation is at:
third_party/WebKit/Source/core/html/forms/DateTimeLocalInputType.h.

Best wishes,
Mike

Bug#883363: linux-compiler-gcc-7-x86: incorrect GCC version number in package description

[Ben Hutchings]

On Sun, 2017-12-03 at 09:34 +0800, Paul Wise wrote:
> Package: linux-compiler-gcc-7-x86
> Version: 4.14.2-1
> Severity: minor
> 
> The linux-compiler-gcc-7-x86 package depends on GCC 7 but
> declares in the description that it depends on GCC 6:
>
> Package: linux-compiler-gcc-7-x86
> Depends: gcc-7
> Description: Compiler for Linux on x86 (meta-package)
>  This package depends on gcc 6 of the appropriate architecture for Linux on
>  amd64, i386 and x32.
> 
> I suggest changing the information to something like this:
> 
> Package: linux-compiler-gcc-x86
> Depends: gcc-7
> Description: Compiler for Linux on x86 (meta-package)
>  This package depends on GCC of the appropriate version and architecture
>  for Linux on amd64, i386 and x32.
[...]

Thanks, this seems like a good idea.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#883419: python3-requests: RequestsDependencyWarning urllib3 (1.21.1) or chardet (2.3.0) doesn't match a supported version

[xiscu]

Package: python3-requests
Version: 2.12.4-1
Severity: important

Dear Maintainer,
importing requests on python3 raises a dependency warning:

$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
/home/ci/.local/lib/python3.5/site-packages/requests/__init__.py:80: 
RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.3.0) doesn't match a 
supported version!
  RequestsDependencyWarning)

Is it possible to update urllib3 at least to version 1.21.1 as recomended ?

Thanks in advance!
xiscu


-- System Information:
Debian Release: 9.1
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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-requests depends on:
ii  ca-certificates  20161130+nmu1
ii  python3  3.5.3-1
ii  python3-chardet  2.3.0-2
ii  python3-urllib3  1.19.1-1

python3-requests recommends no packages.

Versions of packages python3-requests suggests:
pn  python3-cryptography  
pn  python3-idna  
pn  python3-openssl   
pn  python3-socks 

-- no debconf information

Bug#883418: dolibarr: EDM module does not work because of jQuery version

[pitchum]

Package: dolibarr
Version: 4.0.2+dfsg4-2
Severity: important
Tags: patch

After upgrading from to stretch, module EDM does not work anymore.
Firefox's webconsole prints this:
'TypeError: v.selector is undefined (jquery.layout.min.js:123:157)'

After investigation it appears that this problem is Debian specific.
Dolibarr from upstream includes jquery v1.12 while Debian's package
provides jquery v.3.1 from package libjs-jquery and unfortunately
EDM uses a jquery plugin (UI Layout) which was not updated to be
compatible with jquery v3.

The problem is already known:
https://github.com/allpro/layout/issues/10
https://github.com/allpro/layout/issues/17

I attach a simple patch for the Debian package using the
workaround proposed in issue 17.

-- 
pitchum
Index: b/htdocs/main.inc.php
===
--- a/htdocs/main.inc.php
+++ b/htdocs/main.inc.php
@@ -1145,6 +1145,7 @@ function top_htmlhead($head, $title='',
 // jQuery Layout (still used by ECM module)
 if (defined('REQUIRE_JQUERY_LAYOUT'))
 {
+print '(function ($){$.fn.selector = { split: function() { return ""; }};})(jQuery);\n';
 print ''."\n";
 }
 // jQuery jnotify

Bug#795675: Version 0.4.3 is out!

[Alexander Galanin]

https://bitbucket.org/agalanin/fuse-zip/downloads/fuse-zip-0.4.3.tar.gz

Change log:

* Released 0.4.3:
- License changed to GPLv3 or later because LGPLv3 is too confusing.
- Support mknod() system call.
- Fixed out of bounds write on sparse file (issue #50).
- Fixed timestamp and file attribute fields saving into archive.

* Released 0.4.2:
- Properly handle ZIP_SOURCE_SUPPORTS call introduced in libzip 1.0
(fixes #46)

* Released 0.4.1:
- Fixed problem with subdir module support.
- Applied makefile conventions from GNU Coding Standards.

-- 
Alexander Galanin

Bug#876404: Pending fixes for bugs in the golang-github-go-ldap-ldap package

[pkg-go-maintainers]

tag 876404 + pending
thanks

Some bugs in the golang-github-go-ldap-ldap package are closed in
revision e357b3fd4067f7b070a2031bdf9d3ae91ca00278 in branch ' 
stretch' by Dr. Tobias Quathamer

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-go-ldap-ldap.git/commit/?id=e357b3f

Commit message:

Require explicit intention for empty password.

This is normally used for unauthenticated bind, and
https://tools.ietf.org/html/rfc4513#section-5.1.2 recommends:

> Clients SHOULD disallow an empty password input to a Name/Password
> Authentication user interface

This is (mostly) a cherry-pick of 95ede12 from upstream. I've removed
the bit in ldap_test.go, which is unrelated to the security issue.

This fixes CVE-2017-14623.


https://github.com/go-ldap/ldap/commit/95ede1266b237bf8e9aa5dce0b3250e51bfefe66

Closes: #876404

Bug#883375: qtbase-opensource-src: Please add private headers in /src/plugins/platforms/xcb/

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 wontfix

El 3 dic. 2017 6:21 a.m., "Pino Toscano"  escribió:

> My question is, is it possible for us to include (copy) those header
files and
> distribute them inside package "qtbase5-private-dev" so that package
> "qt5dxcb-plugin" could build-dep on qtbase5-private-dev instead of
bundling
> them inside repository (like what Fedora did)?

[Snip Pino's reply]


No, it's not possible. As Pino said it's already a big headache to have to
ship official private headers. Adding even more would require us even more
work to properly track them. So the answer is no.


It ought to really work with what Qt ships, not trying to outsmart Qt
this way.  Why does qt5dxcb-plugin need these headers?  If it really
needs them (IMHO it should just use what Qt provides, even as private
headers), did you ask upstream Qt to provide them or the equivalent API
for what qt5dxcb-plugin wants to do?


Right, if you really need then then work with upstream to make it public
API, or at least official private one.

Please note that we will not add private headers to other qt submodules
except we the Debian Qt/KDE team really need them.

Bug#882365: osspd FTCBFS: uses the build architecture pkg-config

[Ralf Jung]

Hi Helmut,

thanks a lot for this patch!  I have added it to the development version
of the package, which you can find at .
I plan to do a new upload soon.  Upstream is pretty dead, so there is
little point in forwarding the patch there.

Your patch is at
.
 I build-tested this locally, but of course that's not a cross-build --
I don't have the environment to test those.  Please let me know if this
looks like it should be working.

Kind regards,
Ralf


On 21.11.2017 21:20, Helmut Grohne wrote:
> Source: osspd
> Version: 1.3.2-8
> Tags: patch upstream
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> osspd fails to cross build from source, because it uses the build
> architecture pkg-config (hard coded in Makefile) and thus fails finding
> required libraries, which are only requested for the host architecture
> by its Build-Depends. The correct solution is to use the host
> architecture pkg-config, which is correctly passed by dh_auto_build, but
> ignored by the Makefile. After making pkg-config substitutable, osspd
> cross builds successfully. Please consider applying the attached patch.
> 
> Helmut
> 

Bug#882225: inn2: wrong hardcoded gzip path breaks scanlogs and UUCP feed

[Marco d'Itri]

On Dec 03, Richard Kettlewell  wrote:

> Is this going to be fixed in stretch too?
Yes: see #882391 for details.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#883417: phpmyadmin FTBFS with phpunit 6.4.4-2

[Adrian Bunk]

Source: phpmyadmin
Version: 4:4.6.6-5
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/phpmyadmin.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/phpmyadmin-4.6.6'
# We exclude:
# - selenium tests as the setup would be too complex
# - some network based tests
LC_ALL=en_US.UTF-8 phpunit --config phpunit.xml.nocoverage --exclude-group 
selenium --exclude-group network
No headers testing.
Please install runkit and enable runkit.internal_override!
PHP Fatal error:  Class 'PHPUnit_Framework_TestCase' not found in 
/build/1st/phpmyadmin-4.6.6/test/PMATestCase.php on line 14
debian/rules:11: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 255

Bug#882801: chromium: segfaults like crazy

[Alberto Bertogli]

Just FYI, I'm also seeing this.

On an up to date Debian testing, same version (62.0.3202.89-1).

I can reproduce it on a fresh profile, and also incognito is affected,
so it's completely unusable.
-g makes no difference in my case (also crashes).


If I "rm -r ~/.config/chromium" and then run "chromium --incognito", it
opens and runs for about 4m of light use (browsing simple websites in
two tabs, for example) before crashing.  Subsequent runs crash right
after launching.

This seems to be 100% reproducible here.


Traceback obtained with gdb:

Thread 1 "chromium" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt  
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fffec49319a in __GI_abort () at abort.c:89
#2  0x5754ebc5 in base::debug::BreakDebugger() ()
#3  0x57568835 in logging::LogMessage::~LogMessage() ()
#4  0x567a75be in 
content::RenderProcessHostImpl::GetProcessHostForSiteInstance(content::BrowserContext*,
 content::SiteInstanceImpl*) ()
#5  0x56836fe7 in content::SiteInstanceImpl::GetProcess() ()
#6  0x5685fb5e in 
content::WebContentsImpl::Init(content::WebContents::CreateParams const&) ()
#7  0x5685d5d6 in 
content::WebContentsImpl::CreateWithOpener(content::WebContents::CreateParams 
const&, content::FrameTreeNode*) ()
#8  0x587a6cac in chrome::Navigate(chrome::NavigateParams*) ()
#9  0x587b437d in 
StartupBrowserCreatorImpl::OpenTabsInBrowser(Browser*, bool, 
std::vector const&) ()
#10 0x587b5df9 in 
StartupBrowserCreatorImpl::RestoreOrCreateBrowser(std::vector const&, StartupBrowserCreatorImpl::BrowserOpe
nBehavior, unsigned int, bool, bool) ()
#11 0x587b64b1 in 
StartupBrowserCreatorImpl::ProcessLaunchUrlsUsingConsolidatedFlow(bool, 
std::vector const&) ()
#12 0x587b66d8 in StartupBrowserCreatorImpl::Launch(Profile*, 
std::vector const&, bool) ()
#13 0x587b2c7d in 
StartupBrowserCreator::LaunchBrowser(base::CommandLine const&, Profile*, 
base::FilePath const&, chrome::startup::IsProcessStartup, chrome::startup::
IsFirstRun) ()
#14 0x587b37b8 in 
StartupBrowserCreator::ProcessCmdLineImpl(base::CommandLine const&, 
base::FilePath const&, bool, Profile*, std::vector const&) ()
#15 0x587b3aba in StartupBrowserCreator::Start(base::CommandLine 
const&, base::FilePath const&, Profile*, std::vector > const&) ()
#16 0x57484e61 in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() ()
#17 0x57485160 in ChromeBrowserMainParts::PreMainMessageLoopRun() ()
#18 0x5659f8f4 in content::BrowserMainLoop::PreMainMessageLoopRun() ()  

#19 0x5683dfba in content::StartupTaskRunner::RunAllTasksNow() ()   
   
#20 0x565a26f6 in content::BrowserMainLoop::CreateStartupTasks() ()
#21 0x565a42ab in 
content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) 
()
#22 0x5659f05f in content::BrowserMain(content::MainFunctionParams 
const&) ()
#23 0x572e9e0b in content::ContentMainRunnerImpl::Run() ()
#24 0x572f1210 in service_manager::Main(service_manager::MainParams 
const&) ()
#25 0x572e9514 in content::ContentMain(content::ContentMainParams 
const&) ()
#26 0x5613512c in ChromeMain ()
#27 0x7fffec47e561 in __libc_start_main (main=0x561241ef , 
argc=9, argv=0x7fffdeb8, init=, fini=, 
rtld_fini=,
stack_end=0x7fffdea8) at ../csu/libc-start.c:297
   
#28 0x56134fba in _start () 
   


I hope this helps!

Thanks!
Alberto

Bug#883411: gtk2-engines-murrine: Don't depend on gtk2

[Yves-Alexis Perez]

On Sun, 2017-12-03 at 13:11 -0500, Jeremy Bicha wrote:
> There are other packages that excludes dependencies from dh_shlibdeps:
> https://codesearch.debian.net/search?q=path%3Adebian%2Frules+dh_shlibdeps.*-x
> https://codesearch.debian.net/search?q=path%3Adebian%2Frules+dh_shlibdeps.*--exclude
> https://codesearch.debian.net/search?q=path%3Adebian%2Frules+DEB_DH_MAKESHLIBS_ARG.*--exclude=1
> 
> I don't think Debian Policy forbids my proposal.

Depending on a library package is a policy should. While it's not explicitly
forbidden, it's still really not advised.


> Could you explain how my proposal would break anything?

You made yourself clear on why you want to do that in Ubuntu. I don't consider
the reason valid enough in Debian, and again I don't like it. So please do
whatever you want in Ubuntu, that's all.

Also, I don't really want to spend more time on this.

Regards,
-- 
Yves-Alexis

Bug#883416: Updated Russian translation

[Sergey Alyoshin]

Package: ejabberd
Version: 17.11-1
Priority: wishlist
Tags: l10n patch


ru.po.gz
Description: GNU Zip compressed data

Bug#882181: mockito: FTBFS - java.lang.UnsupportedOperationException: Cannot nest operations in the same thread

[Markus Koschany]

Control: reassign -1 src:gradle
Control: found -1 3.2.1-5
Control: fixed -1 3.4.1-2

Hi,

I'm going to reassign this bug to gradle because the issue is really in
gradle 3.2.1. It is fixed in 3.4.1-2 in experimental. Mockito will build
from source again as soon as gradle 3.4.1 is uploaded to unstable and
another revision of Mockito is uploaded as well that addresses another
issue with testng. The changes were already pushed to the Git repository.

Currently the failing bnd package is the only blocking bug for uploading
gradle 3.4.1 to unstable. It would be nice if we could fix this without
having to package the latest upstream release of bnd because this will
most likely create other issues for us and needlessly delay the fix for
this bug.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#883411: gtk2-engines-murrine: Don't depend on gtk2

[Jeremy Bicha]

On Sun, Dec 3, 2017 at 12:56 PM, Yves-Alexis Perez  wrote:
> I have to admit I really don't like this approach. Also, it's looks like a
> policy break, unless it's somehow agreed accross Debian that gtk engines are
> not standard packages and shouldn't obey their shlibsdeps, I don't think it we
> should do that.

There are other packages that excludes dependencies from dh_shlibdeps:
https://codesearch.debian.net/search?q=path%3Adebian%2Frules+dh_shlibdeps.*-x
https://codesearch.debian.net/search?q=path%3Adebian%2Frules+dh_shlibdeps.*--exclude
https://codesearch.debian.net/search?q=path%3Adebian%2Frules+DEB_DH_MAKESHLIBS_ARG.*--exclude=1

I don't think Debian Policy forbids my proposal.

Could you explain how my proposal would break anything?

Thanks,
Jeremy Bicha

Bug#883387: libjaxb-java 2.3.0-3 causes FTBFS in eclipselink

[Markus Koschany]

Am 03.12.2017 um 13:29 schrieb Adrian Bunk:
> Package: libjaxb-java
> Version: 2.3.0-3
> Severity: serious
> Control: affects -1 src:eclipselink

Hi,

Thanks for reporting. I had a look at this but I can't find the mistake
in libjaxb-java. The difference between 2.3.0-2 and 2.3.0-3 is that we
use absolute classpaths now and this works for Netbeans for example. [1]
I can't see that I made a typo somewhere. So my guess is something
curious is going on with eclipselink's build system. When I add the
necessary dependencies to debian/classpath-debian it works again but it
really should not make any difference in this case whether the classpath
for usr/share/java/jaxb-xjc.jar uses relative or absolute paths.

It would be nice if someone else had a look at this because I might have
overlooked something but it doesn't look like a bug in libjaxb-java.

Markus

[1]
https://anonscm.debian.org/cgit/pkg-java/jaxb.git/commit/?id=0c76b6c3fd1430f4fdc07d13af1a42a593a2319d



signature.asc
Description: OpenPGP digital signature

Bug#883412: zareena.your.recent.order.87827680

[Zareena Ali]

Please can you send i.  this address
1623 E :Street
HAYWARD CA 94541

On Dec 3, 2017 9:42 AM, "Amazon FinalNotice"  wrote:

> Welcome.to.AmazonSurvey
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: wnpp Severity: wishlist Owner: Simon Quigley * Package name :
> qtnetworkauth-opensource-src Version : 5.9.3 Upstream Author : The Qt
> Company Ltd. * URL : http://www.example.org/ * License : (GPL, LGPL, BSD,
> MIT/X, etc.) Programming Lang: C++ Description : Network Authenticator
> module for Qt Qt Network Authorization provides a set of APIs that enable
> Qt applications to obtain limited access to online accounts and HTTP
> services without exposing users' passwords. . Currently, the supported
> authorization protocol is OAuth, versions 1 and 2. I plan on maintaining
> this under the Debian Qt/KDE Maintainers umbrella; we need it for some
> newer KDE applications. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on
> freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4

Bug#883411: gtk2-engines-murrine: Don't depend on gtk2

[Yves-Alexis Perez]

control: tag -1 wontfix

On Sun, 2017-12-03 at 11:44 -0500, Jeremy Bicha wrote:
> So while my proposal seems a bit unusual, I believe it is the best solution.
> 
> Other Info
> -
> I told you earlier that Michael Biebl objected to my proposal. He has
> since withdrawn his objection, and I am implementing this proposal in
> other packages.

I have to admit I really don't like this approach. Also, it's looks like a
policy break, unless it's somehow agreed accross Debian that gtk engines are
not standard packages and shouldn't obey their shlibsdeps, I don't think it we
should do that.

Tagging wontfix to add this opinion to the bug meta-data.

Regards,
-- 
Yves-Alexis

Bug#883412: Info received (NELLIE.your.recent.order.682157153)

[Nellie Smith]

STOP WITH THE EMAILS

On Dec 3, 2017 11:45 AM, "Debian Bug Tracking System" 
wrote:

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

Bug#883394: logs

[Henrique de Moraes Holschuh]

Now attached for real... sorry about this.

-- 
  Henrique Holschuh
Aptitude 0.8.7: log report
Sun, Dec  3 2017 05:03:16 -0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 17 packages, and remove 0 packages.
13.3 kB of disk space will be used

[HOLD] linux-doc-4.9:amd64 4.9.30-2+deb9u2
[HOLD] linux-manual-4.9:amd64 4.9.30-2+deb9u2
[UPGRADE] glibc-doc:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] kde-config-gtk-style:amd64 4:5.8.6-1 -> 4:5.8.6-1+deb9u1
[UPGRADE] libapparmor1:amd64 2.11.0-3 -> 2.11.0-3+deb9u1
[UPGRADE] libc-bin:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc-dev-bin:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc-l10n:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6:i386 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-dbg:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-dev:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-dev-i386:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-dev-x32:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-i386:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-i686:i386 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] libc6-x32:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] locales:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2
[UPGRADE] multiarch-support:amd64 2.24-11+deb9u1 -> 2.24-11+deb9u2

2017-12-03 05:03:41 startup archives unpack
2017-12-03 05:03:42 upgrade libc6-i386:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:42 status triggers-pending libc-bin:amd64 2.24-11+deb9u1
2017-12-03 05:03:42 status half-configured libc6-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:42 status unpacked libc6-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:42 status half-installed libc6-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:44 status half-installed libc6-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:46 status unpacked libc6-i386:amd64 2.24-11+deb9u2
2017-12-03 05:03:47 status unpacked libc6-i386:amd64 2.24-11+deb9u2
2017-12-03 05:03:47 upgrade libc-dev-bin:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:47 status half-configured libc-dev-bin:amd64 2.24-11+deb9u1
2017-12-03 05:03:47 status unpacked libc-dev-bin:amd64 2.24-11+deb9u1
2017-12-03 05:03:47 status half-installed libc-dev-bin:amd64 2.24-11+deb9u1
2017-12-03 05:03:47 status triggers-pending man-db:amd64 2.7.6.1-2
2017-12-03 05:03:47 status half-installed libc-dev-bin:amd64 2.24-11+deb9u1
2017-12-03 05:03:48 status unpacked libc-dev-bin:amd64 2.24-11+deb9u2
2017-12-03 05:03:48 status unpacked libc-dev-bin:amd64 2.24-11+deb9u2
2017-12-03 05:03:48 upgrade libc6-dev:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:48 status half-configured libc6-dev:amd64 2.24-11+deb9u1
2017-12-03 05:03:48 status unpacked libc6-dev:amd64 2.24-11+deb9u1
2017-12-03 05:03:48 status half-installed libc6-dev:amd64 2.24-11+deb9u1
2017-12-03 05:03:50 status half-installed libc6-dev:amd64 2.24-11+deb9u1
2017-12-03 05:03:52 status unpacked libc6-dev:amd64 2.24-11+deb9u2
2017-12-03 05:03:52 status unpacked libc6-dev:amd64 2.24-11+deb9u2
2017-12-03 05:03:52 upgrade libc6-dev-i386:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:52 status half-configured libc6-dev-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:52 status unpacked libc6-dev-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:52 status half-installed libc6-dev-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:52 status half-installed libc6-dev-i386:amd64 2.24-11+deb9u1
2017-12-03 05:03:52 status unpacked libc6-dev-i386:amd64 2.24-11+deb9u2
2017-12-03 05:03:52 status unpacked libc6-dev-i386:amd64 2.24-11+deb9u2
2017-12-03 05:03:55 upgrade libc6-dev-x32:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:55 status half-configured libc6-dev-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:55 status unpacked libc6-dev-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:55 status half-installed libc6-dev-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:56 status half-installed libc6-dev-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:56 status unpacked libc6-dev-x32:amd64 2.24-11+deb9u2
2017-12-03 05:03:56 status unpacked libc6-dev-x32:amd64 2.24-11+deb9u2
2017-12-03 05:03:56 upgrade libc6-x32:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:56 status half-configured libc6-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:56 status unpacked libc6-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:56 status half-installed libc6-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:57 status half-installed libc6-x32:amd64 2.24-11+deb9u1
2017-12-03 05:03:58 status unpacked libc6-x32:amd64 2.24-11+deb9u2
2017-12-03 05:03:58 status unpacked libc6-x32:amd64 2.24-11+deb9u2
2017-12-03 05:03:58 upgrade libc6-dbg:amd64 2.24-11+deb9u1 2.24-11+deb9u2
2017-12-03 05:03:58 status half-configured libc6-dbg:amd64 2.24-11+deb9u1
2017-12-03 05:03:58 status unpacked libc6-dbg:amd64 2.24-11+deb9u1
2017-12-03 05:03:58