Bug#913346: libsane1: Cannot update libsane1

[John Paul Adrian Glaubitz]

On 1/21/19 9:52 AM, Gianfranco Costamagna wrote:
>>If someone is using unstable, I expect them to be able to resolve
>>such issues themselves. unstable isn't a release, it's a development
>>version of Debian.
> 
> ehm, this bug hit testing too :/

No, it didn't. What makes you think so? The version of sane-backends with
the libsane1 package was never migrated to testing, see:

> https://packages.qa.debian.org/s/sane-backends.html

Quoting the testing migration mail:

> FYI: The status of the sane-backends source package
> in Debian's testing distribution has changed.

>  Previous version: 1.0.25-4.1
>  Current version:  1.0.27-3.1

Testing upgraded from 1.0.25-4.1 to 1.0.27-3.1, the rename happened
in 1.0.27-1~experimental1.

>>I don't understand why some users install unstable without understanding
>>the ramifications of using a development version of Debian.
> 
> I honestly never cared about unstable or even experimental, but testing is 
> something
> we should consider with our upgrade paths...

Yes, but testing is not affected. Again, what makes you think so?

If someone pulled the packages from experimental and installed them
into testing, I expect them to know and understand what they were
doing.

It's not Debian's job to support broken local configurations.

> Anyway, revised debdiff attached :)

Please don't. It was never part of testing so there are not kludges
required. And, again, unstable is not guaranteed to be stable, hence
the name.

If someone can point me to the point in the policy where it says that
upgrades and migrations in unstable need to be smooth and without
such issues, I am happy to revise my point of view.

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

Bug#919835: mgba; AppStream metadata isn't being used because of its license

[Markus Koschany]

Hello Jeremy,

Am 20.01.19 um 02:45 schrieb Jeremy Bicha:
> Source: mgba
> Version: 0.6.3+dfsg1-2
> X-Debbugs-CC: sergio_...@yahoo.com.br
> 
> The AppStream metadata that was added to the Debian package isn't
> being used because its metadata_license isn't on the short list of
> approved licenses.
> 
> I encourage you to consider relicensing your metadata as CC0-1.0. From
> what I can tell, CC0-1.0 is by far the most popular license for
> AppStream metadata.
> 
> The AppStream metadata for libretro-mgba isn't very useful for
> gnome-games-app without the .libretro file. It would be easier for me
> to help with some of these issues if these projects used
> https://salsa.debian.org . Please let me know if you would like my
> help.

[...]

I think the easiest way to solve this issue is to join the games team
and make your changes. That would reduce the differences between the
Debian and Ubuntu package and save time for everyone. I also think that
creating a Git repository on salsa.debian.org is fine and actually
should have been done much earlier.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier

[Robert Schindler]

Hello,

Samuel Thibault wrote:
> Thanks! Just to make sure, is this while Orca is running?

Yes, it is.

Best regards
Robert


signature.asc
Description: PGP signature

Bug#919990: stretch-pu: package chkrootkit/0.50-4+b2

[Moritz Schlarb]

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

As reported in #600109, /etc/cron.daily/chkrootkit contains a regular
expression to filter out dhclient3 and dhcpd3 as false positives from the
packet sniffer test. However, the binaries don't exist anymore, they have been
renamed to dhclient and dhcpd respectively.

I propose to backport the fix to this regex from chkrootkit/0.52-2 in Buster.

Debdiff is attached.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru chkrootkit-0.50/debian/changelog chkrootkit-0.50/debian/changelog
--- chkrootkit-0.50/debian/changelog2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/changelog2019-01-21 11:45:44.0 +0100
@@ -1,3 +1,14 @@
+chkrootkit (0.50-4+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport fix for regular expression for filtering out dhcpd and dhclient as
+false positives from the packet sniffer test.
+
+  [ Lorenzo "Palinuro" Faletra ]
+  * Update /etc/cron.daily/chkrootkit (Closes: #600109)
+
+ -- Moritz Schlarb   Mon, 21 Jan 2019 11:45:44 +0100
+
 chkrootkit (0.50-4) unstable; urgency=low
 
   * [132754e] Fix windigo false positive (Closes:#796599)
diff -Nru chkrootkit-0.50/debian/cron.daily chkrootkit-0.50/debian/cron.daily
--- chkrootkit-0.50/debian/cron.daily   2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/cron.daily   2019-01-21 11:44:19.0 +0100
@@ -19,7 +19,7 @@
eval $CHKROOTKIT $RUN_DAILY_OPTS > 
$LOG_DIR/log.today.raw 2>&1
# the sed expression replaces the messages 
about /sbin/dhclient3 /usr/sbin/dhcpd3
# with a message that is the same whatever 
order eth0 and eth1 were scanned
-   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient3|/usr/sbin/dhcpd3)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient3|dhcpd3]{PID}\),' \
+   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient|/usr/sbin/dhcpd)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient|dhcpd]{PID}\),' \
-e 's/(! \w+\s+)[ 0-9]{4}[0-9]/\1#/' 
$LOG_DIR/log.today.raw > $LOG_DIR/log.today
 if [ ! -f $LOG_DIR/log.expected ]; then
echo "ERROR: No file 
$LOG_DIR/log.expected"

Bug#919957: Please check for binaries depending on unused libraries

[Josh Triplett]

On Mon, 21 Jan 2019 08:39:27 +0200 Adrian Bunk  wrote:
> On Sun, Jan 20, 2019 at 03:45:35PM -0800, Josh Triplett wrote:
> > I'd love to see lintian catch issues like this:
> > 
> > $ ldd -u /sbin/badblocks
> > Unused direct dependencies:
> > /lib/x86_64-linux-gnu/libblkid.so.1
> > 
> > Lintian already parses binaries and libraries with objdump, so catching
> > this seems reasonable.
> 
> This does not sound like a good idea to me, since fixing such warnings 
> would result in many ugly (and sometimes not upstreamable) hacks.

In most cases, fixing such warnings would involve either adding
--as-needed or just removing a library from linking for a given program.

- Josh

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Andreas Beckmann]

Package: lintian
Severity: normal

libpython3.7-dev ships /usr/include/python3.7 -> python3.7m

Packages should not install and ship headers in /usr/include/python3.7/
but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
otherwise they will trigger piuparts installs_over_symlink_error.

currently violated by

python-greenlet-dev: /usr/include/python3.7/greenlet/greenlet.h
python3-bsddb3: /usr/include/python3.7/bsddb3/bsddb.h
python3-persistent: /usr/include/python3.7/persistent/cPersistence.h
python3-persistent: /usr/include/python3.7/persistent/ring.h
python3-pygame: /usr/include/python3.7/pygame/_camera.h
python3-pygame: /usr/include/python3.7/pygame/_pygame.h
python3-pygame: /usr/include/python3.7/pygame/_surface.h
python3-pygame: /usr/include/python3.7/pygame/bitmask.h
python3-pygame: /usr/include/python3.7/pygame/camera.h
python3-pygame: /usr/include/python3.7/pygame/fastevents.h
python3-pygame: /usr/include/python3.7/pygame/font.h
python3-pygame: /usr/include/python3.7/pygame/freetype.h
python3-pygame: /usr/include/python3.7/pygame/mask.h
python3-pygame: /usr/include/python3.7/pygame/mixer.h
python3-pygame: /usr/include/python3.7/pygame/pgarrinter.h
python3-pygame: /usr/include/python3.7/pygame/pgbufferproxy.h
python3-pygame: /usr/include/python3.7/pygame/pgcompat.h
python3-pygame: /usr/include/python3.7/pygame/pgopengl.h
python3-pygame: /usr/include/python3.7/pygame/pygame.h
python3-pygame: /usr/include/python3.7/pygame/scrap.h
python3-pygame: /usr/include/python3.7/pygame/surface.h
python3-zope.proxy: /usr/include/python3.7/zope.proxy/proxy.h

python-greenlet-dev: /usr/include/python3.6/greenlet/greenlet.h
python3-bsddb3: /usr/include/python3.6/bsddb3/bsddb.h
python3-igraph: /usr/include/python3.6/python-igraph/igraphmodule_api.h
python3-persistent: /usr/include/python3.6/persistent/cPersistence.h
python3-persistent: /usr/include/python3.6/persistent/ring.h
python3-pygame: /usr/include/python3.6/pygame/_camera.h
python3-pygame: /usr/include/python3.6/pygame/_pygame.h
python3-pygame: /usr/include/python3.6/pygame/_surface.h
python3-pygame: /usr/include/python3.6/pygame/bitmask.h
python3-pygame: /usr/include/python3.6/pygame/camera.h
python3-pygame: /usr/include/python3.6/pygame/fastevents.h
python3-pygame: /usr/include/python3.6/pygame/font.h
python3-pygame: /usr/include/python3.6/pygame/freetype.h
python3-pygame: /usr/include/python3.6/pygame/mask.h
python3-pygame: /usr/include/python3.6/pygame/mixer.h
python3-pygame: /usr/include/python3.6/pygame/pgarrinter.h
python3-pygame: /usr/include/python3.6/pygame/pgbufferproxy.h
python3-pygame: /usr/include/python3.6/pygame/pgcompat.h
python3-pygame: /usr/include/python3.6/pygame/pgopengl.h
python3-pygame: /usr/include/python3.6/pygame/pygame.h
python3-pygame: /usr/include/python3.6/pygame/scrap.h
python3-pygame: /usr/include/python3.6/pygame/surface.h
python3-zope.proxy: /usr/include/python3.6/zope.proxy/proxy.h


Andreas

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Chris Lamb]

tags 919979 + moreinfo
severity 919979 wishlist
thanks

Hi Andreas,

> Packages should not install and ship headers in /usr/include/python3.7/
> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),

Why? I'll need such an explanation for the long description. :)


Best wishes,

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

Bug#919954: blockattack: Starting blockattack causes a segfault

[Markus Koschany]

Hello,

Am 20.01.19 um 23:37 schrieb Nikolas Nyby:
> Package: blockattack
> Version: 2.3.0-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I started blockattack with no options.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Starting blockattack with the --software-renderer option solves this problem.
> 
>* What was the outcome of this action?
> 
> I get this error when starting blockattack like this:
> 
> $ blockattack
> GetFileContent - File does not exists: configFile
> ALSA lib pcm.c:8424:(snd_pcm_recover) underrun occurred
> Segmentation fault
> 
>* What outcome did you expect instead?
> 
> I expected the program to start.

The game works for me but I use an Intel based graphic chip. Since the
--software-renderer option works for you too, it is likely that this is
an issue with your Nouveau drivers. The GetFileContent warnings are
harmless because those files don't exist at first start and are later
stored in ~/.local/share/blockattack.

The only way to debug this issue is to get a backtrace. See
https://wiki.debian.org/HowToGetABacktrace for further information.
Please also attach a kernel log to the bug report.

dmesg > kernel_log.txt

With those information we could reassign the bug report to
xserver-xorg-video-nouveau. However, since Debian already ships the
latest version of nouveau, I suggest to submit this bug report upstream
as well because it is most likely not Debian specific.

https://nouveau.freedesktop.org/wiki/Bugs/

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Chris Lamb]

Hi Andreas,

> On 2019-01-21 10:13, Chris Lamb wrote:
> >> Packages should not install and ship headers in /usr/include/python3.7/
> >> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
> > 
> > Why? I'll need such an explanation for the long description. :)
> 
> Installing files over symlinks may silently overwrite files from other
> packages without dpkg noticing. 
[..]

Sorry, I actually meant why /usr/include/python3.x versus
python3.xm. What is the difference between these two directories?


Regards,

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

Bug#919356: dwarves-dfsg: Copyright/licensing is unclear

[Domenico Andreoli]

Hallo d-l,

  the situation of dwarves-dfsg improved a lot over the weekend, the
only knot left is now the license of hash.h

This file is also present in the kernel [0] with an updated copyright
but still without license.

I received a private email from somebody in the kernel community who
already tried to contact Nadia in the past but did not get any reply.

I need advice on how to handle the package, it is all GPL 2.0 with just
this exception.

I think that pushing it to non-free is formally the right thing but I
actually feel it's not the right thing.

Regards,
Domenico

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#910987: Bug#917025: tracker.debian.org: 0 new commits since last upload

[Christoph Berg]

Control: reassign -1 tracker.debian.org

Re: Mattia Rizzolo 2018-12-21 <20181221211515.gn19...@mapreri.org>
> > Not sure if this is a duplicate of #910987, but I see the problem.
> 
> Not quite.  However, it's not a problem coming from tracker, rather by
> the data source it uses.

It's somewhat related because in both bugs, the wording used by the
tracker is the problem. In #910987, the information is technically
correct, but the wording is a little bit too aggressive in suggesting
that A Upload Is Needed Now.

> > -->8--
> >  action needed
> >  0 new commits since last upload, time to upload? normal
> >  vcswatch reports that this package seems to have a new changelog entry
> >  (version 1:5.25.2-2, distribution unstable) and new commits in its VCS.
> >  You should consider whether it's time to make an upload.
> > 
> >  Here are the relevant commit messages:
> > 
> >  None
> > 
> >  Created: 2018-12-21 Last update: 2018-12-21 15:05
> > -->8---
> > 
> > Latest commit is 727f110b (tagged then, after several minutes,
> > everything was pushed to the public repo _before_ upload to
> > the debian archive was done).

The problem here is that the tracker is interpreting the information
from vcswatch wrongly. The "commits since last tag" information should
only be used when the status is "COMMITS". And even when done
correctly, it should rather be saying "eventually this package should
be uploaded", and not "time to upload?" which seems to suggest that
this should happen "now".

Christoph

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Philip Hands]

Ian Jackson  writes:

...
>
>  * Declare that no-one is allowed the binary package name
>/usr/bin/dune other than the C++ library dune-common
 ^
I suspect you meant 'dune' there.

BTW I agree (having followed the thread) that the consensus on
debian-devel was that the choice of name was pretty foolish.
Foolishness made less forgivable by the fact that the name change was
prompted by a previous clash, and the new name was very obviously also
going to clash with several easily discoverable software projects.

My opinion is that if any package gets to use /usr/bin/dune, it should
be one of the other ones: As you suggest, most probably the C++ library.
The same goes for the package name.

Stéphane,

  That being the case, I would encourage you to come up with a better
  justification than what I've seen so far[1].  The sooner you do this,
  the more likely is is to have an influence on the outcome.

BTW This is just my opinion, and I'm not trying to swing the view of the
rest of the TC by stating it.  However, I suspect that I'm not alone in
thinking this, so it seems OK to say so early rather than to insist on
trudging through the more usual processes and waste a lot of time.

Cheers, Phil.

[1] It seems the Upstream didn't like the idea of another name change.
Other than that I've not noticed a particular reason for the choice
of name beyond the association between camels and dunes, which seems
pretty weak to me.  Feel free to point out if this is wrong.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#908862: neutron: FTBFS (failing tests)

[Thomas Goirand]

Santiago Vila :
> This is still happening, both in reproducible-builds and also in my
> own autobuilders. The reproducible-builds logs are available here:
>
>
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html
>
> and I've just put my build logs here:
>
> https://people.debian.org/~sanvila/build-logs/neutron/

What's weird, is that it's not the same amount of failures.

> (I'm still using eatmydata, since you said you use it yourself and
> it's supposed to work).

Correct.

> Please take a look at this. Just saying "it works for me" does not
> help.

Here, you're recognizing that there's a pattern, and that we've seen
already a few times that, building works for me, but fails in your
environment. So, quite the opposite, the "it works for me" is important,
and needs to be addressed. We need to figure out what is different in
your environment and mine.

To investigate this, I've just tried building in a porter box, which
normally should be very close (if not identical) to what we have in the
buildd network. What I did was really only download the build
dependencies in the schroot, and run dpkg-buildpackage in the schroot:
so nothing special, really. The build was on barriere.debian.org.

The result is that it works perfectly. I do expect to see the same
result if uploading source only.

One thing I've observed, is that most of the times (or every time?), the
test errors we've seen are in SQLite, with a "table doesn't exist"
error. I have no idea (yet) why it's like that.

> While we are at it, I have yet to see how this is not serious,
> being a FTBFS bug in a supported architecture, but I will be happy to
> skip the discussion about the severity as far as you are really
> willing to solve the problem.

An FTBFS which we would observe everywhere, including in porter boxes
(which are normally the same as the buildds), in all configurations
including the most basic one (like mine), would indeed qualify as an RC
bug. Though if there's an FTBFS only in some specific environments,
which we aren't even able to explain, doesn't look like a good candidate
for an RC bug.

> If you still need a machine to reproduce this, please contact me
> privately.

Unfortunately, last time I tried, I could indeed see the FTBFS, but I
wasn't able to understand why it was happening in your build env and not
the standard one (ie: porter box or my own sbuild setup). As you're
actually paying for the VM to be hosted, I don't dare to ask you to
leave it up, and I'm unsure what to do... :/

I'm open to ideas and I am willing to spend the time to understand, if
you have some clues,
Cheers,

Thomas Goirand (zigo)

Bug#919985: jupyter-sphinx-theme: ipywidgets depends on python-jupyter-sphinx-theme which was removed

[Tobias Hansen]

Package: src:jupyter-sphinx-theme
Version: 0.0.6+ds1-4
Severity: normal
Tags: sid buster
Control: block 917705 by -1

Hi Jerome,

ipywidgets depends on python-jupyter-sphinx-theme which is no longer built by 
jupyter-sphinx-theme. I haven't checked if ipywidgets could be changed not to 
depend on it, but I wanted to make you aware that we might have to bring back 
python-jupyter-sphinx-theme.

Best,
Tobias

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

tags #919922 confirmed upstream
severity #919922 important
thanks

Hi Sven,

thanks for spotting this. Strangely, this didn't happen on my test
box, but I can confirm this behavior for my workstation.

I am downgrading this to important though, since I consider the
statistics writing an auxillary feature, and I suspect that the issue
will fix itself next midnight.

What do you think, would it be an acceptable workaround to move the
current day file away in postinst and document that fact?

Greetings
Marc


On Sun, Jan 20, 2019 at 07:17:54PM +0100, Sven Hartge wrote:
> From: Sven Hartge 
> Subject: Bug#919922: Does not start anymore, existing file
>  /var/log/atop/atop_20190120 has incompatible header
> To: Debian Bug Tracking System 
> Reply-To: Sven Hartge , 919...@bugs.debian.org
> Date: Sun, 20 Jan 2019 19:17:54 +0100
> X-Mailer: reportbug 7.5.1
> 
> Package: atop
> Version: 2.4.0-1
> Severity: grave
> 
> Hello!
> 
> After the update tpo 2.4.0-1 atop does not start anymore for me.
> TL;DR: 
> 
> existing file /var/log/atop/atop_20190120 has incompatible header
> (created by version 2.3 - current version 2.4)
> 
> Here the whole debugging session:
> 
> server:~# systemctl start atop; systemctl status atop; sleep 2; systemctl 
> status atop
> ● atop.service - Atop advanced performance monitor
>Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
> enabled)
>Active: active (running) since Sun 2019-01-20 19:08:50 CET; 11ms ago
>  Docs: man:atop(1)
>  Main PID: 550488 (atop.daily)
> Tasks: 5 (limit: 4691)
>Memory: 1.5M
>CGroup: /system.slice/atop.service
>├─550488 /bin/bash /usr/share/atop/atop.daily
>├─550491 ps -p 547913
>└─550492 grep atop$
> ● atop.service - Atop advanced performance monitor
>Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
> enabled)
>Active: failed (Result: exit-code) since Sun 2019-01-20 19:08:50 CET; 1s 
> ago
>  Docs: man:atop(1)
>   Process: 550488 ExecStart=/usr/share/atop/atop.daily (code=exited, status=7)
>  Main PID: 550488 (code=exited, status=7)
> 
> As one can see, the unit starts /usr/share/atop/atop.daily but no daemon
> remains at the end.
> 
> Even when running the shell script directly, nothing happens:
> 
> server:~# ps auwwwx | grep [a]top; rm /run/atop.pid; bash -x 
> /usr/share/atop/atop.daily; sleep 5; ps auwwwx | grep [a]top
> user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
> /usr/bin/python3 /usr/bin/reportbug atop
> user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim 
> -c :6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
> user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
> /tmp/user/1000/reportbug-atop-20190120-547330-uof401oa
> + LOGOPTS=-R
> + LOGINTERVAL=600
> + LOGGENERATIONS=28
> + DEFAULTSFILE=/etc/default/atop
> + '[' -e /etc/default/atop ']'
> + . /etc/default/atop
> + case "$LOGGENERATIONS" in
> ++ date +%Y%m%d
> + CURDAY=20190120
> + LOGPATH=/var/log/atop
> + BINPATH=/usr/bin
> + PIDFILE=/run/atop.pid
> + '[' -e /run/atop.pid ']'
> + sleep 3
> + echo 555663
> + exec /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
> + find /var/log/atop -name 'atop_*' -mtime +28 -exec rm '{}' ';'
> user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
> /usr/bin/python3 /usr/bin/reportbug atop
> user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim 
> -c :6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
> user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
> /tmp/user/1000/reportbug-atop-20190120-547330-uof401oa
> 
> (You can see the open reportbug where I type this in right now.)
> 
> Running atop directly shows the problem:
> 
> server:~# /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
> existing file /var/log/atop/atop_20190120 has incompatible header
> (created by version 2.3 - current version 2.4)
> 
> Deleting all files in /var/log/atop/ makes it work again.
> 
> Side not: the error message does *not* appear in the journal nor the syslog.
> 
> Grüße,
> Sven.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
> 
> Kernel: Linux 4.19.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 /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages atop depends on:
> ii  libc62.28-5
> ii  libncurses6  6.1+20181013-1
> ii  libtinfo66.1+20181013-1
> ii  lsb-base 10.2018112800
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> Versions of packages atop recommends:
> ii  cron [cron-daemon]  3.0pl1-130
> 
> atop 

Bug#919981: Update bug metadata

[Jonathan Carter]

bts notfound 919981 mathjax/2.7.4+dfsg-1 '# fixing version information'
. found 919981 mathjax/2.7.0-2

thanks

This bug affects version 2.7.0 and seems to be fixed in the 2.7.4
version available in testing.

Bug#919991: clusterssh: sometimes fails to open sessions with "Interrupted system call"

[Moritz Schlarb]

Package: clusterssh
Version: 4.13.2-2
Severity: important

Hi,

ClusterSSH in Buster sometimes fails to open one or more sessions with:

> Cannot open pipe for reading when talking to linux1 : Interrupted system call
> Use of uninitialized value $win in concatenation (.) or string at
/usr/share/perl5/App/ClusterSSH.pm line 639.
> linux1  session closed

I don't know who exactly is the culprit here, maybe Perl, but if someone gave
me some pointers, I'd be happy to investigate.

Regards,
Moritz



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

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

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  30-1
ii  libx11-protocol-perl0.56-7
ii  openssh-client  1:7.9p1-5
ii  perl5.28.1-3
ii  perl-tk 1:804.033-2+b3
ii  xterm   342-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

Bug#919659: live-build: building in docker fails with mounting /proc unmount /sys [UPDATE]

[Leszek Lesner]

Hi,

after some debugging I found a solution which works fine for me and 
successfully builds 
Images and ISOs in Docker again. 

Commenting out this line in debootstrap makes it work again:
https://sources.debian.org/src/debootstrap/1.0.114/functions/#L1161

So either the issue is in debootstrap or there needs to be a patch in 
live-build to circumvent 
the issue of unmounting the dockers /proc

Input is welcome as I am unsure on how to procede here (e.g. opening up a bug 
in debootstrap 
or leave it here)

Greetings


-- 
ZevenOS / Neptune Team
https://neptuneos.com
Leszek Lesner 

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 11:20:52 +0100, Marc Haber wrote:
> What do you think, would it be an acceptable workaround to move the
> current day file away in postinst and document that fact?

Are the old files still readable by the new atop?

If not, another (better?) possibility is to ask the user if he
wishes to convert these old files to the new format.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#913820: [Pkg-freeipa-devel] Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin

[Jan Luca Naumann]

Hey,

the fix of this bug is not complete, the installation of the JS-stuff is
still excluded in debian/rules. Could you please take another look into
the bug?

Best regards,
Jan

On Fri, 16 Nov 2018 11:20:44 +0200 Timo Aaltonen 
wrote:
> On 15.11.2018 18.22, Jan Luca Naumann wrote:
> > Package: cockpit-389-ds
> > Version: 1.4.0.18-1
> > Severity: grave
> > Justification: renders package unusable
> > 
> > At the momenent the package cockpit-389-ds applies a patch to use the Debian
> > packaged JS libraries. In contrast to the vendored libraries the Debian 
> > versions
> > do not work with the current version of the cockpit-389-plugin, c.f. the
> > backtrace attached. Removing the Debian-specific patch and installing the
> > vendored JS libs resolves the issue.
> 
> yeah, and all the minified stuff is already in debian/missing-sources,
> so it should be fine to just drop the patch.. Thanks for the bug!
> 
> 
> -- 
> t
> 
> 

Bug#919986: ITP: r-cran-askpass -- safe password entry for GNU R, Git, and SSH

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-askpass
  Version : 1.1
  Upstream Author : Jeroen Ooms
* URL : https://cran.r-project.org/package=askpass
* License : MIT
  Programming Lang: GNU R
  Description : safe password entry for GNU R, Git, and SSH
 Cross-platform utilities for prompting the user for credentials or a
 passphrase, for example to authenticate with a server or read a protected key.
 Includes native programs for MacOS and Windows, hence no 'tcltk' is required.
 Password entry can be invoked in two different ways: directly from R via the
 askpass() function, or indirectly as password-entry back-end for 'ssh-agent'
 or 'git-credential' via the SSH_ASKPASS and GIT_ASKPASS environment variables.
 Thereby the user can be prompted for credentials or a passphrase if needed
 when R calls out to git or ssh.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-askpass
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919989: Where is upstream

[Geert Stappers]

Package: rust-dhcp4r

Version: 0.1.0-1


Hello,

Where to find upstream of  rust-dhcp4r?


A websearch did yield https://tracker.debian.org/pkg/rust-dhcp4r

and I hoped to be able to click on Homepage, but is it not stated.


Opening
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/dhcp4r/debian

did not reveal an watch file.  The uscan config could have helped me.


The Debian changelog revealed "crates.io", so found
https://crates.io/crates/dhcp4r

That page has two interresting links:

Documentation:  https://docs.rs/dhcp4r/0.1.0/dhcp4r/

Repository: https://github.com/krolaw/dhcp4r


The git repository seems to be the best candidate for a home page link.


Thank you for uploading dhcp4r to Debian.


Cheers

Geert Stappers

DevOps Engineer

Bug#919992: drbl: Remove/replace ash dependency

[Juan Picca]

Package: drbl
Version: 2.20.11-6
Severity: wishlist

Dear Maintainer,

Your package is the only one that use the package ash as dependency.

If you can change it for the package dash, the functionality remain unchanged
and the dash source package can remove the creation of the ash package.

Also, inspecting the files in drbl package, i can't see the usage of ash/dash
shell; the only one used is bash.

Regards,
Juan Picca

Bug#919994: deltachat-core has unsatisfied hard-coded dependencies on library packages

[Matthias Klose]

Package: src:deltacheck
Version: 0.39.0-1+ds
Severity: serious
Tags: sid buster

deltachat-core has unsatisfied hard-coded dependencies on library packages.

Package: libdeltachat0
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libsasl2-2, libetpan17,
libssl1.0.2, libsqlite3-0
Description: Delta.Chat shared libraries


excuses:
Migrates after: openssl1.0
Too young, only 0 of 5 days old
libdeltachat0/amd64 unsatisfiable Depends: libetpan17
libdeltachat0/arm64 unsatisfiable Depends: libetpan17
libdeltachat0/i386 unsatisfiable Depends: libetpan17
libdeltachat0/mips unsatisfiable Depends: libetpan17
libdeltachat0/ppc64el unsatisfiable Depends: libetpan17
libdeltachat0/s390x unsatisfiable Depends: libetpan17

Bug#919924: mercurial: autopkgtest depends on monotone which is not in testing

[Graham Inggs]

Control: tags -1 + patch

I've checked, and the autopkgtest succeeds when monotone is simply
dropped from the test dependencies, as below:


--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,3 @@
 Tests: testsuite
-Depends: @, zip, unzip, netbase, python-subversion, monotone, cvs, bzr, 
tla, gcc, python2.7-dev, less
+Depends: @, zip, unzip, netbase, python-subversion, cvs, bzr, tla, gcc, 
python2.7-dev, less

 Restrictions: allow-stderr

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 2019-01-21 10:13, Chris Lamb wrote:
>> Packages should not install and ship headers in /usr/include/python3.7/
>> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
> 
> Why? I'll need such an explanation for the long description. :)

Installing files over symlinks may silently overwrite files from other
packages without dpkg noticing. Also depending on the unpacking order
either a symlink or a directory will be created, the latter resulting in
two separate trees in the filesystem which may break stuff (because some
headers cannot be found in /usr/include/python3.7m/).


Andreas

Bug#919906: ITP: pullimap -- Pull mails from an IMAP mailbox and deliver them via SMTP or LMTP

[Peter Pentchev]

On Sun, Jan 20, 2019 at 05:33:02PM +0100, Guilhem Moulin wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Guilhem Moulin 
> 
> * Package name: pullimap
>   Version : 0.4
>   Upstream Author : Guilhem Moulin 
> * URL : https://git.guilhem.org/interimap/about/
> * License : GPL-3+
>   Programming Lang: Perl
>   Description : Pull mails from an IMAP mailbox and deliver them via SMTP 
> or LMTP
> 
> PullIMAP retrieves messages from an IMAP mailbox and deliver them to an
> SMTP or LMTP transmission channel.  It can also remove old messages after
> a configurable retention period.
> 
> A statefile is used to keep track of the mailbox's UIDVALIDITY and UIDNEXT
> values.  While PullIMAP is running, the statefile is also used to keep
> track of UIDs being delivered, which avoids duplicate deliveries if the
> process is interrupted.
> 
> PullIMAP supports the COMPRESS=DEFLATE extension from [RFC4978].  It is
> enabled by default on servers advertising it, in order to reduce network
> traffic.
> 
> See also https://guilhem.org/man/pullimap.1.html .

Hmm, as a Perl programmer, I do understand the spirit of "there's more
than one way to do it", so please do not take this as an objection of
any kind, but still I feel curious: what are pullimap's advantages over
fetchmail?

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#919644: Outdated version of debhelper used for building package

[Julian Dammann]

We investigated the problem further:
The systemd-tmpfiles call in the postinstall script is added by dh_installinit 
(debhelper).
debhelper Version 12 (sid) and Version 12~bpo9+1 (stretch-backports) already 
fixed this using basename, as we initially suggested.
However, apparently packages for stretch are not built using the debhelper 
suite from backports.

Bug#919995: fuse-posixovl: posixovl 1.3 is out !

[Thierry]

Package: fuse-posixovl
Version: 1.2.20120215+gitf5bfe35-1
Severity: important

Dear Maintainer,

i noticed that posixovl 1.3 is out for 4 months ! It would be awesome to have it
in buster.

Ciao,
Thierry


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

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

Versions of packages fuse-posixovl depends on:
ii  libc6 2.24-11+deb9u3
ii  libfuse2  2.9.7-1+deb9u2

fuse-posixovl recommends no packages.

fuse-posixovl suggests no packages.

-- no debconf information

Bug#919987: RM: golang-github-nvveen-gotty -- NPOASR; unused; abandoned upstream

[Arnaud Rebillout]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I packaged this library as a build dependency of the docker.io package.
It turns out that we don't use it to build docker.io. It has no reverse
dependency as I know of:

  $ reverse-depends -b golang-github-nvveen-gotty-dev
  No reverse dependencies found
  $ reverse-depends golang-github-nvveen-gotty-dev
  No reverse dependencies found

Plus, it's unmaintained upstream for years. So this is just cruft that
should be removed from the archive.

Last detail, it was never in stable anyway.

Thanks,

  Arnaud

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

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

-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlxFn4wfHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFizAD/4vo7TJuMUZRU1w
JMusR7UAVCUFNy8yG05+SRJVu1ZDULG2A0OdHDeMcxnLrOcReid8ckiqsXouEY6r
drjbEzbeCmfZro7TAo5Ivb7nTQd9k3oBx17BcFiZTln4DT9Z0qTCWSVZ1LkWDx69
AwkV2CgNr1JJ4HJTs9ZufVQ0lrPyN1xPWPUVtNNH5nWAN6wQRZ5QNFQCy0hcKXfg
RvP2foelbcXfwZ3OAJqv3P3oJiSHypR97OS1x5s7zTJEvjuiB1nMUsMu/HzO01jK
rtxhWs2YKAkOREK71BEVfgo+KiQa3NXnP6YBORhR4mBWcGu5rtgZgwLI299cwrKv
b71LC8w1RLYX+K0u/0JjRcTEKMq9sdIjFcrESZ9GwIKMiPO2je8Pd71xUwHlr+x6
/USWoAnzmYRq6JzakXua7jLi0s/1Esdhks1yFuAaI2qOnFl59YkiIB5dO6XlFG3I
F9QI4YxbDtkg0jdYYloY4MwbnMtraKBcnHMO06/VsLuHsBFC0fW0tsRhBed20+R2
IVCq1ZrcACmlp7Gv6UV9J1xFxKkIzCmDb0XrOqqnVfystc04xkN6GHUuDp8xpZwd
3FRxCERLrKJpond94zF9rc7sno8r8FZkn/tSnfEGaJi0k2A5xBn5NKH2Hg88C7aF
9MQvd5kkV+c9j+OyEuv8a5isIAncOA==
=NJ9v
-END PGP SIGNATURE-

Bug#915355: RFA: fbless -- terminal fiction book reader

[Davor Balder]

Hello Dmitry, 

I can look after this package for some time, if there are no other takers and 
if that is OK with you. 

I should be able to enlist additional assistance in case of major 
issues/changes.

Kind regards, 

Davor

Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier

[Samuel Thibault]

Hello,

Robert Schindler, le jeu. 17 janv. 2019 07:48:01 +0100, a ecrit:
> Is attached.

Thanks! Just to make sure, is this while Orca is running?

Samuel

Bug#919981: fonts-mathjax: Ugly formulas in jupyter

[Jan Groenewald]

Package: fonts-mathjax
Version: 2.7.4+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

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

   * Jupyter notebook mathematics formulas are ugly with bad spacing,
   * short integrals and parenthesis, even some missing mathcal
   * characters.

   * Upgrading to fonts-mathjax from buster fixes (well, improves greatly) the 
rendering/display.

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


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

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

fonts-mathjax depends on no packages.

fonts-mathjax recommends no packages.

Versions of packages fonts-mathjax suggests:
ii  libjs-mathjax  2.7.4+dfsg-1

-- no debconf information

Bug#919988: wrong license

[Thorsten Alteholz]

Package: goo
Version: 0.155-16
Severity: serious
thanks

Hi Aaron,

please change the license of src/samurui/treegoo.* from GPL to LGPL in 
your debian/copyright.


Thanks!
  Thorsten

Bug#836896: xen-utils-4.6: xenstore-read does not read from daemon

[Thadeu Lima de Souza Cascardo]

On Sun, Jan 20, 2019 at 07:50:50PM +0100, Hans van Kranenburg wrote:
> tags 836896 + moreinfo
> thanks
> 
> Hi,
> 
> This is about the bug report about xenstore that you filed before in the
> Debian bug tracker, against the Xen packages.
> 
> Your bug report was targeted at a Xen package in a Debian distribution
> older than the current stable (Stretch).
> 

Well, to be fair, when the bug was reported, Jessie was the latest
stable release.

> Can you please help us by confirming that any of the following scenarios
> does apply to your situation?
> 
> * I had this problem a long time ago. It was never solved, but I found a
> workaround, which is ...
> * I had this problem a long time ago, and I solved it by not using Xen
> any more, but by doing ...
> * I still experience this problem, and I'm still using Xen
> 3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
> * I had this problem, and since upgrading to Stretch / Buster / ? it
> seems it was solved, and I forgot to report it again. Please close it,
> thanks.
> * Other: ...
> 

I was just trying to reproduce a kernel bug that happened under xen. In
the process, I found issues trying to use it, did some debugging, and
reported as much information as I could.

> Note that even if you found a solution, it's still very useful to report
> it back to our bug tracker. There might be someone else running into the
> same problem, who can be helped with your information.
> 
> Please note that unless there's a response within a month from now, we
> will close the bug report. If you discover this message later, and this
> case is important to you, then you can try unarchiving the bug and
> replying to it, or reach out to the maintainers email list at
> pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
> post a message.

You don't have to wait a month. Just close and archive it already.

I understand how hard it is to maintain a package like xen on Debian,
and why this automatic triage is needed. I appreciate your time
maintaining such an important software under Debian.

Thanks.
Cascardo.

> 
> Thanks,
> Hans van Kranenburg

Bug#918247:

[Kyle Robbertze]

I'm going to test this (or get someone else to if I don't hear back from
DSA soon) on a porter box before I upload to unstable



signature.asc
Description: OpenPGP digital signature

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Julien Cristau]

On Thu, Jan 17, 2019 at 01:48:24PM -0800, Brad Warren wrote:
> I just wanted to make sure this was still on everyone’s radar. The
> change server side where tens of thousands of Debian users will begin
> being unable to renew their certificates is in less than a month.
> 
It is, but the initial uploads used the wrong version numbers and had to
be rejected.  AIUI Harlan should be back this week, hopefully he can get
to this.

Cheers,
Julien

> > On Jan 8, 2019, at 4:24 PM, Harlan Lieberman-Berg  
> > wrote:
> > 
> > Hello Julien, everyone,
> > 
> > I've uploaded the relevant packages for your examination.  The
> > packages uploaded are:
> > 
> > - python-acme_0.28.0-1+deb9u1
> > - python-certbot_0.28.0-1+deb9u1
> > - python-certbot-nginx_0.28.0-1+deb9u1
> > - python-certbot-apache_0.28.0-1+deb9u1
> > - python-josepy_1.1.0-2+deb9u1
> > - parsedatetime_2.1-3+deb9u1
> > 
> > On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
> >  wrote:
> >> 
> >> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> >>> OK, let's do that then.  Sorry for not getting back to this sooner.
> >> 
> >> Sounds good.  I'm preparing the uploads now.
> >> 
> >> It looks like I will need to rebuild the version of
> >> python-parsedatetime in stable to also build the python3 version.  I
> >> could also backport a newer version that builds python3.  Let me know.
> >> 
> >> Sincerely,
> >> --
> >> Harlan Lieberman-Berg
> >> ~hlieberman
> > 
> > 
> > 
> > -- 
> > Harlan Lieberman-Berg
> > ~hlieberman
> > 
> > -- 
> > To unsubscribe, send mail to 887399-unsubscr...@bugs.debian.org.
> > 

Bug#918242: Take over lmms maintanenace

[Javier Serrano Polo]

El dg 20 de 01 de 2019 a les 13:20 +0100, Ross Gammon va escriure:
> Would you like me to remove you from the uploaders list?

Do as you wish, I do not have upload permission.

smime.p7s
Description: S/MIME cryptographic signature

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Philipp Hahn]

Package: security-tracker
Severity: important

Dear Maintainer,

the JSON stream of the Debian Security Bug Tracker seems to report stale
data since the beginning of January 2019:

$ curl -I https://security-tracker.debian.org/tracker/data/json
HTTP/2 200
date: Mon, 21 Jan 2019 08:10:06 GMT
...
content-length: 19836218
last-modified: Wed, 02 Jan 2019 19:49:17 GMT
expires: Wed, 02 Jan 2019 20:57:34 GMT

This breaks our process to monitor the Debian Security updates by
processing the DSAs in a machine-readable format.

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

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

Bug#913346: libsane1: Cannot update libsane1

[Gianfranco Costamagna]

 Hello,


>If someone is using unstable, I expect them to be able to resolve
>such issues themselves. unstable isn't a release, it's a development
>version of Debian.

ehm, this bug hit testing too :/
>I don't understand why some users install unstable without understanding>the 
>ramifications of using a development version of Debian.

I honestly never cared about unstable or even experimental, but testing is 
somethingwe should consider with our upgrade paths...
Anyway, revised debdiff attached :)
G.
  

diff
Description: Binary data

Bug#919980: Ask before upgrading so user doesn't lose data

[積丹尼 Dan Jacobson]

Package: nodm

Got an idea:

As there is a very high chance the user is using nodm at the time he
runs apt-get upgrade etc. thinking ho-hum, just another upgrade of 50 
packages...

and an even higher chance if pidof nodm returns positive,

and a good chance that he was browsing something important, and editing
several files,

so instead of making it like the power went out and restarted,

why not have the update script,

kindly ask the user "Ready to update nodm? First close all your
windows" via dialog(1) etc.

Bug#919983: gyoto: autopkgtest failure on i386

[Graham Inggs]

Source: gyoto
Version: 1.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 1.3.0-1, gyoto has been failing its autopkgtests on 
i386 [1] with the following error:


Reading parameter file: 
/tmp/autopkgtest.mHCx9P/build.XrZ/src/doc/examples/example-torusjet.xml

 Copyright (c) 2011-2019 Frédéric Vincent, Thibaut Paumard,
 Odele Straub and Frédéric Lamy.
...

j = 18/32
j = 19/32
j = 20/32In gyoto-mpi-worker.C: Error initializing libgyoto: In 
ThermalBrems: alphanu undefined!

--
Child job 2 terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--
--
mpirun.openmpi detected that one or more processes exited with non-zero 
status, thus causing

the job to be terminated. The first process to do so was:

  Process name: [[32154,2],3]
  Exit code:1
--
autopkgtest [16:14:18]: test gyoto-mpi: ---]
gyoto-mpiFAIL non-zero exit status 1


It is not entirely clear that this is a new failure on i386 as previous 
tests always failed.  Test are now successful on amd64 in Debian [2] and 
all other tested architectures in Ubuntu; amd64, arm64, armhf, ppc64el 
and s390x.


Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/gyoto/disco/i386
[2] https://ci.debian.net/packages/g/gyoto/unstable/amd64/

Bug#919984: ITP: r-cran-sys -- Powerful and Reliable Tools for Running System Commands in GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-sys
  Version : 2.1
  Upstream Author : Jeroen Ooms, Gábor Csárdi
* URL : https://cran.r-project.org/package=sys
* License : MIT
  Programming Lang: GNU R
  Description : Powerful and Reliable Tools for Running System Commands in 
GNU R
 Drop-in replacements for the base system2() function with fine control
 and consistent behavior across platforms. Supports clean interruption,
 timeout, background tasks, and streaming STDIN / STDOUT / STDERR over
 binary or text connections. Arguments on Windows automatically get
 encoded and quoted to work on different locales. On Unix platforms the
 package also provides functions for evaluating expressions inside a
 temporary fork. Such evaluations have no side effects on the main R
 process, and support reliable interrupts and timeouts. This provides the
 basis for a sandboxing mechanism.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-sys
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919417: orca: Orca reads character by character when holding navigation keys pressed

[Robert Schindler]

Hello,

Just want to add that it behaves as intended in Firefox 64.0.2, but not
in gnome-terminal or gedit.

Best regards
Robert


signature.asc
Description: PGP signature

Bug#889582: Update libmtp package in Debian (new upstream releases)

[Dylan Aïssi]

Hi Alessio,

Le lun. 21 janv. 2019 à 02:23, Alessio Treglia  a écrit :
> On Fri, 18 Jan 2019 at 16:39, Dylan Aïssi  wrote:
> > If you don't have time, I can help you to update the package.
>
> Please go ahead.

Thanks :-)

Last questions:
- Should I do a NMU or co-maint is fine for you?
- Since the old git repo is gone with alioth, I have created a new one
with gbp --debsnap [1], is it ok if I move it to the debian group in
salsa (i.e. [2])?

Best,
Dylan

[1] https://salsa.debian.org/daissi/libmtp
[2] https://salsa.debian.org/debian/libmtp

Bug#919993: RM: python-astropy-helpers -- ROM; Dropping Python 2

[Ole Streicher]

Package: ftp.debian.org

Please remove the "python-astropy-helpers" source package from unstable.

Upstream will stop supporting the Python 2 package by the end of the
year, and so it should not appear in Buster or later. Python 3 support
is provided by the "astropy-helpers" source package.

All reverse (build) dependencies of python-astropy were removed:


$ dak rm -Rn python-astropy-helpers
Will remove the following packages from unstable:

python-astropy-helpers |2.0.7-1 | source, all

Maintainer: Debian Astro Team


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 12:28:40 +0100, Vincent Lefevre wrote:
> On 2019-01-21 11:20:52 +0100, Marc Haber wrote:
> > What do you think, would it be an acceptable workaround to move the
> > current day file away in postinst and document that fact?
> 
> Are the old files still readable by the new atop?

Since there is a new program atopconvert, I suppose that they are not.

> If not, another (better?) possibility is to ask the user if he
> wishes to convert these old files to the new format.

After thinking more about it, I think that the choice should be given
between:

1. Move the atop_* files under /var/log/atop to /var/log/atop.old
   (to be created if it doesn't exist yet).

2. Convert these files to the new format with atopconvert.

3. Both (just in case there would be a bug in atopconvert).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 12:48:59 +0100, Vincent Lefevre wrote:
> On 2019-01-21 12:28:40 +0100, Vincent Lefevre wrote:
> > If not, another (better?) possibility is to ask the user if he
> > wishes to convert these old files to the new format.
> 
> After thinking more about it, I think that the choice should be given
> between:
> 
> 1. Move the atop_* files under /var/log/atop to /var/log/atop.old
>(to be created if it doesn't exist yet).
> 
> 2. Convert these files to the new format with atopconvert.
> 
> 3. Both (just in case there would be a bug in atopconvert).

If too complex, it should be sufficient to announce what will be
done in NEWS.Debian (with apt-listchanges, the user could do a
backup first, and if he doesn't use apt-listchanges, he probably
doesn't care) and choose one of the solutions (not 3, because it
could use too much disk space). Probably 2, as the user probably
won't downgrade and won't have to remove the old files manually.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#889582: Update libmtp package in Debian (new upstream releases)

[Alessio Treglia]

On Mon, 21 Jan 2019 at 10:12, Dylan Aïssi  wrote:
> - Should I do a NMU or co-maint is fine for you?

Either way is fine.

> - Since the old git repo is gone with alioth, I have created a new one
> with gbp --debsnap [1], is it ok if I move it to the debian group in
> salsa (i.e. [2])?

I'm ok with that.

Thanks


-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

Bug#836034: mate-session-manager: don't run dbus-launch if XDG_RUNTIME_DIR/bus is available

[Mike Gabriel]

Hi Simon,

On  Di 29 Nov 2016 10:33:37 CET, Simon McVittie wrote:


On Tue, 29 Nov 2016 at 08:39:27 +, Mike Gabriel wrote:

On  Di 30 Aug 2016 11:52:49 CEST, Simon McVittie wrote:
> For the moment, dbus-user-session does make sure DBUS_SESSION_BUS_ADDRESS
> is set, to be nice to packages that don't have this fallback path.
> However, I'd like to avoid requiring that in future, by adapting
> the dbus-launch code in gnome-session and its forks to look for
> XDG_RUNTIME_DIR/bus before trying dbus-launch.
>
> I'll open an upstream bug for gnome-session after doing this MBF. The same
> patch that is used in gnome-session will probably also apply to
> mate-session-manager - based on a glance at the relevant code path, it
> does not appear to have changed since the fork.

I just looked into this and could neither find a gnome-session upstream bug,
nor a patch in gnome-session that address the above.


Sorry, this got rather lost. I'll try to refresh the patch I upstreamed
soon (it has some known issues due to being older than the dbus-user-session
code paths that actually landed).

Downstream: https://bugs.debian.org/835887

Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=694472

What needs to happen, at a minimum, before the patch on the upstream bug
can land: https://bugzilla.gnome.org/show_bug.cgi?id=694472#c8

Regards,
S


Is the above still a valid issue? After some URL reading, noticed that  
gnome-session upstream does not have your patch, yet. Neither has  
gnome-session in Debian.


Are you still on this? In the GNOME upstream issue, you mentioned some  
more work to be done on your patch. Did you get to that by now?


Please update the status of this bug and close it, if it's not valid anymore.

Thanks,
Mike
--

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

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



pgp8w5FE4bpUt.pgp
Description: Digitale PGP-Signatur

Bug#778664: pam_tty_audit bug how to confirm ?

[secucatcher]

hi
i plan to put auditd on several hundred servers to control.

I saw this bug, but i can't confirmed it on debian jessie or stretch, and i was 
thinking
it didn't exist anymore i discover the same case and behavior on ubuntu 18.40.

So now i'm in doubt :)

Jessie, 8.11 version

libpam-modules:amd64 1.1.8-3.1+deb8u2+b1
debconf  1.5.56+deb8u1 
libaudit1:amd64  1:2.4-1+b1 
libc6:amd64  2.19-18+deb8u10 
libdb5.3:amd64   5.3.28-9+deb8u1 
libpam-modules-bin   1.1.8-3.1+deb8u2+b1
libpam0g:amd64   1.1.8-3.1+deb8u2+b1
libselinux1:amd642.3-2   


Stretch, 9.6 version

libpam-modules:amd64 1.1.8-3.6
debconf  1.5.61 
libaudit1:amd64  1:2.6.7-2 
libc6:amd64  2.24-11+deb9u3
 libdb5.3:amd64   5.3.28-12+deb9u1
libpam-modules-bin   1.1.8-3.6 
libpam0g:amd64   1.1.8-3.6 
libselinux1:amd642.6-3+b3

No problems:

Jessie:
Jan 21 14:38:17  su[10664]: Successful su for root by marc
Jan 21 14:38:17  su[10664]: + /dev/pts/1 marc:root
Jan 21 14:38:17  su[10664]: pam_unix(su:session): session opened for user root 
by marc(uid=1003)
Jan 21 14:38:17  su[10664]: pam_tty_audit(su:session): changed status from 0 to 
1

stretch:

Jan 21 14:41:13  su[11588]: Successful su for root by marc
Jan 21 14:41:13  su[11588]: + /dev/pts/2 marc:root
Jan 21 14:41:13  su[11588]: pam_unix(su:session): session opened for user root 
by marc(uid=1001)
Jan 21 14:41:13  su[11588]: pam_systemd(su:session): Cannot create session: 
Already running in a session
Jan 21 14:41:13  su[11588]: pam_tty_audit(su:session): changed status from 0 to 
1

but ubuntu:
Jan 21 14:32:17  sshd[10975]: pam_tty_audit(sshd:session): error setting 
current audit status: Invalid argument
Jan 21 14:32:18  sshd[10975]: error: PAM: pam_open_session(): Cannot 
make/remove an entry for the specified session


So what environement or package create the bug ?
i don't want to have hundred of servers i can't no longer connect on it.
Best regards
thanks

Bug#913346: libsane1: Cannot update libsane1

[Jeremy Bicha]

On Mon, Jan 21, 2019 at 4:08 AM John Paul Adrian Glaubitz
 wrote:
> If someone can point me to the point in the policy where it says that
> upgrades and migrations in unstable need to be smooth and without
> such issues, I am happy to revise my point of view.

Respectfully, Debian Policy doesn't cover every single point. I think
the principle that you should be able to smoothly upgrade unstable is
such an undisputed principle that it hasn't needed to be stated in
Policy yet. piuparts is one tool to monitor that we can install,
uninstall, and upgrade packages smoothly. If a package introduces a
regression caught by piuparts, it is prevented from migrating to
Testing: in other words, it is an RC bug.

We can debate whether this bug is Serious or Important or even
something else, but I don't think it's reasonable to debate whether
there is a bug here or not.

You're welcome to ask the Release Team about this bug. I think they
would support my position.

I apologize that I didn't get around to verifying this bug much sooner
and therefore proposing a fix. This bug is really easy to verify, but
to some extent, the more time that goes by, the more likely that
people running unstable have already manually upgraded this package.

I am attaching an updated patch from Ubuntu. Ubuntu will need to carry
this change until Ubuntu 20.04 LTS is released. Then it can be dropped
from both Debian and Ubuntu.

I think it would be better to just upload this fix now, so we don't
have to worry about getting an exception once we hit the next Buster
Freeze milestone for adding a new binary package.

Thanks,
Jeremy Bicha
From c94e6facab754986546cfeca4af927028d182b95 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 21 Jan 2019 08:49:28 -0500
Subject: [PATCH] Add libsane1 transitional package

LP: #1802586
Closes: #913346
---
 debian/control | 21 +
 1 file changed, 21 insertions(+)

diff --git a/debian/control b/debian/control
index 0056910..5231286 100644
--- a/debian/control
+++ b/debian/control
@@ -125,3 +125,24 @@ Description: API development library for scanners [development files]
  .
  This package contains the files needed to build your applications
  using SANE.
+
+Package: libsane1
+Architecture: any
+Multi-Arch: same
+Section: oldlibs
+Depends:
+ libsane (>= ${source:Version}),
+ ${misc:Depends}
+Description: API library for scanners [transitional package]
+ SANE stands for "Scanner Access Now Easy" and is an application
+ programming interface (API) that provides standardized access to any
+ raster image scanner hardware (flatbed scanner, hand-held scanner,
+ video- and still-cameras, frame-grabbers, etc.). The SANE standard is
+ free and its discussion and development are open to everybody. The
+ current source code is written to support several operating systems,
+ including GNU/Linux, OS/2, Win32 and various Unices and is available
+ under the GNU General Public License (commercial applications and
+ backends are welcome, too, however).
+ .
+ This package is here to ensure smooth upgrades. It can be removed when
+ you see fit.
-- 
2.19.1

Bug#919727: cmtk FTBFS in unstable, presumablly due to the new dcmtk

[Andreas Tille]

Control: tags -1 help

Hi,

I can confirm that cmtk[1] really fails to build from source and
most probably this is due to changes in dcmtk.  Any help would be
more than welcome.

Kind regards,

   Andreas.


[1] https://salsa.debian.org/neurodebian-team/cmtk

-- 
http://fam-tille.de

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 13:27, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:

>> I think you can just delete all old statistics files, since they are
>> useless with the new atop. sysstat does this all the time (after a
>> debconf prompt).
> 
> I'd rather go without debconf and gazillions of translations.

Easiest solution would be to run the rotate script on upgrades from
<2.4.0 before starting the newly installed version. That way the old
files are still there, if one needs them but the new daemon starts with
a clean slate.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#913346: libsane1: Cannot update libsane1

[Gianfranco Costamagna]

 Hello John,

>No, it didn't. What makes you think so? The version of sane-backends with
>the libsane1 package was never migrated to testing, see:

you are right, I'm not sure why I missed this :)
If you want to cancel or reschedule my delayed upload, feel free to do it,I 
still would like to know the maintainer opinion on this.
Ubuntu can carry a delta for one year, or even forever, this is not the 
pointI'm trying to raise here :)

G.
  

Bug#862413: mate-desktop-environment: Transfer of email attachment from simplescan to sylpheed fails

[Mike Gabriel]

Control: reassing -1 caja-sendto

On  Fr 12 Mai 2017 15:15:52 CEST, Daniel Auth wrote:


Package: mate-desktop-environment
Version: 1.16.0+1
Severity: normal

Dear Maintainer,

I am running debian-stretch, a fresh install, with mate desktop environment.
I use the programs simplescan for scanning and sylpheed as an email client.

I scan a paper with simplescan. Then, in simplescan menubar, I click on
File -> Email. That opens the preferred emailer application (which  
is sylpheed)

with a compose window. The attachment does not appear in the compose window.

Expected behaviour:
Scanned paper appears as an Attachment in mailer's compose window.

I have tracked down the problem so far:

simplescan creates a temporary file, a pdf that should be the  
attachment  (works)

simplescan calls xdg-email, with a parameter defining the attachment (works)
xdg-email calls gvfs-open mailto
sylpheed's compose window opens but does not show the attachment.

Where the problem does not occur:
simplescan + sylpheed + xfce
simplescan + claws-mail + xfce
simplescan + claws-mail + mate

Best wishes,
Daniel Auth


Duplicate of #827901 in caja-sendto? Probably, so reassigning.

Mike
--

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

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



pgpUkeUi3LtwF.pgp
Description: Digitale PGP-Signatur

Bug#920006: geeqie: Random crashes in directories with many images

[Rinat]

Package: geeqie
Version: 1:1.4+git20190106-1
Severity: important
Tags: upstream patch

Since version 1:1.4+git20190106-1, Geeqie crashes randomly. Most often it
does so in a directory with many images, about thousand of them. It turned
out, there was an uninitialized variable read, which caused random addresses
to be passed to free(). That code was called once per seen file. That's
why the more one uses Geeqie, the more probable the crash is.

Fix was applied upstream:
http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=commitdiff;h=431adf320f4ce0ba31fb7a07ea53aca03c21fcbd

Please, consider updating the package to include changes.

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20190106-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-5
ii  libcairo21.16.0-2
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-14
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.1-5
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libstdc++6   8.2.0-14
ii  libtiff5 4.0.10-3
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.10-3
ii  exiftran 2.10-2+b3
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  librsvg2-common  2.44.10-1
ii  ufraw-batch  0.22-4
ii  zenity   3.30.0-2

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.8-2
pn  libjpeg-progs  
pn  ufraw  
pn  xpaint 

-- no debconf information

Bug#920005: Embedded JavaScript Library

[Stefan Hornburg (Racke)]

package: sympa
version: 6.2.40~dfsg-1

W: sympa: embedded-javascript-library 
usr/share/sympa/static_content/js/html5shiv/html5shiv.js please use 
libjs-html5shiv
N:
N:This package contains an embedded copy of JavaScript libraries that are
N:now available in their own packages (for example, JQuery, Prototype,
N:Mochikit or "Cropper"). Please depend on the appropriate package and
N:symlink the library into the appropriate location.
N:
N:Refer to Debian Policy Manual section 4.13 (Convenience copies of code)
N:for details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: files, Type: binary, udeb

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#918106: logrotate: segfaults in rotateLogSet

[Bernhard Übelacker]

Control: retitle 918106 logrotate: segfaults in rotateLogSet


Hello Marc,
I am sorry, but my advice to use 'bt full' makes
following commands to show the state of frame #1.

Therefore can you repeat the "coredumpctl gdb 754"
without the "bt full"?

Kind regards,
Bernhard

Bug#919957: Please check for binaries depending on unused libraries

[Chris Lamb]

[Adding d...@debian.org to CC]

Josh Triplett wrote:

> > This does not sound like a good idea to me, since fixing such warnings 
> > would result in many ugly (and sometimes not upstreamable) hacks.
> 
> In most cases, fixing such warnings would involve either adding
> --as-needed or just removing a library from linking for a given program.

I believe Adrian's wider point was more that there would be no need to
add --as-needed if it were made the default in Debian.

I believe doko (added to CC) was working on this (eg. #916831); is there
a status, ETA, tracking bug, etc.?


Regards,

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

Bug#919957: Please check for binaries depending on unused libraries

[Adrian Bunk]

[ Josh: The BTS does not Cc submitter or commenters, so I didn't get 
your email. ]

On Mon, Jan 21, 2019 at 03:37:02PM +, Chris Lamb wrote:
> [Adding d...@debian.org to CC]
> 
> Josh Triplett wrote:
> 
> > > This does not sound like a good idea to me, since fixing such warnings 
> > > would result in many ugly (and sometimes not upstreamable) hacks.
> > 
> > In most cases, fixing such warnings would involve either adding
> > --as-needed or just removing a library from linking for a given program.
> 
> I believe Adrian's wider point was more that there would be no need to
> add --as-needed if it were made the default in Debian.

Correct, manually adding --as-needed on a per-package basis would be 
more work for less benefits.

> I believe doko (added to CC) was working on this (eg. #916831); is there
> a status, ETA, tracking bug, etc.?

These are FTBFS in Ubuntu, which switched to --as-needed
as default 8 years ago.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#920015: Serious bug in armadillo

[Kumar Appaiah]

Package: armadillo
Version: 1:9.200.6+dfsg-1
Tags: patch

Per the author's report below.

Kumar
-- 
Kumar Appaiah
--- Begin Message ---
Hi Kumar,

I've discovered a serious bug in Armadillo 9.200.6, where the trace()
function can lead to incorrect results when applied to compound
expressions with complex matrices.

Attached is a small patch for Armadillo 9.200.6 which fixes the bug.
The patch changes only 1 line and does not introduce any new
functionality.  It is a pure bug fix patch.

Could you apply this patch to the Debian armadillo package ?  It would
be good to have this before upcoming freeze.

An alternative solution is to upgrade the Debian armadillo package to
version 9.200.7, which also contains the fix.

With regards,
Conrad


On Tue, 11 Dec 2018 at 15:39, Kumar Appaiah  wrote:
>
> Dear Conrad,
>
> On Tue, Dec 11, 2018 at 02:15:38PM +1000, Conrad Sand wrote:
> > Hi Kumar,
> >
> > I've released Armadillo 9.200, which contains bug fixes,
> > new functions, improvements and many speedups.
> >
> > I recommend upgrading the corresponding Debian and Ubuntu packages.
> >
> > http://sourceforge.net/projects/arma/files/armadillo-9.200.6.tar.xz
> >
> [snip]
> >
> > With regards,
> > Conrad
>
>
> Done. Thanks for contributing to Debian!
>
> Kumar
> --
> Kumar Appaiah
diff -r -u armadillo-9.200.6-a/include/armadillo_bits/fn_trace.hpp armadillo-9.200.6-b/include/armadillo_bits/fn_trace.hpp
--- armadillo-9.200.6-a/include/armadillo_bits/fn_trace.hpp	2016-06-17 02:19:16.0 +1000
+++ armadillo-9.200.6-b/include/armadillo_bits/fn_trace.hpp	2016-06-17 02:19:16.0 +1000
@@ -82,7 +82,7 @@
 template
 arma_warn_unused
 inline
-typename T1::elem_type
+typename enable_if2< is_cx::no, typename T1::elem_type>::result
 trace(const Glue& X)
   {
   arma_extra_debug_sigprint();
--- End Message ---

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Stéphane Glondu]

Le 20/01/2019 à 23:14, Ian Jackson a écrit :
> In #919622 and the associated debian-devel thread,
>  "Conflict over /usr/bin/dune"
>   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> the file conflict over /usr/bin/dune was discussed.
> 
> The rough consensus of the debian-devel thread was that /usr/bin/dune
> ought definitely not to be taken by the ocaml build system, and that
> the best claim on it was the C++ library which already provides a
> number of /usr/bin/dune?* binaries.

I do not agree there was such concensus.

You gave your opinion which seemed off-topic to me, Andy and Andreas
remotely agreed with you, Philipp had the same point of view as me.
Maintainers of whitedune did not object.

There is no conflict with the C++ library, I wonder why this was put on
the table.

> Instead, the maintainers of the ocaml package reassigned the bug
> against their `dune' package to the whitedune package, which
> previously provided /usr/bin/dune as a compat symlink.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622
> 
> They used the phrase
>   "As discussed on debian-devel"
> which is very misleading because it makes it sounds like there was a
> consensus for this course of action, whereas the opposite is true.

Sorry but from my point of view, I proposed something and there was no
(relevant) objection. I thought you were giving your opinion in passing,
and didn't understand you would be so vocal about it.

> Apparently as a result of this there was an NMU of `whitedune' to drop
> the symlink /usr/bin/dune.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58
> 
> The maintainers of the ocaml `dune' have now uploaded `dune' (the
> ocaml package) with /usr/bin/dune and Breaks+Replaces to claim the
> file.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#99

You seem to imply that transgressions have been made... but as far as I
can tell, procedures were followed and the relevant people (should) have
been notified.

> Meanwhile there seems to have been no contact with the maintainers of
> the C++ library which is the only hit on Wikipedia for
>   https://en.wikipedia.org/wiki/Dune_(software)
> (Amazingly, this is still true at the time of writing even though
> I referred to this fact in the debian-devel thread.)

I still fail to see how this is relevant.

> Note that this ocaml tool `dune' was previously known as `jbuilder'.
> It has nothing to do with Java AIUI.  No-one has suggested a plausible
> charitable explanation for why the ocaml upstream made such
> egregiously bad naming mistakes twice in succession.
> 
> Additionally the binary package name `dune' for the ocaml tool is bad,
> too.

Actually, I am not fond of the `dune' name either, but I think it's not
my job to judge and rename it. And I would feel ridiculous asking
upstream for a change (I am already ashamed of this situation).

> Please would the Technical Committee:
> 
>  * Declare that no-one is allowed the name /usr/bin/dune other than
>the C++ library dune-common or its friends.
> 
>  * Declare that no-one is allowed the binary package name
>/usr/bin/dune other than the C++ library dune-common
>or its friends.
> 
>  * Declare that the ocaml build system should choose a new source
>package name and use it henceforth.
> 
> I am about to file an RC bug against the `dune' package, blocked by
> this one.

The tone of your mail looks like harassment to me.


Cheers,

-- 
Stéphane

Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist

[Michael Stone]

On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote:

On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote:

On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
>On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
>> I’m very much against just saying this package
>> “should not exist”
>
>I'm inclined to agree with this as the source (+ features/parameters) for
>this package is substantially different from rng-tools/rng-tools5.

Yes, but most of those features are obsolescent at best. I'm not clear
on what functionality is actually being used. (I'm hesitant to remove
it exactly because I'm not clear on that, but I tend to think that it's
functionally obsolete.)


I'm not knowledgeable enough to weigh in on that and/or what is best towards
the future, so I'll leave that up to you.


>coordination/progress. I'm thinking of updating
>https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we
>use(d) the old rng-tools to get much better/more entropy on the Raspberry
>Pi.

In what way?


Entropy generation for the creation of SSH keys as the netinstaller is mostly
used in headless situations.
https://github.com/debian-pi/raspbian-ua-netinst/issues/42


That functionality doesn't require the old package; will work fine with 
rng-tools5. 

Bug#920018: Memory Leak in journald? Failed to write entry (23 items, 500 bytes), ignoring: Cannot allocate memory

[Sven Hartge]

Package: systemd
Version: 240-4
Severity: important

Hi!

Since systemd_240-4 journald seems to either leak memory or something
strange is going on with my system.

Soon after boot or journald restart, I get messages like this in my
kernel log:

[...]
[31317.206261] systemd-journald[341]: Failed to write entry (29 items, 682 
bytes), ignoring: Cannot allocate memory
[31330.715806] systemd-journald[341]: Failed to write entry (21 items, 547 
bytes), ignoring: Cannot allocate memory
[31330.756475] systemd-journald[341]: Failed to write entry (21 items, 549 
bytes), ignoring: Cannot allocate memory
[31330.756946] systemd-journald[341]: Failed to write entry (21 items, 633 
bytes), ignoring: Cannot allocate memory
[31330.757454] systemd-journald[341]: Failed to write entry (21 items, 629 
bytes), ignoring: Cannot allocate memory
[31331.070486] systemd-journald[341]: Failed to write entry (22 items, 577 
bytes), ignoring: Cannot allocate memory
[31331.070625] systemd-journald[341]: Failed to write entry (22 items, 564 
bytes), ignoring: Cannot allocate memory
[31331.103742] systemd-journald[341]: Failed to write entry (22 items, 581 
bytes), ignoring: Cannot allocate memory
[31331.103878] systemd-journald[341]: Failed to write entry (22 items, 548 
bytes), ignoring: Cannot allocate memory
[31331.104589] systemd-journald[341]: Failed to write entry (22 items, 562 
bytes), ignoring: Cannot allocate memory
[31334.787786] systemd-journald[341]: Failed to write entry (24 items, 611 
bytes), ignoring: Cannot allocate memory
[31335.992491] systemd-journald[341]: Failed to write entry (23 items, 500 
bytes), ignoring: Cannot allocate memory
[...]

Also the committed memory size as recored by munin (see attached image)
spikes quickly. You can clearly spot in the graph, when I upgraded to
systemd_240-4. You can also see the times where I manually restarted
journald.

(Yes, this system is a bit small for all the services running on it,
hence the swap usage.)

I now have downgraded to systemd_240-3 which resolves this issue for me.

Other systems of mine show the same, but because they have more RAM, the
problem is not as visible (yet).

Grüße,
Sven.

-- Package-specific info:

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

Kernel: Linux 4.19.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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-3
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.5-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-4
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-4

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 240-4

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent
ForwardToConsole=yes
TTYPath=/dev/tty12

/etc/systemd/logind.conf changed:
[Login]
KillUserProcesses=no

/etc/systemd/system.conf changed:
[Manager]
RuntimeWatchdogSec=60


-- debconf-show failed

Bug#919906: ITP: pullimap -- Pull mails from an IMAP mailbox and deliver them via SMTP or LMTP

[Guilhem Moulin]

Hi,

On Mon, 21 Jan 2019 at 12:40:47 +0200, Peter Pentchev wrote:
> Hmm, as a Perl programmer, I do understand the spirit of "there's more
> than one way to do it", so please do not take this as an objection of
> any kind, but still I feel curious: what are pullimap's advantages over
> fetchmail?

I switched from fetchmail to getmail4 some years ago because of
fetchmail's relative complexity, and the lack of client state for IMAP:
only UNSEEN messages from the server are downloaded, which makes it
unreliable if the remote IMAP server is used by another client between
fetchmail calls (it won't retrieve new messages read on the other
client).  getmail and pullimap, on the other hand, retrieve all messages
that have not been retrieved in a previous call.

What made me move away from getmail is the lack of IDLE support: a new
process is spawned, retrieves new messages, and then terminates.  This
adds some overhead (especially on high latency links such as over Tor)
as well as extra latency (when new messages are received one needs to
wait for the next getmail run to retrieve them).  On the other hand,
thanks to its IDLE support, pullimap keep the connection open (one
process per mailbox) and downloads new messages immediately.

My use-case for pullimap & interimap is when messages are retrieved from
one or more third-party IMAP accounts (corporate, etc.), then passed
through a local spam filter, and finally replicated to the other devices
(each of which having its own IMAP server), not necessarily in a star
topology.  Thanks to the long-lived connections, IDLE and friends, when
a message is delivered to my work mailbox, it appears on my laptop and
other devices <2s later (spamassassin being the overhead) and I'm
immediately notified.

Other advantages are COMPRESS=DEFLATE and native SOCKS support.  On the
downside, pullimap supports less protocols (only IMAP4rev1 on the
fetching end, only SMTP or LMTP on the receiving end) and processes a
single mailbox per process (but if multiple mailboxes need to be polled
one can start one process for each).

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 03:10:28PM +0100, Sven Hartge wrote:
> On 21.01.19 13:27, Marc Haber wrote:
> > On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:
> 
> >> I think you can just delete all old statistics files, since they are
> >> useless with the new atop. sysstat does this all the time (after a
> >> debconf prompt).
> > 
> > I'd rather go without debconf and gazillions of translations.
> 
> Easiest solution would be to run the rotate script on upgrades from
> <2.4.0 before starting the newly installed version. That way the old
> files are still there, if one needs them but the new daemon starts with
> a clean slate.

This is no direct rotate script, atop gets restarted at midnight with -w
"$LOGPATH"/atop_"$CURDAY", so just restarting the script won't work.

Take a look at /usr/share/atop/atop.daily.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[أحمد المحمودي]

On Sat, Jan 19, 2019 at 01:41:58AM +0100, Adam Borowski wrote:
> On Sat, Jan 19, 2019 at 07:47:51AM +0800, Paul Wise wrote:
> > On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote:
> > The most ideal situation would be to leave it off by default but
> > have a command-line option to turn it on.
---end quoted text---

Elinks is only compiled with javascript, but it is disabled by default. 
ie. the user has to switch it on.

Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete 
libmozjs185-dev)

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


signature.asc
Description: PGP signature

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:43, Sven Hartge wrote:
> On 21.01.19 15:31, Marc Haber wrote:
>> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> 
>>> I am downgrading this to important though, since I consider the
>>> statistics writing an auxillary feature, and I suspect that the issue
>>> will fix itself next midnight.
>>
>> Can you check whether:
>> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
>> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
>> will allow your atop to run again?
> 
> I don't have the old files any more unfortunately, sorry.

But I can temporarily downgrade to the version from testing and then do
the upgrade again.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#920011: Recursive chmod

[Stefan Hornburg (Racke)]

package: sympa

W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:207
N:
N:The maintainer script appears to call chmod or chown with a
N:--recursive/-R argument, or uses find(1) in a similar manner.
N:
N:This is vulnerable to hardlink attacks on mainline, non-Debian kernels
N:that do not have fs.protected_hardlinks=1,
N:
N:This arises through altering permissions or ownership within a directory
N:that may be owned by a non-privileged user - such a user can link to
N:files that they do not own such as /etc/shadow or files within
N:/var/lib/dpkg/. The promiscuous chown or chmod would convert the
N:ownership or permissions of these files so that they are manipulable by
N:the non-privileged user.
N:
N:Ways to avoid this problem include:
N:
N: - If your package uses a static uid, please perform the chown at
N:   package build time instead of installation time.
N: - Use a non-recursive call instead, ensuring that you do not change
N:   ownership of files that are in user-controlled directories.
N: - Use runuser(1) to perform any initialization work as the
N:   user you were previously chowning to.
N:
N:Refer to https://bugs.debian.org/889060, https://bugs.debian.org/889488,
N:and the runuser(1) manual page for details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: scripts, Type: binary
N:
W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:220
W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:226




-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#912749: These warnings occur with annoying regularity

[sixerjman]

Even after performing the prescribed fix, after a few days or weeks the
warning are back.

Bug#920014: efitools: please consider packaging latest upstream version 1.9.2

[Luca Boccassi]

Source: efitools
Version: 1.8.1-1
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

Dear Maintainer,

Please kindly consider updating efitools to the latest upstream version
before Buster ships. There have been a couple of important bug fixes
since last month that would be great to have in Buster.

For example, it fixes problems with signing variables for runtime
updates of KEK/DB/DBX, and with getting the hash of the kernel image in
some cases.

The latest upstream version is 1.9.2:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#919999: Fails to build from source in current stretch

[Adrian Bunk]

Control: severity -1 serious

On Mon, Jan 21, 2019 at 02:02:44PM +0100, Moritz Muehlenhoff wrote:
> Package: ruby2.3
> Version: 2.3.3-1+deb9u4
> Severity: important
> 
> Hi Ruby maintainers,
> I tried to rebuild ruby2.3 2.3.3-1+deb9u4 and it fails with the following 
> four test
> failures:
> 
> 
> 
>   1) Failure:
> IMAPTest#test_imaps_with_ca_file 
> [/build/ruby2.3-2.3.3/.ext/common/openssl/ssl.rb:404]:
> Exception raised:
> <# sslv3 alert certificate expired>>.
> 
>   2) Failure:
> IMAPTest#test_starttls [/build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:21]:
> exceptions on 1 threads:
> # dead>:
> /build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `accept': SSL_accept 
> returned=1 errno=0 state=unknown state: sslv3 alert certificate expired 
> (OpenSSL::SSL::SSLError)
> from /build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `block in 
> starttls_test'
>...
> Failure 1 and 2 are probably just an expired cert.

These look like #919516 in ruby2.5.

> We don't currently have any open/pending ruby2.3 security issues, but it 
> would be nice
> if those could be fixed in either the stretch branch in git or for the next 
> point release,
> so that this doesn't block a future sec update.

I'm marking it as RC, like any other FTBFS in stable.

This makes it visible for people looking through RC bugs in stable.

> Cheers,
> Moritz

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#918106: logrotate: segfaults in rotateLogSet

[secucatcher]

ok, so here we go
but i don't see much more withour bt full, do i understand correctly ?

the command:

coredumpctl gdb 754
display/i $pc
info reg
disassemble $pc-0x50,$pc+0x50

thanks


coredumpctl gdb 754
quit
   PID: 754 (logrotate)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Sun 2019-01-20 11:24:28 CET (1 day 5h ago)
  Command Line: /usr/sbin/logrotate /etc/logrotate.conf
Executable: /usr/sbin/logrotate
 Control Group: /system.slice/cron.service
  Unit: cron.service
 Slice: system.slice
   Boot ID: a57707f859fe4471ae781dd31d2b75f7
Machine ID: 230c8c9b6d3840749a45bcf6e73d8a82
  Hostname: syslog
   Storage: 
/var/lib/systemd/coredump/core.logrotate.0.a57707f859fe4471ae781dd31d2b75f7.754.1547979868.lz4
   Message: Process 754 (logrotate) of user 0 dumped core.

Stack trace of thread 754:
#0  0x55e3239db88a rotateLogSet (logrotate)
#1  0x55e3239d298d main (logrotate)
#2  0x7faf357fb2e1 __libc_start_main (libc.so.6)
#3  0x55e3239d312a _start (logrotate)



GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/logrotate...Reading symbols from 
/usr/lib/debug/.build-id/4b/a3d893d18935ef292da47c51a97214648caf82.debug...done.
done.
[New LWP 754]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/logrotate /etc/logrotate.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55e3239db88a in rotateLogSet (log=0x55e323ec4ca0, force=0) at 
logrotate.c:1880
1880logrotate.c: Aucun fichier ou dossier de ce type.


display/i $pc

1: x/i $pc
=> 0x55e3239db88a :callq  0x55e3239d6ec0 


info reg

 info reg
rax0x0  0
rbx0x55e323ec4ca0   94434048625824
rcx0x0  0
rdx0x55e323ec4650   94434048624208
rsi0x55e3239dd734   94434043483956
rdi0x2  2
rbp0x7fff984ad610   0x7fff984ad610
rsp0x7fff97c94a30   0x7fff97c94a30
r8 0x55e358a20040   94434932949056
r9 0x0  0
r100x0  0
r110x246582
r120x55e3239d3100   94434043441408
r130x0  0
r140x0  0
r150x55e323ec4ca0   94434048625824
rip0x55e3239db88a   0x55e3239db88a 
eflags 0x10246  [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0


disassemble $pc-0x50,$pc+0x50
Dump of assembler code from 0x55e3239db83a to 0x55e3239db8da:
   0x55e3239db83a:  test   %al,(%rax)
   0x55e3239db83c:  add%al,(%rax)
   0x55e3239db83e:  add%al,(%rax)
   0x55e3239db840 : push   %rbp
   0x55e3239db841 : mov%rsp,%rbp
   0x55e3239db844 : push   %r15
   0x55e3239db846 : push   %r14
   0x55e3239db848 : push   %r13
   0x55e3239db84a :push   %r12
   0x55e3239db84c :mov%esi,%r13d
   0x55e3239db84f :push   %rbx
   0x55e3239db850 :lea0x1edd(%rip),%rsi
# 0x55e3239dd734
   0x55e3239db857 :mov%rdi,%r15
   0x55e3239db85a :sub$0x58,%rsp
   0x55e3239db85e :mov(%rdi),%rdx
   0x55e3239db861 :mov%fs:0x28,%rax
   0x55e3239db86a :mov%rax,-0x38(%rbp)
   0x55e3239db86e :xor%eax,%eax
   0x55e3239db870 :movslq 0x10(%rdi),%rax
   0x55e3239db874 :mov$0x2,%edi
   0x55e3239db879 :lea0x12(,%rax,4),%rax
   0x55e3239db881 :and$0xfff0,%rax
   0x55e3239db885 :sub%rax,%rsp
   0x55e3239db888 :xor%eax,%eax
=> 0x55e3239db88a :callq  0x55e3239d6ec0 
   0x55e3239db88f :test   %r13d,%r13d
   0x55e3239db892 :mov%rsp,%r12
   0x55e3239db895 :jne0x55e3239dbb70 

   0x55e3239db89b :cmpl   $0x5,0x20(%r15)
   0x55e3239db8a0 :ja 0x55e3239db8e0 

   

Bug#915689: Bug#919893: package shouldn't exist

[Diederik de Haas]

On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
> I’m very much against just saying this package
> “should not exist”

I'm inclined to agree with this as the source (+ features/parameters) for this 
package is substantially different from rng-tools/rng-tools5.

AFAICT the problem started when rng-tools changed substantially by the upload 
which made it (very) similar to rng-tools5 and I think the last line of the 
long description of rng-tools should've been removed as it only applies to the 
'old' implementation (which is now in rng-tools-debian).

I bumped into the 'conversation' because I noticed a lack of conversation/
coordination/progress. I'm thinking of updating https://github.com/debian-pi/
raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get 
much better/more entropy on the Raspberry Pi. (I also want to investigate 
whether it'll help with other small SBCs like Pine A64)
I haven't tried yet whether rng-tools5 will work just as well (raspbian-ua-
netinst doesn't use any cmd-line params)

And I also think that the current situation shouldn't end up in a stable 
release.

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

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 11:20, Marc Haber wrote:

> I am downgrading this to important though, since I consider the
> statistics writing an auxillary feature, and I suspect that the issue
> will fix itself next midnight.

But until then, the daemon will be non-functional and since there is no
message *why* this is the case, the user/admin is left in the dark.

> What do you think, would it be an acceptable workaround to move the
> current day file away in postinst and document that fact?

I think you can just delete all old statistics files, since they are
useless with the new atop. sysstat does this all the time (after a
debconf prompt).

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#900918: debian-installer: Please make the generated images reproducible

[Chris Lamb]

Dear Cyril,

Thank you for your review and timely merge.

> That's looking good but I'm seeing new warnings because of gzip's being
> unhappy about the GZIP environment variable.

Interesting. However when you say "new" warnings I don't believe my
patch set actually added/changed this; indeed, it has not changed
since:

   
https://salsa.debian.org/lamby/debian-installer/commit/28b863340cc5fd73fbaac85a3fb89e72e842b15c

… so I'm just checking what you are requesting to be done here.

§

> All gtk files have fontconfig-related cache/uuid changes…
[…]
> FWIW, dropping all fontconfig-related bits (see attached patch)

This is #864082 in src:fontconfig — I've been playing whack-a-mole
with fontconfig over the past 18 months or so and this was a
fairly recent regression.

Are you planning on applying this patch to debian-installer.git?
Naturally, I would prefer if #864082 was applied and in buster, or
otherwise closed again.

§

> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg?

Possibly. Let me try and reproduce and reload all of that into my
brain and get back to you on this; IIRC there was some pushback
against making it change behaviour only on SOURFE_DATE_EPOCH being
present so — as you imply — a command-line change might be required.

§

> (Including lintian runtime, using pigz on a 8-way machine cuts real time
> from 8m8s to 4m23s.)

TIL pigz; thanks.

> Checking what happens [it] seems successive builds with pigz lead to the
> same results. But those aren't the same as the results generated with
> gzip. I don't suppose this is going to be a particularly huge problem
> though?

Alas, it is a problem in thatfrom the outside nobody will know
whether one built with pigz or gzip and thus it will be unclear how
to reproduce the bit-for-bit identical binary. In other words, there
is currently no ".buildinfo" equivalent here that specifies "I used
Arch^Wpigz, btw" and got a SHA of $foo.

One easy solution would be if that, if SOURCE_DATE_EPOCH is present,
then we force the use of one tool. Although that would regrettably
mean the lowest common denominator (ie. gzip)  which probably isn't
the ideal due to the aforementioned performance gain for using pigz.
Alternatively, we could make pigz a strict build requirement but
that sounds a little antisocial.

Perhaps we need to record the environment after all; again, I will
reload all of this into my head anyway due to mini.iso (^) so this
will be top-of-stack again.


Regards,

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

Bug#919996: gnat ftbfs on kfreebsd

[Matthias Klose]

Package: src:gcc-9
Version: 9-20190120-1
Priority: important

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/x86_64-kfreebsd-gnu/bin/ -B/usr/x86_64-kfreebsd-gnu/lib/ -isystem
/usr/x86_64-kfreebsd-gnu
/include -isystem /usr/x86_64-kfreebsd-gnu/sys-include -isystem
/<>/build/sys-include   -fchecking=1 -c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s
-osinte.adb -o s-osinte.o
s-osinte.ads:445:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:446:07: warning: formal parameter "protocol" is not referenced
s-osinte.ads:449:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:450:06: warning: formal parameter "protocol" is not referenced
s-osinte.ads:453:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:454:07: warning: formal parameter "prioceiling" is not referenced
s-osinte.ads:457:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:458:07: warning: formal parameter "prioceiling" is not referenced
../gcc-interface/Makefile:299: recipe for target 's-osinte.o' failed
make[8]: *** [s-osinte.o] Error 1
make[8]: Leaving directory '/<>/build/gcc/ada/rts'
gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
make[7]: *** [gnatlib] Error 2
make[7]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
make[6]: *** [gnatlib-shared-dual] Error 2
make[6]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
make[5]: *** [gnatlib-shared] Error 2
make[5]: Leaving directory '/<>/build/gcc/ada'
Makefile:104: recipe for target 'gnatlib-shared' failed
make[4]: *** [gnatlib-shared] Error 2
make[4]: Leaving directory '/<>/build/x86_64-kfreebsd-gnu/libada'
Makefile:20374: recipe for target 'all-target-libada' failed
make[3]: *** [all-target-libada] Error 2

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 13:15:09 +0100, Sven Hartge wrote:
> I think you can just delete all old statistics files, since they are
> useless with the new atop. sysstat does this all the time (after a
> debconf prompt).

I disagree. They may still be useful to analyze a past problem,
even with the new atop since they can be converted.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#920000: Please build nacl with -fPIC and use CFLAGS from dpkg-buildflags

[Laurent Bigonville]

Source: nacl
Version: 20110221-6
Severity: serious

Hi,

Should't nacl be built with -fPIC?

You also might want to follow the *FLAGS set in the environment during
the build.

On fedora they are doing both:

https://src.fedoraproject.org/cgit/rpms/nacl.git/tree/nacl-20110221-dist-flags.patch
https://src.fedoraproject.org/cgit/rpms/nacl.git/tree/nacl.spec#n56

The fact that it's missing -fPIC seems to cause troubles in libssh
(#919956)

See attached patch

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru 
nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch 
nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch
--- nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch   
2018-10-22 08:10:48.0 +0200
+++ nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch   
2019-01-21 13:14:00.0 +0100
@@ -11,35 +11,32 @@
  okcompilers/cpp | 9 +++--
  2 files changed, 6 insertions(+), 12 deletions(-)
 
-diff --git a/okcompilers/c b/okcompilers/c
-index 7218da3..2667f82 100644
 --- a/okcompilers/c
 +++ b/okcompilers/c
-@@ -1,8 +1,5 @@
+@@ -1,8 +1 @@
 -gcc -m64 -O3 -fomit-frame-pointer -funroll-loops
 -gcc -m64 -O -fomit-frame-pointer
 -gcc -m64 -fomit-frame-pointer
 -gcc -m32 -O3 -fomit-frame-pointer -funroll-loops
 -gcc -m32 -O -fomit-frame-pointer
 -gcc -m32 -fomit-frame-pointer
-+gcc -O3 -fomit-frame-pointer -funroll-loops
-+gcc -O -fomit-frame-pointer
-+gcc -fomit-frame-pointer
- spu-gcc -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
- spu-gcc -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
-diff --git a/okcompilers/cpp b/okcompilers/cpp
-index d1b9ae6..35304e4 100644
+-spu-gcc -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
+-spu-gcc -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
++gcc ${CFLAGS}
 --- a/okcompilers/cpp
 +++ b/okcompilers/cpp
-@@ -1,8 +1,5 @@
+@@ -1,8 +1 @@
 -g++ -m64 -O3 -fomit-frame-pointer -funroll-loops
 -g++ -m64 -O -fomit-frame-pointer
 -g++ -m64 -fomit-frame-pointer
 -g++ -m32 -O3 -fomit-frame-pointer -funroll-loops
 -g++ -m32 -O -fomit-frame-pointer
 -g++ -m32 -fomit-frame-pointer
-+g++ -O3 -fomit-frame-pointer -funroll-loops
-+g++ -O -fomit-frame-pointer
-+g++ -fomit-frame-pointer
- spu-g++ -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
- spu-g++ -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
+-spu-g++ -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
+-spu-g++ -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
++g++ ${CFLAGS}
+--- a/okcompilers/archivers
 b/okcompilers/archivers
+@@ -1,2 +1 @@
+ ar
+-ar -X64
diff -Nru nacl-20110221/debian/rules nacl-20110221/debian/rules
--- nacl-20110221/debian/rules  2018-10-22 08:11:09.0 +0200
+++ nacl-20110221/debian/rules  2019-01-21 13:14:00.0 +0100
@@ -2,6 +2,8 @@
 
 #export DH_VERBOSE=1
 
+CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
+
 override_dh_auto_build:
# some quick tests for the status of /sys to help debug failures
-ls /sys
@@ -13,5 +15,15 @@
# DJB "makefile"-ish
./do
 
+override_dh_auto_configure:
+   [ -f okcompilers/c.orig ] || cp okcompilers/c okcompilers/c.orig
+   [ -f okcompilers/cpp.orig ] || cp okcompilers/cpp okcompilers/cpp.orig
+   sed -i 's|$${CFLAGS}|$(CFLAGS) -fPIC|g' okcompilers/c okcompilers/cpp
+
 %:
dh $@
+
+override_dh_auto_clean:
+   mv -f okcompilers/c.orig okcompilers/c || true
+   mv -f okcompilers/cpp.orig okcompilers/cpp || true
+   dh_auto_clean

Bug#919516:

[Andreas Hasenack]

Upstream fixes, located by juliank:

https://github.com/ruby/ruby/commit/f234e6c3d3170f37508e214cdaef78d4b2584e5a
https://github.com/ruby/ruby/commit/1e0b49a293d3792826c67b7e05c5fcbd09c9ea6e

Bug#920007: squid: basic_ncsa_auth username case sensitivity

[Matsievskiy S.V.]

Package: squid
Version: 4.4-1
Severity: normal

Dear Maintainer,

I was configuring basic_ncsa_auth authentication in squid and could not get it 
to work.
Eventually I decided to check input of basic_ncsa_auth and replaced it with 
custom script:

#!/bin/bash
cat $@ > /tmp/args
cat > /tmp/stdin

After output examination, I learned that squid converts all characters to 
lowercase.
In my case, login had uppercase characters in it. So call to basic_ncsa_auth 
never succeeded.

In my opinion either squid should not convert characters to lowercase, or it 
should be clearly stated somewhere that uppercase characters are not allowed.

tldr: basic_ncsa_auth option does not support usernames with uppercase 
characters.

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

Kernel: Linux 4.19.12-custom (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)
LSM: AppArmor: enabled

Versions of packages squid depends on:
ii  adduser  3.118
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcom-err2  1.44.5-1
ii  libdb5.3 5.3.28+dfsg1-0.2
ii  libdbi-perl  1.642-1+b1
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.6-1
ii  libgcc1  1:8.2.0-14
ii  libgnutls30  3.6.5-2
ii  libgssapi-krb5-2 1.16.2-1
ii  libkrb5-31.16.2-1
ii  libldap-2.4-22.4.47+dfsg-2
ii  libltdl7 2.4.6-6
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnettle6   3.4.1~rc1-1
ii  libpam0g 1.1.8-4
ii  libsasl2-2   2.1.27~rc8-1
ii  libstdc++6   8.2.0-14
ii  libxml2  2.9.4+dfsg1-7+b3
ii  logrotate3.14.0-4
ii  lsb-base 10.2018112800
ii  netbase  5.5
ii  squid-common 4.4-1

Versions of packages squid recommends:
ii  ca-certificates  20180409
ii  libcap2-bin  1:2.25-1.2

Versions of packages squid suggests:
pn  resolvconf   
ii  smbclient2:4.9.4+dfsg-1
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
ii  ufw  0.36-1
pn  winbindd 

-- Configuration Files:
/etc/squid/squid.conf changed:
acl localnet src 192.168.1.0/24 # RFC 1918 local private network (LAN)
acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 10 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 6 hours
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
include /etc/squid/conf.d/*
http_access allow password
http_access deny all
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320


-- no debconf information

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:31, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:

>> I am downgrading this to important though, since I consider the
>> statistics writing an auxillary feature, and I suspect that the issue
>> will fix itself next midnight.
> 
> Can you check whether:
> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
> will allow your atop to run again?

I can confirm: this works.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#920008: Manpage has errors

[Stefan Hornburg (Racke)]

package: sympa
severity: minor

W: sympa: manpage-has-errors-from-man usr/share/man/man5/sympa.conf.5.gz 222: 
warning [p 2, 2.2i]: can't break line
N:
N:This man page provokes warnings or errors from man.
N:
N:"cannot adjust" or "can't break" are trouble with paragraph filling,
N:usually related to long lines. Adjustment can be helped by left
N:justifying, breaks can be helped with hyphenation, see "Manipulating
N:Filling and Adjusting" and "Manipulating Hyphenation" in the groff
N:manual (see info groff).
N:
N:"can't find numbered character" usually means latin1 etc in the input,
N:and this warning indicates characters will be missing from the output.
N:You can change to escapes like \[:a] described on the groff_char man
N:page.
N:
N:Other warnings are often formatting typos, like missing quotes around a
N:string argument to .IP. These are likely to result in lost or malformed
N:output. See the groff_man (or groff_mdoc if using mdoc) man page for
N:information on macros.
N:
N:This test uses man's --warnings option to enable groff warnings that
N:catch common mistakes, such as putting . or ' characters at the start of
N:a line when they are intended as literal text rather than groff
N:commands. This can be fixed either by reformatting the paragraph so that
N:these characters are not at the start of a line, or by adding a
N:zero-width space (\&) immediately before them.
N:
N:At worst, warning messages can be disabled with the .warn directive, see
N:"Debugging" in the groff manual.
N:
N:Lintian also stricter in regards to declaring manpage preprocessors.
N:
N:To test this for yourself you can use the following command:
N: LC_ALL=en_US.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
N:man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
N:
N:Refer to the groff_man(7) manual page and the groff_mdoc(7) manual page
N:for details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: manpages, Type: binary

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Adrian Bunk]

Source: golang-google-cloud
Version: 0.9.0-7
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-google-cloud.html

...
dh_auto_build
cd build && go install 
-gcflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" 
-asmflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" -v 
-p 16 cloud.google.com/go cloud.google.com/go/bigquery 
cloud.google.com/go/bigtable cloud.google.com/go/bigtable/bttest 
cloud.google.com/go/bigtable/cmd/cbt cloud.google.com/go/bigtable/cmd/emulator 
cloud.google.com/go/bigtable/cmd/loadtest 
cloud.google.com/go/bigtable/cmd/scantest 
cloud.google.com/go/bigtable/internal/cbtconfig 
cloud.google.com/go/bigtable/internal/gax 
cloud.google.com/go/bigtable/internal/option 
cloud.google.com/go/bigtable/internal/stat cloud.google.com/go/civil 
cloud.google.com/go/compute/metadata cloud.google.com/go/container 
cloud.google.com/go/datastore cloud.google.com/go/debugger/apiv2 
cloud.google.com/go/errorreporting/apiv1beta1 cloud.google.com/go/errors 
cloud.google.com/go/iam cloud.google.com/go/iam/admin/apiv1 
cloud.google.com/go/internal cloud.google.com/go/internal/atomiccache 
cloud.google.com/go/internal/fields cloud.google.com/go/internal/optional 
cloud.google.com/go/internal/pretty cloud.google.com/go/internal/readme 
cloud.google.com/go/internal/rpcreplay 
cloud.google.com/go/internal/rpcreplay/proto/intstore 
cloud.google.com/go/internal/rpcreplay/proto/rpcreplay 
cloud.google.com/go/internal/testutil cloud.google.com/go/internal/tracecontext 
cloud.google.com/go/internal/version cloud.google.com/go/language/apiv1 
cloud.google.com/go/language/apiv1beta2 cloud.google.com/go/logging 
cloud.google.com/go/logging/apiv2 cloud.google.com/go/logging/internal 
cloud.google.com/go/logging/internal/testing 
cloud.google.com/go/logging/logadmin cloud.google.com/go/longrunning 
cloud.google.com/go/longrunning/autogen cloud.google.com/go/monitoring/apiv3 
cloud.google.com/go/profiler cloud.google.com/go/profiler/mocks 
cloud.google.com/go/pubsub cloud.google.com/go/pubsub/apiv1 
cloud.google.com/go/pubsub/loadtest cloud.google.com/go/pubsub/loadtest/cmd 
cloud.google.com/go/pubsub/loadtest/pb cloud.google.com/go/spanner 
cloud.google.com/go/spanner/admin/database/apiv1 
cloud.google.com/go/spanner/admin/instance/apiv1 
cloud.google.com/go/spanner/internal/testutil cloud.google.com/go/speech/apiv1 
cloud.google.com/go/speech/apiv1beta1 cloud.google.com/go/storage 
cloud.google.com/go/trace cloud.google.com/go/trace/apiv1 
cloud.google.com/go/translate 
cloud.google.com/go/translate/internal/translate/v2 
cloud.google.com/go/videointelligence/apiv1beta1
src/cloud.google.com/go/speech/apiv1beta1/speech_client.go:29:2: cannot find 
package "google.golang.org/genproto/googleapis/cloud/speech/v1beta1" in any of:

/usr/lib/go-1.11/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1 
(from $GOROOT)

/build/1st/golang-google-cloud-0.9.0/build/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
 (from $GOPATH)

Bug#919849: [Pkg-salt-team] Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*

[Benjamin Drung]

Am Montag, den 21.01.2019, 16:34 +0100 schrieb Benjamin Drung:
> Am Sonntag, den 20.01.2019, 06:07 +0100 schrieb Andreas Beckmann:
> > Package: salt-doc
> > Version: 2018.3.3+dfsg1-2
> > Severity: normal
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package ships (or
> > creates)
> > a broken symlink.
> > 
> > From the attached log (scroll to the bottom...):
> > 
> > 0m29.8s ERROR: FAIL: Broken symlinks:
> >   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js ->
> > ../../../../../../twitter-bootstrap/files/js/bootstrap.min.js
> > (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js ->
> > ../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/css/bootstrap.min.css ->
> > ../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css
> > -> ../../../../../twitter-bootstrap/files/css/bootstrap-
> > responsive.min.css (salt-doc)
> > 
> > 
> > Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter-
> > bootstrap ?
> 
> salt-doc depends on libjs-bootstrap to provide these files. Sadly the
> path has changed between the version in stable and in unstable. I
> will fix the symlinks with the next upload.

I saw it wrong. The path in stable and unstable are the same. I
probably overlooked the changed path between src:twitter-bootstrap and
src:twitter-bootstrap3.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Mon Jan 21 2019 at 08:36 AM +0100, Trek wrote:
> @Bill Brelsford: is the problem gone with the 240-4 version? if not,
> can you test udev with these patches applied? thanks!

Yes, 240-4 fixed the problem.  Thanks Trek, Michael and others who
helped resolve it!

Regards..  Bill

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi,

On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
 wrote:
> Santiago Vila 於 2019/1/20 上午1:35 寫道:
> > Package: src:libjstun-java
> > Version: 0.7.3+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >  debian/rules build-indep
> > dh build-indep --with javahelper
> >dh_update_autotools_config -i
> >jh_linkjars -i
> >jh_build -i
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
> > ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
> > or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 1 warning
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make: *** [debian/rules:11: build-indep] Error 123
> > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> > status 2
> > 
> > 
> > (The above is just how the builds ends and not necessarily the most 
> > relevant part)
> > 
> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> > 
> 
> Hi Santiago,
> 
> It seems to me that this line causes the problem.
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
> /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api -classpath
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
> -source 1.7
> 
> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api", then it will pass.
> 
> I'm wondering if javahelper needs to call javadoc in different way.

I've got the very same result for #919803 affecting src:mac-widgets.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[David Bremner]

Ian Jackson  writes:

> Package: tech-ctte
>
> In #919622 and the associated debian-devel thread,
>  "Conflict over /usr/bin/dune"
>   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> the file conflict over /usr/bin/dune was discussed.
>
> The rough consensus of the debian-devel thread was that /usr/bin/dune
> ought definitely not to be taken by the ocaml build system, and that
> the best claim on it was the C++ library which already provides a
> number of /usr/bin/dune?* binaries.
>
> Instead, the maintainers of the ocaml package reassigned the bug
> against their `dune' package to the whitedune package, which
> previously provided /usr/bin/dune as a compat symlink.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622
>
> They used the phrase
>   "As discussed on debian-devel"
> which is very misleading because it makes it sounds like there was a
> consensus for this course of action, whereas the opposite is true.
>
> Apparently as a result of this there was an NMU of `whitedune' to drop
> the symlink /usr/bin/dune.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58
>

Per article 6.6 of the constitution (which I know you're aware of ;)),
have efforts to resolve this via consensus really failed? Except under
extraordinary circumstances, I would expect whitedune maintainers to NAK
the NMU if they disagreed with this resolution. I don't think the
wording of the NMU changelog alone is enough to involve the TC, nor do I
think the social appropriateness of this NMU is really within our
purview.

d

Bug#914464: Any update?

[Filip Pytloun]

Hello,

any update with this package?
I would need it to build newer vdirsyncer.

Thank you,
Filip


signature.asc
Description: PGP signature

Bug#919998: ITP: fonts-b612 -- legible font designed to be used on aircraft cockpit screens

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fonts-b612
  Version : 1.003
  Upstream Authors: 2012 AIRBUS 
2012 Laurent Spaggiari 


* URL : https://github.com/polarsys/b612
* License : OFL 1.1
  Description : legible font designed to be used on aircraft cockpit 
screens
 In 2010, Airbus initiated a research collaboration with ENAC and 
Universite
 de Toulouse III on a prospective study to define and validate an 
Aeronautical
 Font: the challenge was to improve the display of information on the 
cockpit
 screens, in particular in terms of legibility and comfort of reading, 
and to

 optimize the overall homogeneity of the cockpit.
 .
 Two years later, Airbus came to find Intactile DESIGN to work on the 
design
 of the eight typographic variants of the font. This one, baptized B612 
in
 reference to the imaginary asteroid of the aviator SaintExupery, 
benefited

 from a complete hinting on all the characters.
 .
 Main characteristics are:
  - Maximize the distance between the forms of the characters
  - Respect the primitives of the different letters
  - Harmonize the forms and their spacing

Package is availabe at http://phd-sid.ethz.ch/debian/fonts-b612/

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> I am downgrading this to important though, since I consider the
> statistics writing an auxillary feature, and I suspect that the issue
> will fix itself next midnight.

Can you check whether:
mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
will allow your atop to run again?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#920004: node-get-value: missing dependency on node-isobject

[Adrian Bunk]

Package: node-get-value
Version: 3.0.1-1
Severity: serious

> require('get-value')
{ Error: Cannot find module 'isobject'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18) code: 'MODULE_NOT_FOUND' 
}
>

Bug#920012: fwupd breaks xbox360 controller support

[Phil Armstrong]

Package: fwupd
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

As outlined in https://github.com/hughsie/fwupd/pull/836 fwupd as 
currently in Debian testing breaks xbox 360 controller support.


Can we pull a more recent version of fwupd into buster?

cheers, Phil

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libappstream-glib8 0.7.14-1
ii  libarchive13   3.3.3-3
ii  libc6  2.28-5
ii  libefiboot1    37-1
ii  libefivar1 37-1
ii  libelf1    0.175-2
ii  libfwupd2  1.1.4-1
ii  libgcab-1.0-0  1.2-2
ii  libglib2.0-0   2.58.2-3
ii  libgnutls30    3.6.5-2
ii  libgpg-error0  1.33-3
ii  libgpgme11 1.12.0-4
ii  libgudev-1.0-0 232-2
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.26.0+fossilbc891ac6b-1
ii  libuuid1   2.33.1-0.1

Versions of packages fwupd recommends:
ii  bolt   0.7-2
ii  fwupd-amd64-signed [fwupd-signed]  1.1.4+1
ii  python3    3.7.1-3

fwupd suggests no packages.

-- no debconf information

Bug#886777: Bug#907972 #886777: xsane crashes with Mustek Bearpaw 2448 TA Pro

[Bernhard Übelacker]

Control: forcemerge 886777 907972
Control: tags 886777 + upstream fixed-upstream


Dear Maintainer,
upstream applied a fix to this stack smashing.
If no new upstream version is released and enters buster,
this patch [1] might be a candidate for cherry-picking.

Kind regards,
Bernhard


[1] 
https://gitlab.com/sane-project/backends/commit/93340afddfbc4085a5297fe635b65dd7f7f3ef05.patch

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Sun, Jan 13, 2019 at 7:21 PM Keith Packard  wrote:
>
> Alexander Larsson  writes:

> > Yeah, there will be two files. One static in the runtime
> > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak
> > (/run/host/fontconf.xml).
>
> Sounds like we've got a plan for this part -- fix my mapping code to use
> config bits separate from the  elements, then add a 'salt'
> mechanism in the config bits that stirs in some random data when
> generating the cache keys for specific directory trees.

Whats the status of this. Can we come up with an agreed upon format
for doing the dir remapping (outside of the dir nodes) soon? I'm about
to do a flatpak 1.2 release and would like to preempt things by
generating the dir mapping dynamic snippet so we can use it when we
update fontconfig in the runtime. (Note: We need not yet finalize the
salt stuff, because that will not be in the dynamic flatpak-generated
part of this.)

Bug#920013: sbsigntool: please consider packaging latest upstream version 0.9.2

[Luca Boccassi]

Source: sbsigntool
Version: 0.6-3.2
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

Dear Maintainer,

Please kindly consider updating sbsigntool to the latest upstream
version before Buster ships. There have been a number of important
fixes and additions that would be good to have.

For example, the old version has sometimes issues parsing the kernel
signature. Also, the new version adds a convenient sbverify --list that
simply lists all signatures and is useful for a quick (and non
cryptographically secure!) check. Also, it fixes problems with signing
variables for runtime updates of KEK/DB/DBX.

The latest upstream version is 0.9.2:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Julien Cristau]

+debian-admin

On Mon, Jan 21, 2019 at 02:26:16PM +0100, Julien Cristau wrote:
> On Mon, Jan 21, 2019 at 09:27:19AM +0100, Philipp Hahn wrote:
> > Package: security-tracker
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > the JSON stream of the Debian Security Bug Tracker seems to report stale
> > data since the beginning of January 2019:
> > 
> > $ curl -I https://security-tracker.debian.org/tracker/data/json
> > HTTP/2 200
> > date: Mon, 21 Jan 2019 08:10:06 GMT
> > ...
> > content-length: 19836218
> > last-modified: Wed, 02 Jan 2019 19:49:17 GMT
> > expires: Wed, 02 Jan 2019 20:57:34 GMT
> > 
> > This breaks our process to monitor the Debian Security updates by
> > processing the DSAs in a machine-readable format.
> > 
> Looks like at least one CDN node was returning stale data.  I purged
> /tracker/data/json and things are looking ok now.  Thanks for the
> report.
> 
For the record, in case this comes back: I wasn't able to reproduce, but
both Philipp and Ansgar were getting stale data with a "x-cache:
UPDATING" header, from 23.111.9.35.  For me from the same ip the data
was recent and "x-cache: HIT".

Cheers,
Julien

Bug#920016: ITP: gst-plugins-rtp -- GStreamer libraries for handling RTP/RTCP streams on the network

[Marc Leeman]

Package: wnpp
Severity: wishlist
Owner: Marc Leeman 

* Package name: gst-plugins-rtp
  Version : 1.14.4.1
  Upstream Author : Marc Leeman 
* URL : https://github.com/mleeman/gst-plugins-rtp
* License : LGPL
  Programming Lang: C
  Description : GStreamer libraries for handling RTP/RTCP streams on the 
network

 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 GStreamer RTP plugins provide elements that handle RTP streaming to
 and from the network and provide bindings to the rtp:// URI interface.
This message is subject to the following terms and conditions: MAIL 
DISCLAIMER

Bug#919997: ITP: node-domino -- server-side DOM implementation based on Mozilla's dom.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-domino
  Version : 2.1.1
  Upstream Author : Felix Gnass 
* URL : https://github.com/fgnass/domino
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : server-side DOM implementation based on Mozilla's dom.js

 Domino provides a fast but insecure DOM in Node.js.
 .
 The Document Object Model (DOM)
 is a cross-platform and language-independent
 application programming interface
 that treats an HTML, XHTML, or XML document as a tree structure
 wherein each node is an object representing a part of the document.
 .
 Node.js is an event-based server-side JavaScript engine.

NB! Felix Gnass is the main _author_ only -
and The Mozilla Foundation is the main copyright holder.

This package will be maintained in the Debian JavaScript team

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxFu8YACgkQLHwxRsGg
ASEGXw//crSWPh5JcG2fA1w7nGOfYO9HQbNvHWN0tjP2gn90/aoJbvGMbMldMRAI
584yZVVx/u8UeV9/YW91JnXG1RSIlpZM4puoT+2nfoosAwSmDt0W4oAPycHAQnTs
zjRJrxtt29iBGbxbeWoaNxbf+lQfjrT0pMV0WemC8z+78Qy9Lb1qqZ322RBLTvLx
SLKFK0NpKQRkkmVvOXqwWUdibCqlUoGKXG5ZxeCccFC8P92k0N++/UqYCWNJ9I2F
wl/kKbHclT0olf/j2TLFFEAbE9evBJRDV1RwxKbN2v0nsKhENuhBnkCpp0uCypSI
O9D/bHWyvBSK71IXv89Nxij/FUKWhykc8Ki/OoUUclEgKthUoFLxnLGTrcloMOiI
Ti/QpjA7fd6419Rb11zvKzu59jW9jw82VETuATY+ITvVlCKZcd8qEF1CDWkw4ntX
4b6cHIEDjJUIfKA5iLRpLuH9v+waE28+RN8Gz3ObYKB/B+IG3UGkxhrzToMsIMIk
znzYQMp/lSQuk+KQgEXCVLFfFON29fbXnNOGFxOl9CmvCTAl8UxbsUXab/OpIcEU
btSNM/uGfkGLsFpySz7rGHgfCL6h4sUcuztv2yyKiPYEEefgYTCNBstRXoJIkfeO
gCoB4omVcy2WkI7esnx6+kqTmFNXW7LTlvvzVp+URaKjGxsUUv4=
=kF9I
-END PGP SIGNATURE-