Bug#884342: package builds with -march=k8 on amd64 and i386 (and everywhere else)

[Matthias Klose]

Package: src:patman
Version: 1.2.2+dfsg-1
Severity: serious
Tags: sid buster

the package builds with -march=k8 on amd64 and i386 (and everywhere else).

Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Andreas Tille]

On Thu, Dec 14, 2017 at 02:06:11AM +0100, Matthias Klumpp wrote:
> 2017-12-13 11:19 GMT+01:00 Andreas Tille :
> > control: tags -1 help
> >
> > I need to admit I have no idea how to proceed with this issue. :-(
> 
> Please try to package the latest version of undead, or - if that is
> not desired - request a rebuild of the package on the failing
> architectures.
> The library seems to have been compiled with an outdated LDC compiler there.

Its completely desired to follow upstream.  I just did not noticed
amongst all the other bugs I'm currently fixing in other packages.

Unfortunately it fails to build.  I'd be more than happy if you could
have a look at my latest Git commit.  It ends with:


...
[26/27] ldc2  -Iundead_test@exe -I. -I.. -I../src/ -enable-color -O -release -g 
-unittest  -of 'undead_test@exe/src_undead_stream.d.o' -c ../src/undead/stream.d
../src/undead/doformat.d(406): Deprecation: function std.utf.toUTF8 is 
deprecated - To be removed November 2017. Please use std.utf.encode instead.
../src/undead/doformat.d(406): Deprecation: function std.utf.toUTF8 is 
deprecated - To be removed November 2017. Please use std.utf.encode instead.
[27/27] ldc2  -of undead_test 'undead_test@exe/src_undead_stream.d.o' 
'undead_test@exe/src_undead_string.d.o' 
'undead_test@exe/src_undead_dateparse.d.o' 
'undead_test@exe/src_undead_regexp.d.o' 
'undead_test@exe/src_undead_doformat.d.o' 
'undead_test@exe/src_undead_cstream.d.o' 'undead_test@exe/src_undead_date.d.o' 
'undead_test@exe/src_undead_socketstream.d.o' 
'undead_test@exe/src_undead_datebase.d.o' 
'undead_test@exe/src_undead_metastrings.d.o' 
'undead_test@exe/src_undead_bitarray.d.o' 
'undead_test@exe/src_undead_internal_file.d.o' 'undead_test@exe/umain.d.o' -O 
-release -g -L-z -Lrelro  
FAILED: undead_test 
ldc2  -of undead_test 'undead_test@exe/src_undead_stream.d.o' 
'undead_test@exe/src_undead_string.d.o' 
'undead_test@exe/src_undead_dateparse.d.o' 
'undead_test@exe/src_undead_regexp.d.o' 
'undead_test@exe/src_undead_doformat.d.o' 
'undead_test@exe/src_undead_cstream.d.o' 'undead_test@exe/src_undead_date.d.o' 
'undead_test@exe/src_undead_socketstream.d.o' 
'undead_test@exe/src_undead_datebase.d.o' 
'undead_test@exe/src_undead_metastrings.d.o' 
'undead_test@exe/src_undead_bitarray.d.o' 
'undead_test@exe/src_undead_internal_file.d.o' 'undead_test@exe/umain.d.o' -O 
-release -g -L-z -Lrelro  
undead_test@exe/src_undead_stream.d.o: In function 
`_D6undead6stream6Stream16doFormatCallbackMFwZv':
/build/libundead-1.0.9/obj-x86_64-linux-gnu/../src/undead/stream.d:1217: 
undefined reference to `_D6undead3utf6toUTF8FNaNbNiNfNkJG4awZAa'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
ninja: build stopped: subcommand failed.
dh_auto_build: cd obj-x86_64-linux-gnu && ninja -j4 -v returned exit code 1


 
> As for the ppc64el version, it might not make sense to keep that
> around. Maybe rebuilding it on that arch will fix the issue though.
> How to proceed on the ppc64el arch support front is currently a bit
> unclear, because upstream doesn't really test that port:
> https://github.com/ldc-developers/ldc/issues/2356#issuecomment-350394691
> 
> I have a few ideas on how to address that issue potentially though (by
> using different D compilers for different architectures, for example,
> or by just removing the ppc64el port).

In practice most packages of Debian Med are used on amd64.  So for
practical usage this is possibly no real constraint.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#880743: [Pkg-nagios-devel] Bug#880743: nagios-plugins-contrib: check_ssl_cert can't use -servername option of openssl s_client

[Jan Wagner]

Hi Johan,

Am 14.12.17 um 02:13 schrieb Johan Fleury:
> Is there any chance to see this patch pushed to stable along with unstable?

from what I've seen the changes are too invasive to backport this to
stable. Anyway if anybody can come up with an isolated patch(set) we can
have a look if this can be integrated.

With kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#877716: [Aptitude-devel] Bug#877716: qalculate: Removing qalculate removes qalculate-gtk

[shirish शिरीष]

at bottom :-

On 14/12/2017, Manuel A. Fernandez Montecelo  wrote:
> Hi,
>
>
> (Thanks all for the input and for handling this).
>
>
> 2017-12-13 18:01 Axel Beckert:
>>Hi David,
>>
>>David Kalnischkies wrote:
>>> The autobit-moving happens for installed packages which change their
>>> section to one of the mentioned sections on upgrade. Such upgrades will
>>> remove the manual-installed marker from the now "oldlibs" package and
>>> move it to the dependencies so that the oldlibs package will be cleaned
>>> up automatically if nothing depends on it anymore – or if the user wants
>>> to keep it for whatever reason just has to tell apt once about it.
>>[…]
>>> But the setup in this bug is a new installation of the "oldlibs"
>>> package. There is no moving done here: Imagine installing libc5 to run
>>> some really old thingy and apt continuously nagging you to remove it
>>> because it happens to be in "oldlibs"… can't be done, hence the
>>> complicated one-time move on section-changing upgrades.
>
> (talking from the point of view of aptitude, not wanting to review what
> apt does or how oldlibs came to be)
>
> I understand that the behaviour described above was implemented to solve
> some problems or user complaints, but for me, singling out sections and
> having special rules doesn't make much sense, specially in the case of
> aptitude.
>
> If I see iceweasel as pulling firefox-esr and want to keep firefox, I
> unmark it as auto installed explicitly if necessary.
>
> IIRC there are similar discussions with metapackages from time to time
> -- "if I install meta-kde it pulls a bunch of dependencies, but then if
> I uninstall the metapackage, why is everything uninstalled?!?"
>
> If implemented in the other way, another person would say: "OMG, you
> force me to uninstall every single package that was installed by
> meta-kde, because when I uninstall meta-kde everything is kept!  Why do
> you force me to have to go through every single package?!!?  If I remove
> meta-kde is because I want all stuff pulled by it removed, dammit!!"
> (And this case doesn't account for what was once pulled in but it's not
> a dependency anymore".
>
> If I am not misremembering, I have seen similar discussions every now
> and then on debian-devel@, so for me it's an open question, and I don't
> like the package managers to try to be too clever in those cases -- at
> least in aptitude, it tries to help e.g. with the auto-installed and
> auto-removals, but it always puts the user in control.
>
> So for me, that aptitude already informs about removing both packages
> and asks for confirmation, is completely acceptable behaviour.
>
>
>>> So, at least from an apt PoV (and like aptitude as well) this works as
>>> intended although I see what you mean and agree that it is a bit sad
>>> that you have to explicitly tell your package manager that you want to
>>> keep qalculate-gtk after you figured out that you have needlessly
>>> installed qalculate,
>
> For me it's the other way around, I would wonder why it wants to keep
> qalculate-gtk installed when the only rdep is being removed -- for me,
> that qalculate is now in "oldlibs" is probably an irrelevant detail in
> most actual cases when I want something removed...
>
>>> but I don't see how we can improve this interaction
>>> without breaking (or annoying) other usecases [In an ideal world you
>>> would figure that out before installing qalculate as you are reading
>>> descriptions and co before installation of course] – if there are good
>>> ideas we could implement I would be happy to hear them!
>
> ... so yes, you would break my use-case, you evil person! :)
>
>
>>Manuel: In case you think we should nevertheless add support for
>>APT::Move-Autobit-Sections to aptitude (in case it's really not there
>>yet, e.g. through libapt*), feel free to reopen this bug report or
>>file a new one. (Or just implement it. ;-)
>
> As explained above I don't see a compelling case to do it, the only
> reason would be to match the behaviour of apt.
>
> But then again, that's why we have different package managers, isn't it?
>
> They don't need to be needlessly different, but I think that
> historically aptitude is definitely a package manager with attitude :-)
> , specially when it comes to put the user in control of what's
> installed, so from my side I'd prefer if it continues with the current
> behaviour.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 
>

Dear all,

Thank you all for your efforts. Have not been in the best of health
hence took time to reply. Just read the whole backlog.

I was honestly under the impression that transitional packages had no
business other than when packages need to be transitioned, especially
if packages needed to some kind of voodo, lock-step kind of upgrade
(have seen/done it few times and is somewhat scary when those messages
are seen but that's outside the purview of the issue above)

>From Manuel's 

Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling

[Boyuan Yang]

Package: qa.debian.org
Severity: minor

For any random page that shows the content of source code, there is an
unnecessary vertical scroll bar between the line number and the content of
source code. When the user put focus (e.g., by clicking the content of src),
the whole page will not be able to scroll up or down anymore till the user
moves the focus out the the webpage itself.

I believe we could eliminate the vertical scroll bar completely and solves this
problem.

I'm using Debian unstable with Firefox 57. I tested Chromium and the page on
Chromium seems don't get affected by the problem.



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

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

Bug#884340: Debian mirror mirror.waia.asn.au: no sensible dns

[Bastian Blank]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem may-auto-close
Control: submitter -1 mirr...@debian.org

Hi

You receive this mail because you are listed as contact for
  mirror.waia.asn.au

We recently detected that this mirror lacks a sufficently redundant DNS
infrastructure.  In violation to RFC 2182, section 3[1], both DNS
servers are located within the same network.

| ns1.waia.asn.au.7600IN  A   218.100.43.10
| ns2.waia.asn.au.3600IN  A   218.100.43.18

Please report back to use when and how you intend to fix this problem.

Regards,
Bastian Blank,
Debian mirror team

[1]: https://tools.ietf.org/html/rfc2182#section-3
-- 
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4

Bug#882743: Debian mirror ftp.cica.es: upstream mirror, large arch exclude list, ftpsync version

[Bastian Blank]

On Wed, Dec 13, 2017 at 10:29:06AM +0100, Soporte CICA wrote:
> El 07/12/17 a las 18:39, Bastian Blank escribió:
> > You excluded "source", which means you are violating the licenses of
> > half of the software in the Debian archive.
> > 
> > You still have pretty weird caching settings.  You provide the
> > update-in-progress marker to around 50% of the requests for hours:
> I think both problems should be solved now. Could you confirm?

It looks like this is fixed.

As your mirror is not pushed, please use the ftpsync-cron wrapper script
(or at least adjust the frequency to match the master at four times a
day).

Regards,
Bastian

-- 
Beam me up, Scotty!  It ate my phaser!

Bug#884339: RFS: deepin-movie-reborn/3.1.1-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "deepin-movie-reborn"

 * Package name: deepin-movie-reborn
   Version : 3.1.1-1
   Upstream Author : Deepin Technology Co., Ltd.
 * URL : https://www.deepin.org/
 * License : GPLv3
   Section : video

  It builds those binary packages:

deepin-movie - Deepin movie player
 libdmr-dev - Deepin movie player - widget library (development files)
 libdmr0.1  - Deepin movie player - widget library

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

  https://mentors.debian.net/package/deepin-movie-reborn


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/deepin-movie-reborn/deepin-movie-reborn_3.1.1-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  [your most recent changelog entry]


  Regards,
   Yangfl

Bug#862522: Plans

[Adam Cécile]

On 12/13/2017 10:49 PM, Andreas Beckmann wrote:

On 2017-12-13 22:30, Adam Cécile wrote:

Is there any plans to move forward regarding CUDA 9 ?

Packages are sitting in NEW.


Is it at possible I build myself the CUDA 9 packages; do you have some
ready somewhere ?

You can build them from GIT.


Andreas


Hello,


That's a very good news !

Do you have a link to this GIT repository or even more, could you put 
the awaiting source package available somewhere so I can build it directly ?



Thanks, Adam.

Bug#884067: GIO lists removable storage devices even after they have been unplugged when using Linux kernel v4.14

[Torbjörn Andersson]

This appears to be similar to bug #882353 ("nautilus: Phone does not 
disappear after disconnecting"). Sorry about the duplicate.


Torbjörn

Bug#882353: nautilus: Phone does not disappear after disconnecting

[Torbjörn Andersson]

This sounds like the same problem I'm seeing with Xfce's file manager, 
Thunar. I also saw it with PCManFM, but not with Dolphin, so I figured 
that GLib might be the involved.


I could also only reproduce the problem with Linux kernel 4.14, not 4.13.

But since I didn't notice this bug report then, I went ahead and filed 
bug #884067 ("GIO lists removable storage devices even after they have 
been unplugged when using Linux kernel v4.14"). Sorry about that.


Regards,

Torbjörn Andersson

Bug#877181: libwxgtk3.0-0v5: wxExecute fails with non-ascii characters

[Olly Betts]

Control: tags -1 - patch

On Fri, Sep 29, 2017 at 10:39:42PM +0100, Olly Betts wrote:
> Control: forwarded -1 https://trac.wxwidgets.org/ticket/16206
> 
> On Fri, Sep 29, 2017 at 05:02:55PM +0300, Guy Rutenberg wrote:
> > The fix is a simple one-line patch
> > (https://github.com/wxWidgets/wxWidgets/commit/704055f200d97f327a8ee5212762b41bf1d6d503)
> > which works for the current version (3.0.3.1) as well.

You says this works for 3.0.3.1, but upstream says:

| This is not trivial to backport, wxConvWhateverWorks doesn't exist in 3.0

And that indeed seems to be the case, so we don't actually have a patch
we can use, hence I've removed the "patch" tag.

Upstream are open to a patch which does backport this, but it's not a
one line change.  For more info, see:

https://trac.wxwidgets.org/ticket/16206#comment:10

Cheers,
Olly

Bug#884338: RFS: plasma-gmailfeed/1.1-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "plasma-gmailfeed"

Package name: plasma-gmailfeed
Version : 1.1-1
Upstream Author : Anthony Vital 
URL : https://github.com/anthon38/gmailfeed
License : GPL-3+
Section : kde

It builds this binary package:

plasma-gmailfeed - plasmoid that shows your Gmail feed with notifications

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

https://mentors.debian.net/package/plasma-gmailfeed

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/plasma-gmailfeed/plasma-gmailfeed_1.1-1.dsc

More information about hello can be obtained from 
https://github.com/anthon38/gmailfeed

Regards,
Nicholas D Steeves

Bug#884173: Solved-for-me

[Tollef Fog Heen]

Good catch Toote,

it went away when I manually removed the Signal extension it all works a
lot better (just mv-ed out of ~/.config/chromium/Default/Extensions).
If you use it, does it help for you as well?  Should extensions be able
to crash the browser? (Not sure if they can include native code.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884337: ITP: kio-gdrive -- KIO Slave to access Google Drive

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: kio-gdrive
Version : 1.2.1
Upstream Author : Name 
URL : http://www.example.org/
License : GPL-2+
Programming Lang: C++
Description : KIO Slave to access Google Drive

KIO GDrive is a KIO slave that enables KIO-aware applications (such as
Dolphin, Kate or Gwenview) to access and edit Google Drive files in
the cloud.

--

GNOME has had support for saving documents to Google Drive for some
time.  Now Plasma Desktop has this to!  I do not currently use this
software, but I am certain that I will use it, albeit casually.

I hope to maintain it as part of the pkg-kde-extras team, and I will
need a sponsor.

Sincerely,
Nicholas

Bug#884336: RFS: libsimpleini/4.17+dfsg-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

  Dear mentors,

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

 * Package name: libsimpleini
   Version : 4.17+dfsg-1
   Upstream Author : brofield
* URL : https://github.com/brofield/simpleini
  * License : MIT
   Section : libs

  It builds those binary packages:

libsimpleini-dev - Cross-platform C++ library for INI-style
configuration files (dev
 libsimpleini1 - Cross-platform C++ library for INI-style configuration files

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/libs/libsimpleini/libsimpleini_4.17+dfsg-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  [your most recent changelog entry]


  Regards,
   Yangfl

Bug#884335: network-manager: Network-Manager Fails to Start after update

[Jordan Waughtal]

Package: network-manager
Version: 1.6.2-3
Severity: important

Dear Maintainer,

   * I changed all my sources from jessie to stretch and updated. Upon a 
reboot, NetworkManager does not start.
 
   * I uninstalled the package, rebooted and reinstalled it.
   * I still get this:
 Dec 13 22:22:58 orangepione systemd[1]: Starting Network Manager...
-- Subject: Unit NetworkManager.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit NetworkManager.service has begun starting up.
Dec 13 22:22:58 orangepione systemd[27121]: NetworkManager.service: Failed at 
step NAMESPACE spawning /usr/sbin/Net
-- Subject: Process /usr/sbin/NetworkManager could not be executed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The process /usr/sbin/NetworkManager could not be executed and failed.
-- 
-- The error number returned by this process is 9.
Dec 13 22:22:58 orangepione systemd[1]: NetworkManager.service: Main process 
exited, code=exited, status=226/NAMESP
Dec 13 22:22:58 orangepione systemd[1]: Failed to start Network Manager.
-- Subject: Unit NetworkManager.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support

   * I was hoping it was an old config file causing the issue, so I thought a 
reinstall could fix the solution.



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.113-sun8i (SMP w/4 CPU cores; PREEMPT)
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)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.24-0+deb9u1
ii  init-system-helpers1.48
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2+deb9u1
ii  libc6  2.24-11+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u3
ii  libgudev-1.0-0 230-3
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.6.2-3
ii  libpam-systemd 232-25+deb9u1
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b3
ii  libsoup2.4-1   2.56.0-2+deb9u1
ii  libsystemd0232-25+deb9u1
ii  libteamdctl0   1.26-1+b1
ii  libuuid1   2.29.2-1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u1
ii  wpasupplicant  2:2.4-1+deb9u1

Versions of packages network-manager recommends:
ii  crda 3.18-1
pn  dnsmasq-base 
ii  iptables 1.6.0+snapshot20161117-6
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3
pn  modemmanager 
pn  ppp  

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#883751: RFS: deepin-calculator/1.0.1-1 [ITP]

[Yangfl]

Wired, I got lintian clean here...

Anyway, I'll manually check and reupload later.

Bug#884173: +1

[Matías Bellone]

This is happening on my installation as well.

After some light debugging I reached the same conclusions on this
thread. It has to do with extensions as running with
--disable-extensions doesn't cause it to crash. But, more
interestingly, if you close the browser running without extensions and
start chromium again as normal it works just fine for a while. But
when it crashes it will not start cleanly again until it is run
without extensions again at least once.

If I disable the native gnome extension (from package
chrome-gnome-shell) the crash still occurs. Trying to rule out if
there is any other particular extension I have installed that is
causing the issue (have 2 or 3 more).

Thanks for all your work.
Toote

Bug#884333: mesa: Since 17.3.0~rc5-1 GNOME 3.26.x login broken

[Marc Jeffrey Driftmeyer]

Source: mesa
Version: 17.3.0
Severity: normal

Dear Maintainer,

I upgraded from 17.2.5 after a failed test of the Experimental 17.3.0 branch 
release candidates hoping to see if this issue had been addressed, and it 
hasn't.

I had to downgrade to 17.2.5 to file this bug with GNOME 3.26.2 in Sid and the 
Mesa 17.3 branch giving the infamous Oops something went wrong logout continous 
retry phenomenom no one enjoys. Perhaps someone could think of logout turns 
into console login after 1 failed try?

At any rate, I just thought you might want to test this more thoroughly. I'll 
wait until a few more stable releases from Mesa are out before trying again.

Marc J. Driftmeyer

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

Kernel: Linux 4.14.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)

Bug#884332: cheese: could not generate thumbnail

[Jeremy Bicha]

On Wed, Dec 13, 2017 at 9:03 PM, Daniel Kahn Gillmor
 wrote:
> ** (cheese:25393): WARNING **: could not generate thumbnail for 
> /home/dkg/Pictures/Webcam/2017-12-13-205800.jpg (image/jpeg)

Do you have libgdk-pixbuf2.0-bin installed? It is a recommends of
libgdk-pixbuf2.0-0.

Thanks,
Jeremy Bicha

Bug#884227: debian-policy: please add zlib to common licenses

[Russ Allbery]

Jonathan Nieder  writes:
> Markus Koschany wrote:

>> License: zlib
>> Source: https://opensource.org/licenses/Zlib
>> Example packages:
>> https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29

> Hm.  The license says

>   3. This notice may not be removed or altered from any source distribution.

> And part of 'This notice' is a copyright line that varies from package
> to package.  Since the license text is very short, it seems simplest for
> packages to keep reproducing the license text --- it's not too painful
> disk space-wise and it is much clearer license-wise.

> So I don't believe it belongs in common-licenses.

I agree.  I don't like the idea of including very short licenses in
common-licenses.  I think it just adds indirection to no real purpose and
won't really save maintainers significant time.  I'm less opposed to this
one than to the MIT or BSD licenses that have substantial variation in
wording, but I still don't think it's a good idea.

common-licenses has the most benefit for very long licenses that people
then copy verbatim.

-- 
Russ Allbery (r...@debian.org)   

Bug#884332: cheese: could not generate thumbnail

[Daniel Kahn Gillmor]

Package: cheese
Version: 3.26.0-2
Severity: normal

When i take a picture with my webcam with cheese, it shows up in the
bottom bar as a generic icon, rather than as a thumbnail.

on stderr at the same time, cheese emits:

** (cheese:25393): WARNING **: could not generate thumbnail for 
/home/dkg/Pictures/Webcam/2017-12-13-205800.jpg (image/jpeg)

if i investigate the resulting image with GraphicsMagick, it doesn't
complain about any obvious problems:

$ gm identify -verbose /home/dkg/Pictures/Webcam/2017-12-13-205800.jpg
Image: /home/dkg/Pictures/Webcam/2017-12-13-205800.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Geometry: 1280x720
  Class: DirectClass
  Type: true color
  Depth: 8 bits-per-pixel component
  Channel Depths:
Red:  8 bits
Green:8 bits
Blue: 8 bits
  Channel Statistics:
Red:
  Minimum:  2056.00 (0.0314)
  Maximum: 63736.00 (0.9725)
  Mean:36876.51 (0.5627)
  Standard Deviation:  15328.91 (0.2339)
Green:
  Minimum:  4883.00 (0.0745)
  Maximum: 58339.00 (0.8902)
  Mean:34839.42 (0.5316)
  Standard Deviation:  13896.80 (0.2121)
Blue:
  Minimum:  6425.00 (0.0980)
  Maximum: 65535.00 (1.)
  Mean:38506.94 (0.5876)
  Standard Deviation:  13386.76 (0.2043)
  Filesize: 314.3Ki
  Interlace: No
  Orientation: Unknown
  Background Color: white
  Border Color: #DFDFDF
  Matte Color: #BDBDBD
  Page geometry: 1280x720+0+0
  Compose: Over
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  JPEG-Quality: 85
  JPEG-Colorspace: 2
  JPEG-Colorspace-Name: RGB
  JPEG-Sampling-factors: 1x1,1x1,1x1
  Signature: 30ad6206ccb4a32ca9aded5aff7d88b3b2d9d8b635f61930b3afd44c5fd841e4
  Profile-EXIF: 196 bytes
Model: Integrated Camera: Integrated C
Software: Cheese 3.26.0
Date Time: 2017:12:13 20:58:00
Exif Offset: 128
Exif Version: 0230
Date Time Original: 2017:12:13 20:58:00
Flash Pix Version: 0100
  Profile-XMP: 3053 bytes
  Tainted: False
  User Time: 0.020u
  Elapsed Time: 0m:0.014761s
  Pixels Per Second: 59.5Mi
$


I welcome any suggestions for further debugging.

  --dkg


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

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

Versions of packages cheese depends on:
ii  cheese-common  3.26.0-2
ii  gnome-video-effects0.4.3-1
ii  libc6  2.25-3
ii  libcanberra-gtk3-0 0.30-5
ii  libcheese-gtk253.26.0-2
ii  libcheese8 3.26.0-2
ii  libclutter-1.0-0   1.26.2+dfsg-3
ii  libclutter-gtk-1.0-0   1.8.4-2
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.1-1
ii  libgnome-desktop-3-12  3.26.2-1
ii  libgstreamer1.0-0  1.12.3-1
ii  libgtk-3-0 3.22.24-3

Versions of packages cheese recommends:
pn  gvfs  
pn  yelp  

Versions of packages cheese suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

Bug#882801: chromium: segfaults like crazy

[Clint Adams]

On Sat, Dec 09, 2017 at 05:52:16PM +0100, Pascal Obry wrote:
> Does it runs if started with --disable-extensions ?

Yes, it appears so.

Bug#880743: [Pkg-nagios-devel] Bug#880743: nagios-plugins-contrib: check_ssl_cert can't use -servername option of openssl s_client

[Johan Fleury]

Hi Jan,

Thank you for your answer !

Is there any chance to see this patch pushed to stable along with unstable?

-- 
Johan Fleury
PGP Key ID : 0x5D404386805E56E6

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

Bug#884331: python3-defaults: please update, as python3-distutils cannot install now

[YunQiang Su]

Package: python3-defaults
Version: 3.6.3-2
Severity: grave

python3-distutils depends on python3>=3.6.4~rc1,
while the current python3-default is still 3.6.3-2.

Please update the python3-defaults package.


-- 
YunQiang Su

Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Matthias Klumpp]

2017-12-13 11:19 GMT+01:00 Andreas Tille :
> control: tags -1 help
>
> I need to admit I have no idea how to proceed with this issue. :-(

Please try to package the latest version of undead, or - if that is
not desired - request a rebuild of the package on the failing
architectures.
The library seems to have been compiled with an outdated LDC compiler there.

As for the ppc64el version, it might not make sense to keep that
around. Maybe rebuilding it on that arch will fix the issue though.
How to proceed on the ppc64el arch support front is currently a bit
unclear, because upstream doesn't really test that port:
https://github.com/ldc-developers/ldc/issues/2356#issuecomment-350394691

I have a few ideas on how to address that issue potentially though (by
using different D compilers for different architectures, for example,
or by just removing the ppc64el port).

Cheers,
Matthias

Bug#859718: Please review patches for ssldump

[Hilko Bengen]

Control: tag -1 patch

I have prepared patches for ssldump to

(1) recognize OpenSSL 1.1 at configure time
(2) deal with API changes

Cheers,
-Hilko

Index: ssldump/configure.in
===
--- ssldump.orig/configure.in
+++ ssldump/configure.in
@@ -187,8 +187,13 @@ if test "$ac_use_openssl" != "false"; th
 		save_LDFLAGS=$LDFLAGS
 		LIBS="-lssl -lcrypto $LIBS"
 		LDFLAGS="-L$dir $LDFLAGS"
-		AC_TRY_LINK_FUNC(SSL_load_error_strings,ac_linked_libssl="true",
-			ac_linked_libssl="false");
+AC_TRY_LINK([
+#define OPENSSL_API_COMPAT 0x1000L
+#include 
+],
+[SSL_load_error_strings()],
+ac_linked_libssl="true",
+ac_linked_libssl="false");
 		AC_TRY_LINK_FUNC(RC4_set_key,ac_linked_libcrypto="true",
 			ac_linked_libcrypto="false");
 		if test "$ac_linked_libssl" != "false" -a \
Index: ssldump/ssl/ssl_rec.c
===
--- ssldump.orig/ssl/ssl_rec.c
+++ ssldump/ssl/ssl_rec.c
@@ -116,7 +116,7 @@ int ssl_create_rec_decoder(dp,cs,mk,sk,i
 dec->cs=cs;
 if(r=r_data_create(>mac_key,mk,cs->dig_len))
   ABORT(r);
-if(!(dec->evp=(EVP_CIPHER_CTX *)malloc(sizeof(EVP_CIPHER_CTX
+if(!(dec->evp=EVP_CIPHER_CTX_new()))
   ABORT(R_NO_MEMORY);
 EVP_CIPHER_CTX_init(dec->evp);
 EVP_CipherInit(dec->evp,ciph,sk,iv,0);
@@ -228,35 +228,35 @@ static int tls_check_mac(d,ct,ver,data,d
   UINT4 datalen;
   UCHAR *mac;
   {
-HMAC_CTX hm;
+HMAC_CTX *hm = HMAC_CTX_new();
 const EVP_MD *md;
 UINT4 l;
 UCHAR buf[20];
 
 md=EVP_get_digestbyname(digests[d->cs->dig-0x40]);
-HMAC_Init(,d->mac_key->data,d->mac_key->len,md);
+HMAC_Init(hm,d->mac_key->data,d->mac_key->len,md);
 
 fmt_seq(d->seq,buf);
 d->seq++;
-HMAC_Update(,buf,8);
+HMAC_Update(hm,buf,8);
 buf[0]=ct;
-HMAC_Update(,buf,1);
+HMAC_Update(hm,buf,1);
 
 buf[0]=MSB(ver);
 buf[1]=LSB(ver);
-HMAC_Update(,buf,2);
+HMAC_Update(hm,buf,2);
 
 buf[0]=MSB(datalen);
 buf[1]=LSB(datalen);
-HMAC_Update(,buf,2);
+HMAC_Update(hm,buf,2);
 
-HMAC_Update(,data,datalen);
+HMAC_Update(hm,data,datalen);
 
-HMAC_Final(,buf,);
+HMAC_Final(hm,buf,);
 if(memcmp(mac,buf,l))
   ERETURN(SSL_BAD_MAC);
 
-HMAC_cleanup();
+HMAC_CTX_free(hm);
 return(0);
   }
 
@@ -268,7 +268,7 @@ int ssl3_check_mac(d,ct,ver,data,datalen
   UINT4 datalen;
   UCHAR *mac;
   {
-EVP_MD_CTX mc;
+EVP_MD_CTX *mc = EVP_MD_CTX_new();
 const EVP_MD *md;
 UINT4 l;
 UCHAR buf[64],dgst[20];
@@ -277,42 +277,44 @@ int ssl3_check_mac(d,ct,ver,data,datalen
 pad_ct=(d->cs->dig==DIG_SHA)?40:48;
 
 md=EVP_get_digestbyname(digests[d->cs->dig-0x40]);
-EVP_DigestInit(,md);
+EVP_DigestInit(mc,md);
 
-EVP_DigestUpdate(,d->mac_key->data,d->mac_key->len);
+EVP_DigestUpdate(mc,d->mac_key->data,d->mac_key->len);
 
 memset(buf,0x36,pad_ct);
-EVP_DigestUpdate(,buf,pad_ct);
+EVP_DigestUpdate(mc,buf,pad_ct);
 
 fmt_seq(d->seq,buf);
 d->seq++;
-EVP_DigestUpdate(,buf,8);
+EVP_DigestUpdate(mc,buf,8);
 
 buf[0]=ct;
-EVP_DigestUpdate(,buf,1);
+EVP_DigestUpdate(mc,buf,1);
 
 buf[0]=MSB(datalen);
 buf[1]=LSB(datalen);
-EVP_DigestUpdate(,buf,2);
+EVP_DigestUpdate(mc,buf,2);
 
-EVP_DigestUpdate(,data,datalen);
+EVP_DigestUpdate(mc,data,datalen);
 
-EVP_DigestFinal(,dgst,);
+EVP_DigestFinal(mc,dgst,);
 
-EVP_DigestInit(,md);
+EVP_DigestInit(mc,md);
 
-EVP_DigestUpdate(,d->mac_key->data,d->mac_key->len);
+EVP_DigestUpdate(mc,d->mac_key->data,d->mac_key->len);
 
 memset(buf,0x5c,pad_ct);
-EVP_DigestUpdate(,buf,pad_ct);
+EVP_DigestUpdate(mc,buf,pad_ct);
 
-EVP_DigestUpdate(,dgst,l);
+EVP_DigestUpdate(mc,dgst,l);
 
-EVP_DigestFinal(,dgst,);
+EVP_DigestFinal(mc,dgst,);
 
 if(memcmp(mac,dgst,l))
   ERETURN(SSL_BAD_MAC);
 
+EVP_MD_CTX_free(mc);
+
 return(0);
   }
 
Index: ssldump/ssl/ssldecode.c
===
--- ssldump.orig/ssl/ssldecode.c
+++ ssldump/ssl/ssldecode.c
@@ -501,6 +501,7 @@ int ssl_process_client_key_exchange(ssl,
 int i;
 
 EVP_PKEY *pk;
+const BIGNUM *n;
 
 if(ssl->cs->kex!=KEX_RSA)
   return(-1);
@@ -512,14 +513,15 @@ int ssl_process_client_key_exchange(ssl,
 if(!pk)
   return(-1);
 
-if(pk->type!=EVP_PKEY_RSA)
+if(EVP_PKEY_id(pk)!=EVP_PKEY_RSA)
   return(-1);
  
-if(r=r_data_alloc(>PMS,BN_num_bytes(pk->pkey.rsa->n)))
+RSA_get0_key(EVP_PKEY_get0_RSA(pk), , NULL, NULL);
+if(r=r_data_alloc(>PMS,BN_num_bytes(n)))
   ABORT(r);
 
 i=RSA_private_decrypt(len,msg,d->PMS->data,
-  pk->pkey.rsa,RSA_PKCS1_PADDING);
+  

Bug#884330: mailman3-suite: sysv init fails restart for various reasons

[Stephen Rothwell]

Package: mailman3-suite
Version: 0+20170523-2
Severity: normal

Dear Maintainer,

The sysv init script will fail to do a stop or restart:

--die-on-term is passed to uwsgi, so a TERM signal is needed
to stop it instead of HUP
uwsgi takes some time to terminate, so a following start may fail
if it is still stopping
stop sill fail if uwsgi is not actually running (which makes
restart fail)

To fix all this, I changed do_stop to do:

start-stop-daemon --stop --quiet --oknodo --retry forever/TERM/5 \
--pidfile $PIDFILE --exec $DAEMON

The "forever" may not be a good choice ... maybe "TERM/5/KILL/5" or
some such would be better. And 5 seconds may also not be a good choice,
but it seems to work fairly well on my setup.

I am also not sure that the {forced-}reload actions are going to work.

Also, maybe start-stop-daemon is not needed for uwsgi as it seems to do
its own process management?

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

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

Versions of packages mailman3-suite depends on:
ii  dbconfig-pgsql2.0.9
ii  debconf [debconf-2.0] 1.5.65
ii  lsb-base  9.20170808
ii  mailman3-core 3.1.0-7
ii  node-less 1.6.3~dfsg-2
ii  python2.7.14-1
ii  python-django-hyperkitty  1.1.4-2
ii  python-django-postorius   1.1.0-1
ii  python-psycopg2   2.7.3-1
ii  python-whoosh 2.7.4+git6-g9134ad92-1
ii  ruby-sass 3.4.23-1
ii  ucf   3.0036
ii  uwsgi 2.0.15-10
ii  uwsgi-plugin-python   2.0.15-10

Versions of packages mailman3-suite recommends:
ii  libapache2-mod-proxy-uwsgi  2.0.15-10
ii  postgresql  10+188

mailman3-suite suggests no packages.

-- Configuration Files:
/etc/cron.d/mailman3-suite changed [not included]
/etc/init.d/mailman3-suite changed [not included]

-- debconf information:
  mailman3-suite/upgrade-error: abort
  mailman3-suite/install-error: abort
  mailman3-suite/remote/newhost: localhost
  mailman3-suite/restart-webserver: true
  mailman3-suite/pgsql/authmethod-user: password
  mailman3-suite/pgsql/no-empty-passwords:
  mailman3-suite/superuser-name: admin
  mailman3-suite/passwords-do-not-match:
  mailman3-suite/dbconfig-reinstall: false
  mailman3-suite/emailname: ozlabs.org
  mailman3-suite/internal/skip-preseed: false
  mailman3-suite/pgsql/admin-user: postgres
  mailman3-suite/remove-error: abort
  mailman3-suite/dbconfig-remove: true
  mailman3-suite/remote/port:
  mailman3-suite/superuser-mail: root@localhost
  mailman3-suite/pgsql/changeconf: false
  mailman3-suite/pgsql/manualconf:
  mailman3-suite/pgsql/method: TCP/IP
  mailman3-suite/reconfigure-webserver: apache2
  mailman3-suite/dbconfig-upgrade: true
  mailman3-suite/internal/reconfiguring: false
  mailman3-suite/upgrade-backup: true
  mailman3-suite/pgsql/authmethod-admin: ident
  mailman3-suite/database-type: pgsql
  mailman3-suite/db/app-user: mailman3suite@localhost
  mailman3-suite/purge: false
  mailman3-suite/missing-db-package-error: abort
  mailman3-suite/db/dbname: mailman3suite
* mailman3-suite/remote/host: localhost
* mailman3-suite/dbconfig-install: true


-- 
Cheers,
Stephen Rothwell

Bug#884008: [Filesystems-devel] Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[sfjro]

(removed aufs-users ML from Cc:)

Ralf Jung:
> Oh wow, that's a long list...

Thanx for the report, anyway.


> > - linux kernel version
> >   if your kernel is not plain, for example modified by distributor,
> >   the url where i can download its source is necessary too.
>
> Linux core.hacksaar.de 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03)
> x86_64 GNU/Linux
>
> The source download is at the bottom of
> 

Hmm, I checked linux-image-4.9.0-4-amd64 pkg and downloaded its
linux_4.9.65-3.debian.tar.xz, I could not find aufs source files.


> > - aufs version which was printed at loading the module or booting the
> >   system, instead of the date you downloaded.
>
> > Dez 10 12:10:24 core.hacksaar.de kernel: aufs: loading out-of-tree module 
> > taints kernel.
> > Dez 10 12:10:24 core.hacksaar.de kernel: aufs 4.9-20161219

While this version is very old (a year ago), the info is enough to
identify the source files (with assuming debian people didn't change
them).


> > S Sun Dec 10 12:10:27 2017 p4 kernel: WARNING: CPU: 0 PID: 1490 at 
> > /var/lib/dkms/aufs/4.9+20161219/build/fs/aufs/cpup.c:423 
> > au_cp_regular+0x16c/0x250 [aufs]
> > S Sun Dec 10 12:10:27 2017 p4 kernel: .wh..wh.setup_maker_elements-i.ri.0007
> > Please report this warning to aufs-users ML

This is an unexpected situation for aufs. It might be related to your
environment (xen domU?). The period (10sec) this warning is appearing,
the performance of the internal file-close operation may get worse a
little bit. But it is harmless. You can ignore this warning safely.

I know it must be annoying for you, and I am going to comment it out in
next release. Your report is helpful for me to know the case where this
warning appears.


By the way, I see all your branches are under "/dev/xvda1
/var/lib/docker/aufs ext4", it is ok. But what for is
"shm /var/lib/docker/containers/2b0cb..."?
Is it totally unused?


--
From: Ralf Jung 
Date: Wed, 13 Dec 2017 22:54:08 +0100

FWIW, my message got rejected from aufs-users.  I'm not really
interested in receiving that list, is there no other way to report a bug?

aufs-users ML is members only. I expect you to join the ML before you
post. I can understand you don't want to. And... there is no other way,
sorry.


Thank you
J. R. Okajima

Bug#883858: closed by Adrian Bunk <b...@debian.org> (Bug#883858: fixed in libunwind 1.2.1-4)

[Jason Duerstock]

One tiny mishap: src/ia64/mk_cursor_i needs to be chmod 755.

Sorry for the oversight.

On Wed, Dec 13, 2017 at 4:09 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the src:libunwind package:
>
> #883858: libunwind FTBFS on ia64
>
> It has been closed by Adrian Bunk .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Adrian Bunk <
> b...@debian.org> by
> replying to this email.
>
>
> --
> 883858: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883858
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: 883858-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 13 Dec 2017 21:06:50 +
> Subject: Bug#883858: fixed in libunwind 1.2.1-4
> Source: libunwind
> Source-Version: 1.2.1-4
>
> We believe that the bug you reported is fixed in the latest version of
> libunwind, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 883...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Adrian Bunk  (supplier of updated libunwind package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Wed, 13 Dec 2017 20:24:14 +0200
> Source: libunwind
> Binary: libunwind-dev libunwind8 libunwind-setjmp0-dev libunwind-setjmp0
> Architecture: source
> Version: 1.2.1-4
> Distribution: unstable
> Urgency: low
> Maintainer: Adrian Bunk 
> Changed-By: Adrian Bunk 
> Description:
>  libunwind-dev - library to determine the call-chain of a program -
> development
>  libunwind-setjmp0 - libunwind-based non local goto - runtime
>  libunwind-setjmp0-dev - libunwind-based non local goto - development
>  libunwind8 - library to determine the call-chain of a program - runtime
> Closes: 883858 883861
> Changes:
>  libunwind (1.2.1-4) unstable; urgency=low
>  .
>* Add upstream fix for FTBFS with glibc 2.26. (Closes: #883861)
>* Add ia64 fixes from Jason Duerstock. (Closes: #883858)
> Checksums-Sha1:
>  48fb29a5657cd6711b24012295f68cd57409f196 2527 libunwind_1.2.1-4.dsc
>  a1306ae056db2a1ee856e663af6923aaede489f7 16924
> libunwind_1.2.1-4.debian.tar.xz
> Checksums-Sha256:
>  186344c9e538799d02ae70d11dff092c3816670047e055b1669a2efcfa99cf3f 2527
> libunwind_1.2.1-4.dsc
>  c815d14740ed8bc82bbfc1b36cc81686fa2ee46af137da74b91fd49d177b47f6 16924
> libunwind_1.2.1-4.debian.tar.xz
> Files:
>  5a288e9e0f1915b25606475c5ba360f2 2527 libs optional libunwind_1.2.1-4.dsc
>  e374e961cefde4ff2abb927765d8b95d 16924 libs optional
> libunwind_1.2.1-4.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAloxggwACgkQiNJCh6LY
> mLE6hw/+JyDiuEONqauhYdleV9/ckD893smBEV3H4bq+ZE28x7PpLHcB3xuVUZvu
> cP8U9vgv7J5tniBuT+ypB2u7ylTGW5qclot6Ka6XRHNVpQ+DsfO/FNTen2dfUHwK
> M6baQ+F57AIRQUaMy0pqHLlFHJIoaluszfYl1/lUmaJTq/jLkqwqSV4yViKnYGeA
> o1KjEpxaAWWWlCzKsPaOpbjQIdcEcW6CjZUkM8ujQ7SSAEiZ37z6uVr94itplO/T
> oNfRdyH/e8av0EpwE1A9fX8WpN7rXwHVBGAMTZpnz938aQGG/0TwlN5OnXNEie4o
> 7a1LNplxdWiOUZNWBkne+BhWWEKw0Lff2yZ9GifoOcMaYcSrcLESSmytpYKeyDBm
> bya1DzjrpOOzLyjSTjBxZS7jWj+3pO5CpdXt5Dk9OZyPgNXY9HEEY+T8y+FHI+KT
> OX6HaZ1uvo6cFZ2qPSNwx9IGL0b0LAflktVqWgiHIiaJvw/3HjAi3mtFa3dqs4VB
> 22pvQmtKyceDdTX7ZYRok0VKpanYivkDEbWZD7z/Zsva/HObHCrTFUC53wvRbhy8
> 6CFansCbLgTeX8GEn+hkpoowUV9JTb59bFYWjBl0AKUSPjEWd3EcfIx7dyFiwVH6
> 5NltwnjYTVeZkyoU4of6QiRrAkremGliZZp6WdWx1didwWeaRYQ=
> =Pznf
> -END PGP SIGNATURE-
>
> -- Forwarded message --
> From: Jason Duerstock 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 08 Dec 2017 06:56:05 -0500
> Subject: libunwind FTBFS on ia64
> Source: libunwind
> Severity: normal
>
> Dear Maintainer,
>
> It appears as though some files went missing from libunwind between 1.1
> and 1.2.  It now fails to build from source:
>
> make[1]: Leaving directory '/mnt/a/sid/libunwind-1.2.1'
>dh_auto_build
> make -j2
> make[1]: Entering directory '/mnt/a/sid/libunwind-1.2.1'
> Making all in src
> make[2]: Entering directory '/mnt/a/sid/libunwind-1.2.1/src'
> make[2]: *** No rule to make target 'ia64/mk_Gcursor_i.c', needed by
> 'mk_Gcursor_i.s'.  Stop.
> make[2]: Leaving directory '/mnt/a/sid/libunwind-1.2.1/src'
> 

Bug#884319: Networking shutdown before NFS unmount on shutdown or reboot

[Michael Biebl]

Am 14.12.2017 um 00:09 schrieb Michael Biebl:
> Am 13.12.2017 um 22:04 schrieb Peter 'p2' De Schrijver:
>> On 2017-12-13 21:53:10 (+0100), Michael Biebl  wrote:
>>> Control: tags -1 + moreinfo

>> NFS mount is just done manually:
>>
>> mount freenas:/mnt/storage /nfs/
>> mount freenas:/mnt/storage/p2_home/ /nfs/p2_home/
> 
> What's the systemctl status and systemctl show output for these mount
> points?

We will need a systemd-analyze dump output and a verbose debug log from
shutdown.
See /usr/share/doc/systemd/README.Debian.gz on how to generate a debug
log on shutdown.


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



signature.asc
Description: OpenPGP digital signature

Bug#877716: [Aptitude-devel] Bug#877716: qalculate: Removing qalculate removes qalculate-gtk

[Manuel A. Fernandez Montecelo]

Hi,


(Thanks all for the input and for handling this).


2017-12-13 18:01 Axel Beckert:

Hi David,

David Kalnischkies wrote:

The autobit-moving happens for installed packages which change their
section to one of the mentioned sections on upgrade. Such upgrades will
remove the manual-installed marker from the now "oldlibs" package and
move it to the dependencies so that the oldlibs package will be cleaned
up automatically if nothing depends on it anymore – or if the user wants
to keep it for whatever reason just has to tell apt once about it.

[…]

But the setup in this bug is a new installation of the "oldlibs"
package. There is no moving done here: Imagine installing libc5 to run
some really old thingy and apt continuously nagging you to remove it
because it happens to be in "oldlibs"… can't be done, hence the
complicated one-time move on section-changing upgrades.


(talking from the point of view of aptitude, not wanting to review what
apt does or how oldlibs came to be)

I understand that the behaviour described above was implemented to solve
some problems or user complaints, but for me, singling out sections and
having special rules doesn't make much sense, specially in the case of
aptitude.

If I see iceweasel as pulling firefox-esr and want to keep firefox, I
unmark it as auto installed explicitly if necessary.

IIRC there are similar discussions with metapackages from time to time
-- "if I install meta-kde it pulls a bunch of dependencies, but then if
I uninstall the metapackage, why is everything uninstalled?!?"

If implemented in the other way, another person would say: "OMG, you
force me to uninstall every single package that was installed by
meta-kde, because when I uninstall meta-kde everything is kept!  Why do
you force me to have to go through every single package?!!?  If I remove
meta-kde is because I want all stuff pulled by it removed, dammit!!"
(And this case doesn't account for what was once pulled in but it's not
a dependency anymore".

If I am not misremembering, I have seen similar discussions every now
and then on debian-devel@, so for me it's an open question, and I don't
like the package managers to try to be too clever in those cases -- at
least in aptitude, it tries to help e.g. with the auto-installed and
auto-removals, but it always puts the user in control.

So for me, that aptitude already informs about removing both packages
and asks for confirmation, is completely acceptable behaviour.



So, at least from an apt PoV (and like aptitude as well) this works as
intended although I see what you mean and agree that it is a bit sad
that you have to explicitly tell your package manager that you want to
keep qalculate-gtk after you figured out that you have needlessly
installed qalculate,


For me it's the other way around, I would wonder why it wants to keep
qalculate-gtk installed when the only rdep is being removed -- for me,
that qalculate is now in "oldlibs" is probably an irrelevant detail in
most actual cases when I want something removed...


but I don't see how we can improve this interaction
without breaking (or annoying) other usecases [In an ideal world you
would figure that out before installing qalculate as you are reading
descriptions and co before installation of course] – if there are good
ideas we could implement I would be happy to hear them!


... so yes, you would break my use-case, you evil person! :)



Manuel: In case you think we should nevertheless add support for
APT::Move-Autobit-Sections to aptitude (in case it's really not there
yet, e.g. through libapt*), feel free to reopen this bug report or
file a new one. (Or just implement it. ;-)


As explained above I don't see a compelling case to do it, the only
reason would be to match the behaviour of apt.

But then again, that's why we have different package managers, isn't it?

They don't need to be needlessly different, but I think that
historically aptitude is definitely a package manager with attitude :-)
, specially when it comes to put the user in control of what's
installed, so from my side I'd prefer if it continues with the current
behaviour.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#884329: zfs-dkms: Please Upgrade ZFS on Linux to 0.7.4

[Niklas Wagner]

Package: zfs-dkms
Version: 0.7.3-3
Severity: normal

Dear Maintainer,

could you upgrade zfs-linux to the latest release (0.7.4) as you can see here: 
https://github.com/zfsonlinux/zfs/releases


Thanks!


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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  dkms   2.3-3
ii  lsb-release9.20170808
ii  spl-dkms   0.7.3-1

Versions of packages zfs-dkms recommends:
ii  zfs-zed 0.7.3-3
ii  zfsutils-linux  0.7.3-3

zfs-dkms suggests no packages.

-- debconf information excluded

Bug#853783: Reopen 853783

[Brian Potkin]

On Wed 13 Dec 2017 at 22:17:27 +0100, Svante Signell wrote:

> reopen 853783
> thanks
> 
> Since I have not obtained a mail from you about the scanner problems since 
> Tue,
> 28 Feb 2017 I reopen this bug. Your replies have not reached me. And you 
> cannot 
> expect me to look at the web page for all bugs I've submitted.
> 
> I see that my email address, and the bug number is on the mail from Wed, 22 
> Nov
> 2017 but I have never seen that mail, honestly. Neither did I get the mails 
> from
> Thu, 17 Aug 2017 or Thu, 15 Jun 2017, Wed, 14 Jun 2017. Was the bug submitter
> mail address change? I did not get any mails since the mail from Martin Heine
> Wed, 14 Jun 2017.

Svante, I do not think either of us will get any traction on this bug by
spending our time looking at the email record. I'll just mention that
the one on Thu, 17 Aug 2017 has you in the Cc:.

I assume scanning is still not working for you, so I'll re-read all the
mails tomorrow and try to think of some strategy. Meanwhile, you've
installed the plugin?

Regards,

Brian.

Bug#884327: clang-format-3.8: man page contains spurious error text

[Roberto C. Sanchez]

Package: clang-format-3.8
Version: 1:3.8.1-25
Severity: minor

The clang-format-3.8(1) man page has this error text near the top:

   ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be pre‐
   loaded (cannot open shared object file): ignored.  OVERVIEW:  A  tool  to
 
Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#174145: AZERTY

[alvis hilbasin attorney]

[image: Inline image 1]

Bug#884328: nagios-plugins-contrib: check_running_kernel checks against recent installed kernel file

[Jan Wagner]

Package: nagios-plugins-contrib
Version: 21.20170222
Severity: normal

Running this on recent Debian Jessie (with installed linux-image from
Jessie AND Wheezy) results into the following:

# /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux
version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) !=
Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.96-2]

# ls -la /boot/vmlinuz*
-rw-r--r-- 1 root root 3129104 Sep 19 17:11 /boot/vmlinuz-3.16.0-4-amd64
-rw-r--r-- 1 root root 2854496 Dec 10 18:24 /boot/vmlinuz-3.2.0-4-amd64
# uname -s -r -v
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

So it reports that the running 3.16.0-4-amd64 does not match the
recently installed 3.2.0-4-amd64. Indeed this it totally true, but I
guess this is nobody caring, cause in such a situation it would be
expected nobody wants to boot and run the 3.2.0 kernel.

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#884319: Networking shutdown before NFS unmount on shutdown or reboot

[Michael Biebl]

Am 13.12.2017 um 22:04 schrieb Peter 'p2' De Schrijver:
> On 2017-12-13 21:53:10 (+0100), Michael Biebl  wrote:
>> Control: tags -1 + moreinfo
>>
>>
>> Am 13.12.2017 um 21:32 schrieb Peter De Schrijver:
>>> Package: systemd
>>> Version: 235-2
>>> Severity: important
>> Please include more information about your network setup.
>> What tools do you use (NM, ifupdown, networkd), what configuration
> 
> ifupdown



>> (ethernet, wifi, dhcp, static), how does your nfs mount configuration
> 
> Ethernet and OVS
> 
>> look like (your fstab contains no information in that regard)
>>
> 
> NFS mount is just done manually:
> 
> mount freenas:/mnt/storage /nfs/
> mount freenas:/mnt/storage/p2_home/ /nfs/p2_home/

What's the systemctl status and systemctl show output for these mount
points?



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



signature.asc
Description: OpenPGP digital signature

Bug#884326: mailman3-suite: sysv init script uses incorrect PIDFILE name

[Stephen Rothwell]

Package: mailman3-suite
Version: 0+20170523-2
Severity: normal

Dear Maintainer,

I was investigating other problems and noticed that the PIDFILE was just
called ".pid" - it should be called "mailman3-suite.pid"

I moved the definition of NAME in the init script earlier (up near
the definition of DAEMON).

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

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

Versions of packages mailman3-suite depends on:
ii  dbconfig-pgsql2.0.9
ii  debconf [debconf-2.0] 1.5.65
ii  lsb-base  9.20170808
ii  mailman3-core 3.1.0-7
ii  node-less 1.6.3~dfsg-2
ii  python2.7.14-1
ii  python-django-hyperkitty  1.1.4-2
ii  python-django-postorius   1.1.0-1
ii  python-psycopg2   2.7.3-1
ii  python-whoosh 2.7.4+git6-g9134ad92-1
ii  ruby-sass 3.4.23-1
ii  ucf   3.0036
ii  uwsgi 2.0.15-10
ii  uwsgi-plugin-python   2.0.15-10

Versions of packages mailman3-suite recommends:
ii  libapache2-mod-proxy-uwsgi  2.0.15-10
ii  postgresql  10+188

mailman3-suite suggests no packages.

-- Configuration Files:
/etc/cron.d/mailman3-suite changed [not included]
/etc/init.d/mailman3-suite changed [not included]

-- debconf information:
  mailman3-suite/upgrade-error: abort
  mailman3-suite/pgsql/no-empty-passwords:
  mailman3-suite/missing-db-package-error: abort
  mailman3-suite/internal/skip-preseed: false
  mailman3-suite/db/app-user: mailman3suite@localhost
  mailman3-suite/pgsql/authmethod-user: password
* mailman3-suite/dbconfig-install: true
  mailman3-suite/database-type: pgsql
  mailman3-suite/superuser-name: admin
  mailman3-suite/restart-webserver: true
  mailman3-suite/dbconfig-remove: true
* mailman3-suite/remote/host: localhost
  mailman3-suite/passwords-do-not-match:
  mailman3-suite/remote/newhost: localhost
  mailman3-suite/pgsql/method: TCP/IP
  mailman3-suite/pgsql/admin-user: postgres
  mailman3-suite/remove-error: abort
  mailman3-suite/purge: false
  mailman3-suite/superuser-mail: root@localhost
  mailman3-suite/emailname: ozlabs.org
  mailman3-suite/pgsql/manualconf:
  mailman3-suite/install-error: abort
  mailman3-suite/upgrade-backup: true
  mailman3-suite/internal/reconfiguring: false
  mailman3-suite/dbconfig-reinstall: false
  mailman3-suite/pgsql/changeconf: false
  mailman3-suite/reconfigure-webserver: apache2
  mailman3-suite/pgsql/authmethod-admin: ident
  mailman3-suite/db/dbname: mailman3suite
  mailman3-suite/remote/port:
  mailman3-suite/dbconfig-upgrade: true


-- 
Cheers,
Stephen Rothwell

Bug#883529: ITA: buildbot,buildbot-slave -- Build automation system

[Robin Jarry]

retitle 883529 ITA: buildbot,buildbot-slave -- Build automation system
owner 883529 !
thanks

Hi,

I am willing to adopt both buildbot and buildbot-slave (which should maybe
be renamed to buildbot-worker).

Cheers,

-- 
Robin

Bug#878966: [Pkg-nagios-devel] Bug#878966: nagios-plugins-contrib FTBFS with libvarnishapi-dev 5.2.0-1

[Jan Wagner]

Am 18.10.17 um 08:20 schrieb Adrian Bunk:
> ...
> check_varnish.c: In function 'check_stats_cb':
> check_varnish.c:193:33: error: 'const struct VSC_point' has no member named 
> 'section'
>   assert(sizeof(tmp) > (strlen(pt->section->fantom->type) + 1 +
>  ^
> check_varnish.c:194:19: error: 'const struct VSC_point' has no member named 
> 'section'
>   strlen(pt->section->fantom->ident) + 1 +
>^
> check_varnish.c:195:21: error: 'const struct VSC_point' has no member named 
> 'desc'; did you mean 'sdesc'?
>   strlen(pt->desc->name) + 1));
>  ^
> ...

looks like #879471 is the problem.



signature.asc
Description: OpenPGP digital signature

Bug#884325: mailman3-suite: sysv init fails restart due to missing continuation

[Stephen Rothwell]

Package: mailman3-suite
Version: 0+20170523-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Installing mailman3-suite

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

aptitude install mailman3-suite

   * What was the outcome of this action?

[] Restarting Mailman3 suite uWSGI service: 
mailman3-suitestart-stop-daemon: need at least one of --exec, --pid, --ppid, 
--pidfile, --user or --name
Try 'start-stop-daemon --help' for more information.
/etc/init.d/mailman3-suite: 43: /etc/init.d/mailman3-suite: --pidfile: not found
 failed!
invoke-rc.d: initscript mailman3-suite, action "restart" failed.

   * What outcome did you expect instead?

install success

I fixed up the init script (/etc/init.d/mailman3-suite) by adding a
'\' to the end of the start-stop-daemon line in do_stop()

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

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

Versions of packages mailman3-suite depends on:
ii  dbconfig-pgsql2.0.9
ii  debconf [debconf-2.0] 1.5.65
ii  lsb-base  9.20170808
ii  mailman3-core 3.1.0-7
ii  node-less 1.6.3~dfsg-2
ii  python2.7.14-1
ii  python-django-hyperkitty  1.1.4-2
ii  python-django-postorius   1.1.0-1
ii  python-psycopg2   2.7.3-1
ii  python-whoosh 2.7.4+git6-g9134ad92-1
ii  ruby-sass 3.4.23-1
ii  ucf   3.0036
ii  uwsgi 2.0.15-10
ii  uwsgi-plugin-python   2.0.15-10

Versions of packages mailman3-suite recommends:
ii  libapache2-mod-proxy-uwsgi  2.0.15-10
ii  postgresql  10+188

mailman3-suite suggests no packages.

-- Configuration Files:
/etc/cron.d/mailman3-suite changed [not included]
/etc/init.d/mailman3-suite changed [not included]

-- debconf information:
  mailman3-suite/db/app-user: mailman3suite@localhost
  mailman3-suite/internal/skip-preseed: false
  mailman3-suite/database-type: pgsql
  mailman3-suite/db/dbname: mailman3suite
  mailman3-suite/pgsql/method: TCP/IP
  mailman3-suite/remote/newhost: localhost
  mailman3-suite/pgsql/changeconf: false
  mailman3-suite/pgsql/no-empty-passwords:
  mailman3-suite/dbconfig-reinstall: false
  mailman3-suite/pgsql/manualconf:
  mailman3-suite/pgsql/authmethod-admin: ident
  mailman3-suite/install-error: abort
  mailman3-suite/remove-error: abort
  mailman3-suite/upgrade-error: abort
  mailman3-suite/reconfigure-webserver: apache2
* mailman3-suite/dbconfig-install: true
  mailman3-suite/pgsql/admin-user: postgres
* mailman3-suite/remote/host: localhost
  mailman3-suite/missing-db-package-error: abort
  mailman3-suite/passwords-do-not-match:
  mailman3-suite/remote/port:
  mailman3-suite/emailname: ozlabs.org
  mailman3-suite/superuser-mail: root@localhost
  mailman3-suite/restart-webserver: true
  mailman3-suite/pgsql/authmethod-user: password
  mailman3-suite/upgrade-backup: true
  mailman3-suite/dbconfig-upgrade: true
  mailman3-suite/purge: false
  mailman3-suite/dbconfig-remove: true
  mailman3-suite/superuser-name: admin
  mailman3-suite/internal/reconfiguring: false


-- 
Cheers,
Stephen Rothwell

Bug#884324: segfault with `neomutt -a $file'

[Sebastian Andrzej Siewior]

Source: neomutt
Version: 20171208+dfsg.1-1
Severity: Important

I tried
neomutt -a $file
it then prompts for To:, Subject: and opens $EDITOR. After that I tell
it send. Neomutt saves the email in the `Sent' folder and crashes then:

|-- NeoMutt: Compose  [Approx. msg size: 15K   Atts: 2]--
|Uploading message... 0K/16K (0%)
|Program received signal SIGSEGV, Segmentation fault.
|0x555f6ba8 in mutt_write_fcc (path=path@entry=0x7fffad40 
"imaps://server/Sent", hdr=hdr@entry=0x559b6c60, msgid=msgid@entry=0x0, 
post=post@entry=0,
|fcc=fcc@entry=0x0, finalpath=finalpath@entry=0x7fffb028) at 
../sendlib.c:3146
|3146../sendlib.c: No such file or directory.
|(gdb) bt
|#0  0x555f6ba8 in mutt_write_fcc (path=path@entry=0x7fffad40 
"imaps://server/Sent", hdr=hdr@entry=0x559b6c60, msgid=msgid@entry=0x0, 
post=post@entry=0,
|fcc=fcc@entry=0x0, finalpath=finalpath@entry=0x7fffb028) at 
../sendlib.c:3146
|#1  0x555f715f in mutt_write_multiple_fcc 
(path=path@entry=0x7fffb0d0 "imaps://server/Sent", hdr=0x559b6c60, 
msgid=msgid@entry=0x0, post=post@entry=0,
|fcc=fcc@entry=0x0, finalpath=finalpath@entry=0x7fffb028) at 
../sendlib.c:2915
|#2  0x555eec73 in ci_send_message (flags=, 
msg=, tempfile=, ctx=, 
cur=) at ../send.c:2091
|#3  0x5556f39f in main (argc=, argv=0x7fffdec8, 
env=) at ../main.c:774
|(gdb) p Context
|$1 = (struct Context *) 0x0

The email is not sent.

Sebastian

Bug#844303: Working on it porting ncrack to OpenSSL 1.1

[Hilko Bengen]

Control: tag -1 help patch

I have submitted two patches upstream:

(1) https://github.com/nmap/ncrack/pull/34 contains a simple patch for
opensshlib/configure.ac that sets OPENSSL_API_COMPAT in the various
test programs, enabling compatibility macros for deprecated function
names such as SSLeay_version().

(2) https://github.com/nmap/ncrack/pull/35 contains the commit that
enables building with OpenSSL 1.1, by applying many changes that
replace direct struct access with getter/setter functions.

Unfortunately, the ncrack sources seem to contain no automated tests.
Any advice on how to test the affected bits of the code is appreciated.

Cheers,
-Hilko

Bug#880337: [pkg-php-pear] Bug#880337: php-sabre-vobject-3: diff for NMU version 3.5.2-1.1

[David Prévot]

Hi Adrian,

Le 13/12/2017 à 09:27, Adrian Bunk a écrit :

> I've prepared an NMU for php-sabre-vobject-3 (versioned as 3.5.2-1.1) 
> and uploaded it to DELAYED/14. Please feel free to tell me if I should 
> cancel it.

Since this package was introduced as an ownCloud dependency (removed
from Debian for a while now), I’d rather see this package removed from
the archive, unless you have a real interest into it (then feel free to
take up the maintainership). php-sabre-vobject is already in Debian
(even if this is the version in Sid is quite old).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#884323: qemu: QEMU process rapidly consuming host memory, leads to the host freezing

[Đorđe Kasagić]

Package: qemu
Version: 1:2.8+dfsg-6+deb9u3
Severity: normal

Dear Maintainer,

I have a Xubuntu VM running on QEMU (with the AQEMU GUI), and this problem
has occured multiple times while doing a dist-upgrade on the guest.

The guest is configured to only have 1GB of memory available (out of the 8GB
available to the host), but during a dist-upgrade, the QEMU process is using
far more than that. On one occasion, I have monitored the process and seen the
memory used increase from 1GB to 6GB+ in a matter of seconds before manually
terminating it. I have not noticed this during normal upgrades.

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

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

Versions of packages qemu depends on:
ii  qemu-system  1:2.8+dfsg-6+deb9u3
ii  qemu-user1:2.8+dfsg-6+deb9u3
ii  qemu-utils   1:2.8+dfsg-6+deb9u3

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  

-- no debconf information

Bug#882142: fixed in pulseaudio 11.1-3

[julien forest]

I can not understand how such a patch can solve the problem ! 

The add of libpam-systemd as a recommendation does not solve anything
for anyone not installing recommendations.

Furthermore, for those who do not want (can not) use systemd (or
at least libpam-systemd),this not solve anything.

Maybe the solution is to create a dependency to one of two subpackages
(libpulse0-libpam and libpulse0-nolibpam for example). The first one
should add the file /etc/pulse/client.conf.d/00-disable-autospawn.conf
as now while the second-one should add the following version of the
same file: 
"# On linux systems, disable autospawn by default
# If you are not using systemd, comment out this line
autospawn=yes
". 

Then libpulse0-libpam should depend on libpam-systemd while
libpul$se0-nolibpam conflicts with it. 

Best regards, 

Julien


On Sat, 25 Nov 2017 15:11:18 + Felipe Sateler 
wrote:
> Source: pulseaudio
> Source-Version: 11.1-3
> 
> We believe that the bug you reported is fixed in the latest version of
> pulseaudio, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 882...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Felipe Sateler  (supplier of updated pulseaudio
> package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Sat, 25 Nov 2017 10:35:47 -0300
> Source: pulseaudio
> Binary: pulseaudio pulseaudio-utils pulseaudio-esound-compat
> pulseaudio-module-zeroconf pulseaudio-module-jack
> pulseaudio-module-lirc pulseaudio-module-gconf pulseaudio-module-raop
> pulseaudio-module-bluetooth pulseaudio-equalizer libpulse0
> libpulse-mainloop-glib0 libpulse-dev libpulsedsp Architecture: source
> Version: 11.1-3 Distribution: unstable Urgency: medium Maintainer:
> Pulseaudio maintenance team
>  Changed-By: Felipe
> Sateler  Description: libpulse-dev - PulseAudio
> client development headers and libraries libpulse-mainloop-glib0 -
> PulseAudio client libraries (glib support) libpulse0  - PulseAudio
> client libraries libpulsedsp - PulseAudio OSS pre-load library
>  pulseaudio - PulseAudio sound server
>  pulseaudio-equalizer - Equalizer sink module for PulseAudio sound
> server pulseaudio-esound-compat - PulseAudio ESD compatibility layer
>  pulseaudio-module-bluetooth - Bluetooth module for PulseAudio sound
> server pulseaudio-module-gconf - GConf module for PulseAudio sound
> server pulseaudio-module-jack - jackd modules for PulseAudio sound
> server pulseaudio-module-lirc - lirc module for PulseAudio sound
> server pulseaudio-module-raop - RAOP module for PulseAudio sound
> server pulseaudio-module-zeroconf - Zeroconf module for PulseAudio
> sound server pulseaudio-utils - Command line tools for the PulseAudio
> sound server Closes: 882142
> Changes:
>  pulseaudio (11.1-3) unstable; urgency=medium
>  .
>* Use dh_missing instead of dh_install --fail-missing
>* We don't need root to build, so tell dpkg about that with
>  Rules-Require-Root: no
>* Add Recommends: libpam-systemd because otherwise user instances
> are not started (Closes: #882142)
>* Bump Standards-Version (no changes needed)

Bug#884008: [Filesystems-devel] Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[Ralf Jung]

FWIW, my message got rejected from aufs-users.  I'm not really
interested in receiving that list, is there no other way to report a bug?

; Ralf

Bug#884319: Networking shutdown before NFS unmount on shutdown or reboot

[Peter 'p2' De Schrijver]

OVS setup is:

HOME\p2@sunshine:~$ sudo ovs-vsctl show
[sudo] password for HOME\p2: 
6a4c96dd-80aa-4954-a2f8-22bc7fb56898
Bridge sunshine-net
Port sunshine   
   
Interface sunshine  
   
type: internal  
   
Port sunshine-net
Interface sunshine-net
type: internal
Port "eth0"
Interface "eth0"
ovs_version: "2.6.2"

see attachement for interfaces file

Peter.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug sunshine
auto sunshine
iface sunshine inet dhcp

auto eth0
iface eth0 inet manual
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug sunshine
auto sunshine
iface sunshine inet dhcp

auto eth0
iface eth0 inet manual

Bug#884319: Networking shutdown before NFS unmount on shutdown or reboot

[Peter 'p2' De Schrijver]

On 2017-12-13 21:53:10 (+0100), Michael Biebl  wrote:
> Control: tags -1 + moreinfo
> 
> 
> Am 13.12.2017 um 21:32 schrieb Peter De Schrijver:
> > Package: systemd
> > Version: 235-2
> > Severity: important
> Please include more information about your network setup.
> What tools do you use (NM, ifupdown, networkd), what configuration

ifupdown

> (ethernet, wifi, dhcp, static), how does your nfs mount configuration

Ethernet and OVS

> look like (your fstab contains no information in that regard)
> 

NFS mount is just done manually:

mount freenas:/mnt/storage /nfs/
mount freenas:/mnt/storage/p2_home/ /nfs/p2_home/

freenas is a freenas instance on the local network.

Peter.

Bug#862522: Plans

[Andreas Beckmann]

On 2017-12-13 22:30, Adam Cécile wrote:
> Is there any plans to move forward regarding CUDA 9 ?

Packages are sitting in NEW.

> Is it at possible I build myself the CUDA 9 packages; do you have some
> ready somewhere ?

You can build them from GIT.


Andreas

Bug#884322: sshuttle broken after upgrade to 0.78.0-1

[Emmanuel Lacour]

Package: sshuttle
Version: 0.78.0-1
Severity: important

Dear Maintainer,


after upgrade to 0.78.0-1, I can no longer establish tunnel. I get the 
following error:

$  /usr/bin/sshuttle -v -r root@a.b.c.d:22 w.x.y.z
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.5.1+
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.5.1+
c : connecting to server...
Starting server with Python version 2.7.3
 s: latency control setting = True
Traceback (most recent call last):
  File "", line 1, in 
  File "assembler.py", line 37, in 
  File "sshuttle.server", line 236, in main
  File "sshuttle.server", line 87, in list_routes
  File "sshuttle.server", line 69, in _list_routes
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 63: 
ordinal not in range(128)
c : fatal: server died with error code 1

downgrading to 0.77.2-1 makes it working again.



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

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

Versions of packages sshuttle depends on:
ii  iptables 1.6.0-2
ii  openssh-client [ssh-client]  1:7.2p2-5
ii  python3-pkg-resources20.10.1-1
pn  python3:any  

Versions of packages sshuttle recommends:
ii  sudo  1.8.15-1.1

Versions of packages sshuttle suggests:
pn  autossh  

-- no debconf information

Bug#884316: [Pkg-mailman-hackers] Bug#884316: mailman3-suite: Unable to use nginx because of a typo in control file

[Pierre-Elliott Bécue]

Le mercredi 13 décembre 2017 à 20:04:57+0100, Philip Frei a écrit :
> Package: mailman3-suite
> Version: 0+20170523-2
> Severity: minor
> Tags: patch
> 
> Hi,
> 
> it's great to see mailman3 in Debian. Thanks a lot for your efforts.
> 
> There is a small typo in the control file that prevents to use nginx
> with this package. Patch is attached.

Thanks for reporting the bug, sorry for our mistake. It's in the VCS and
will be uploaded soon (I hope).

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2


signature.asc
Description: PGP signature

Bug#884001: [src:linux] Graphics flickering and system freeze after last kernel upgrade

[Abou Al Montacir]

Package: src:linux

--- Please enter the report below this line. ---Just after upgrade of kernel
image last WE, I've got graphics flickering and system hangs.The freeze issue is
100% reproducible by pressing tab key on a gnome-terminal running bash.The
system become unresponsive and could not ping it using WIFI (did not test wired
connection though).
Upgrade was according to aptitude.log:[UPGRADE] linux-compiler-gcc-6-x86:amd64
4.9.51-1 -> 4.9.65-3[UPGRADE] linux-headers-4.9.0-4-amd64:amd64 4.9.51-1 ->
4.9.65-3[UPGRADE] linux-headers-4.9.0-4-common:amd64 4.9.51-1 -> 4.9.65-
3[UPGRADE] linux-image-4.9.0-4-amd64:amd64 4.9.51-1 -> 4.9.65-3[UPGRADE] linux-
kbuild-4.9:amd64 4.9.51-1 -> 4.9.65-3[UPGRADE] linux-libc-dev:amd64 4.9.51-1 ->
4.9.65-3[UPGRADE] linux-libc-dev:i386 4.9.51-1 -> 4.9.65-3
# uname -aLinux lt-mazen 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03)
x86_64 GNU/Linux
# lsmodModule  Size  Used
byrfcomm 77824  2ip6table_filter16384  0ip6_tables  
   28672  1
ip6table_filteriptable_filter 16384  0tun28672  0ctr
16384  4ccm20480  2bbswitch 
  16384  0cmac   16384  1cpufreq_userspace  16384  0cpufreq_
conservative16384  0cpufreq_powersave  16384  0bnep   20
480  2binfmt_misc20480  1nls_ascii  16384  1nls_cp437   
   20480  1vfat   20480  1fat69632  
1
vfatfuse   98304  7joydev 20480  0intel_rapl
 20480  0x86_pkg_temp_thermal16384  0intel_powerclamp   16384  0
coretemp   16384  0arc4   16384  2kvm_intel 
192512  0iwlmvm245760  0btusb  45056  0kvm  
 589824  1
kvm_inteluvcvideo   90112  0videobuf2_vmalloc  16384  1
uvcvideovideobuf2_memops   16384  1
videobuf2_vmallocvideobuf2_v4l2 24576  1
uvcvideomac80211  671744  1 iwlmvmirqbypass  16384  1
kvmintel_cstate   16384  0intel_uncore  118784  0videobuf2_core 
36864  2 uvcvideo,videobuf2_v4l2videodev  176128  3
uvcvideo,videobuf2_core,videobuf2_v4l2snd_hda_codec_hdmi 49152  1btrtl  
16384  1 btusbbtbcm  16384  1
btusbdell_led   16384  1media  40960  2
uvcvideo,videodeviTCO_wdt   16384  0intel_rapl_perf16384  0i
TCO_vendor_support16384  1
iTCO_wdtdell_wmi   16384  0sparse_keymap  16384  1
dell_wmimxm_wmi16384  0dell_laptop20480  0btintel   
 16384  1 btusbbluetooth 552960  31
btrtl,btintel,bnep,btbcm,rfcomm,btusbsnd_hda_codec_realtek90112  1rtsx_usb_m
s20480  0dell_smbios16384  3
dell_wmi,dell_led,dell_laptopmemstick   20480  1
rtsx_usb_msdcdbas 16384  1
dell_smbiosdell_smm_hwmon 16384  0snd_hda_codec_generic69632  1
snd_hda_codec_realtekiwlwifi   151552  1
iwlmvmhid_multitouch 20480  0pcspkr 16384  0snd_soc_rt56
40118784  0efi_pstore 16384  0efivars20480  
1
efi_pstoreevdev  24576  34serio_raw  16384  0snd_hda
_intel  36864  10snd_soc_ssm456716384  0snd_soc_rl6231 1
6384  1
snd_soc_rt5640dw_dmac16384  0snd_soc_core  212992  2
snd_soc_ssm4567,snd_soc_rt5640sg 32768  0dw_dmac_core   
24576  1 dw_dmacsnd_hda_codec 135168  4
snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realteki915
 1236992  40cfg80211  589824  3
iwlmvm,iwlwifi,mac80211snd_hda_core   81920  5
snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_cod
ec_realteksnd_hwdep  16384  1
snd_hda_codecsnd_compress   20480  1
snd_soc_coresnd_pcm   110592  6
snd_hda_intel,snd_hda_codec,snd_hda_core,snd_soc_rt5640,snd_hda_codec_hdmi,snd_s
oc_coresnd_soc_sst_acpi   16384  0battery20480  0snd_timer  
32768  1 snd_pcmwmi16384  3
dell_wmi,dell_led,mxm_wmimei_me 36864  0mei   10
2400  1 mei_mevideo  40960  3
dell_wmi,dell_laptop,i915drm_kms_helper155648  1
i915drm   360448  14
i915,drm_kms_helperlpc_ich24576  0elan_i2c   36864  
0snd_soc_sst_match  16384  1
snd_soc_sst_acpidell_rbtn  16384  0shpchp 36864  0sn
d86016  30
snd_compress,snd_hda_intel,snd_hwdep,snd_hda_codec,snd_timer,snd_hda_codec_hdmi,
snd_hda_codec_generic,snd_hda_codec_realtek,snd_soc_core,snd_pcmi2c_algo_bit
   16384  1
i915ac 16384  

Bug#862522: Plans

[Adam Cécile]

Hi,


Is there any plans to move forward regarding CUDA 9 ?

Is it at possible I build myself the CUDA 9 packages; do you have some 
ready somewhere ?



Thanks in advance,

Adam

Bug#884321: redis-sentinel: Please remove dependency on redis-server

[Nicolas Payart]

Package: redis-sentinel
Version: 5:4.0.6-1
Severity: wishlist

Dear Maintainer,

Please remove the dependency on redis-server.
One should be able to install sentinel on a separate server from redis-server.

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

Kernel: Linux 4.9.33-mod-std-ipv6-64 (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/bash
Init: systemd (via /run/systemd/system)

Versions of packages redis-sentinel depends on:
ii  init-system-helpers  1.48
ii  lsb-base 9.20161125
pn  redis-server 

redis-sentinel recommends no packages.

redis-sentinel suggests no packages.

Bug#884183: linux-image-3.16.0-4-amd64: Kernel panic at boot

[Benjamin Moody]

Package: src:linux
Followup-For: Bug #884183

Same problem here.  3.16.43-2+deb8u5 works, 3.16.51-2 is broken.

Supermicro H8QM3

Quad-Core AMD Opteron(tm) Processor 8347 HE (fam: 10, model: 02,
stepping: 03)

Two 3ware 9650SE RAID cards

I can get the system to boot by doing the following:

  * installing linux-image-3.16.0-4-amd64_3.16.43-2+deb8u5_amd64.deb
 (but booting the kernel and initrd from the 3.16.51-2 package)

  * adding the option 'nosmp'

  * adding the option 'blacklist=3w-9xxx'

If I don't set 'nosmp', the kernel panics immediately.  I don't
currently have a way to get a serial console on this machine, so I
don't have a complete log, but what I can see
(https://nofile.io/f/Nfc2FPR83st/IMG_20171213_144202.jpg) appears to
match the logs reported by Gerald Schroll.

If I set 'nosmp' but not 'blacklist=3w-9xxx', it goes into a seemingly
infinite loop (it appears to be trying to initialize one or both RAID
cards, but eventually times out and then tries again.)

If I set both of those options, the system boots up (slowly), and
eventually launches an emergency shell.  After five minutes, one of
the two RAID devices becomes visible.  (I assume that in this case,
something is loading 3w-9xxx.ko from the root filesystem, which is
version 3.16.43-2+deb8u5.)

In case it is useful, below is the log from the *old, working kernel*
(3.16.43-2+deb8u5).


-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=9927902d-f34d-44ff-b316-b06fdbab989f ro quiet

** Not tainted

** Kernel log:
[   18.018936] [drm]   HPD2
[   18.018938] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[   18.018939] [drm]   Encoders:
[   18.018940] [drm] CRT2: INTERNAL_DAC2
[   18.018942] [drm] DFP2: INTERNAL_DVO1
[   18.083633] [drm] fb mappable at 0xD004
[   18.083638] [drm] vram apper at 0xD000
[   18.083640] [drm] size 786432
[   18.083641] [drm] fb depth is 8
[   18.083643] [drm]pitch is 1024
[   18.083755] fbcon: radeondrmfb (fb0) is primary device
[   18.236979] Console: switching to colour frame buffer device 128x48
[   18.244485] radeon :01:01.0: fb0: radeondrmfb frame buffer device
[   18.244488] radeon :01:01.0: registered panic notifier
[   18.263937] [drm] Initialized radeon 2.39.0 20080528 for :01:01.0 on 
minor 0
[   18.810759] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.810764] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.810780] sd 0:0:0:0: [sda] Invalid command failure
[   18.810787] sd 9:0:0:0: [sdb] Invalid command failure
[   18.810790] sd 9:0:0:0: [sdb]  
[   18.810793] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.810795] sd 9:0:0:0: [sdb]  
[   18.810798] Sense Key : Illegal Request [current] 
[   18.810806] sd 0:0:0:0: [sda]  
[   18.810807] sd 9:0:0:0: [sdb]  
[   18.810814] Add. Sense: Invalid command operation code
[   18.810818] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.810821] sd 0:0:0:0: [sda]  
[   18.810824] Sense Key : Illegal Request [current] 
[   18.810829] sd 9:0:0:0: [sdb] CDB: 
[   18.810831] ATA command pass through(16): 85 06
[   18.810837] sd 0:0:0:0: [sda]  
[   18.810842]  20
[   18.810844] Add. Sense: Invalid command operation code
[   18.810846] sd 0:0:0:0: [sda] CDB: 
[   18.810848] ATA command pass through(16): 85
[   18.810853]  00
[   18.810855]  06 20 00 05
[   18.810860]  05
[   18.810861]  00 fe 00 00
[   18.810867]  00
[   18.810869]  fe
[   18.810871]  00
[   18.810873]  00
[   18.810874]  00
[   18.810876]  00
[   18.810877]  00
[   18.810879]  00
[   18.810880]  40
[   18.810882]  ef
[   18.810883]  00

[   18.810887]  00
[   18.810889]  00 00 00 40 ef 00
[   18.811173] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811231] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811429] 3w-9xxx: scsi9: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.811498] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835037] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835048] sd 0:0:0:0: [sda] Invalid command failure
[   18.835054] sd 0:0:0:0: [sda]  
[   18.835056] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   18.835059] sd 0:0:0:0: [sda]  
[   18.835061] Sense Key : Illegal Request [current] 
[   18.835065] sd 0:0:0:0: [sda]  
[   18.835068] Add. Sense: Invalid command operation code
[   18.835071] sd 0:0:0:0: [sda] CDB: 
[   18.835073] ATA command pass through(16): 85 06 20 00 05 00 fe 00 00 00 00 
00 00 40 ef 00
[   18.835462] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   18.835732] 3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command 
opcode:opcode=0x85.
[   

Bug#853783: Reopen 853783

[Svante Signell]

reopen 853783
thanks

Since I have not obtained a mail from you about the scanner problems since Tue,
28 Feb 2017 I reopen this bug. Your replies have not reached me. And you cannot 
expect me to look at the web page for all bugs I've submitted.

I see that my email address, and the bug number is on the mail from Wed, 22 Nov
2017 but I have never seen that mail, honestly. Neither did I get the mails from
Thu, 17 Aug 2017 or Thu, 15 Jun 2017, Wed, 14 Jun 2017. Was the bug submitter
mail address change? I did not get any mails since the mail from Martin Heine
Wed, 14 Jun 2017.

Bug#866073: bioperl: autopkgtest regression

[gregor herrmann]

On Wed, 13 Dec 2017 22:04:30 +0100, Andreas Tille wrote:

> > I guess you want to bump the Standards-Version, and I totally leave
> > the further lintian warnings to your discretion :)
> Bumping Standards-Version is done now, I also added a secure URI in
> watch file (what I always wanted to ask - is this the canonical location
> of CPAN?), 

We usually use https://metacpan.org/release/BioPerl in
d/watch,copyright,control,upstream/metadata as the upstream URL --
ah, that's what you've used in d/watch now, perfect :)

> but I'll leave spelling issues in this case (not always) for
> volunteers.

/me nods


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Martin-Éric Racine]

2017-12-13 22:58 GMT+02:00 Michael Biebl :
> Control: found 883877 235-3
>
> Am 08.12.2017 um 21:47 schrieb Martin-Éric Racine:
>> http://q-funk.iki.fi/core.systemd.2857
>>
>
> Not really a backtrace, but a core file, but ok.
> Looks like this is i386, so the backtrace should look like the attached
> .txt file.

Right. I simply could not think of a way to attach gdb to process 1,
and I wouldn't know how to produce an strace from a core dump.
However, systemd-cordump gave me this to work with, which, I figured,
would be a good start.

Am I to assume that the trace you attached was produced using that core dump?

Martin-Éric

Bug#866073: bioperl: autopkgtest regression

[Andreas Tille]

Hi Gregor,

On Wed, Dec 13, 2017 at 09:34:28PM +0100, gregor herrmann wrote:
> 
> Concerning the bug: yes.
> I guess you want to bump the Standards-Version, and I totally leave
> the further lintian warnings to your discretion :)

Bumping Standards-Version is done now, I also added a secure URI in
watch file (what I always wanted to ask - is this the canonical location
of CPAN?), but I'll leave spelling issues in this case (not always) for
volunteers.

Thanks again

   Andreas. 

-- 
http://fam-tille.de

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Michael Biebl]

Control: found 883877 235-3

Am 08.12.2017 um 21:47 schrieb Martin-Éric Racine:
> http://q-funk.iki.fi/core.systemd.2857
> 

Not really a backtrace, but a core file, but ok.
Looks like this is i386, so the backtrace should look like the attached
.txt file.

Would be great if you can file this upstream at
https://github.com/systemd/systemd/issues as this is happening with a
recent systemd version.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#0  0xb7f05cc9 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7d2c7f6 in kill () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#2  0x004d4364 in crash.lto_priv.225 (sig=6) at ../src/core/main.c:191
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 }}, 
  sa_flags = 0, sa_restorer = 0x0}
__func__ = "crash"
__PRETTY_FUNCTION__ = "crash"
#3  
No symbol table info available.
#4  0xb7f05cc9 in __kernel_vsyscall ()
No symbol table info available.
#5  0xb7d2c4f2 in raise () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#6  0xb7d2dc57 in abort () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#7  0x004d4b0b in log_assert_failed_realm.constprop.213 (text=0x5067d6 "n > 0", 
file=0x4ee5ca "../src/core/manager.c", 
line=3527, func=0x50972c <__PRETTY_FUNCTION__.19881> 
"manager_unref_uid_internal", realm=LOG_REALM_SYSTEMD)
at ../src/basic/log.c:817
No locals.
#8  0x0049d910 in manager_unref_uid_internal (m=, 
uid_refs=0x18e3b20, uid=4294948095, destroy_now=false, 
_clean_ipc=0x45e1f0 ) at ../src/core/manager.c:3527
c = 0
n = 0
__PRETTY_FUNCTION__ = "manager_unref_uid_internal"
__func__ = "manager_unref_uid_internal"
#9  0x00479d0d in unit_unref_uid_internal (u=, 
ref_uid=, destroy_now=, 
_manager_unref_uid=) at ../src/core/unit.c:4446
__PRETTY_FUNCTION__ = "unit_unref_uid_internal"
#10 0x004851d8 in unit_unref_gid () at ../src/core/unit.c:4455
destroy_now = false
u = 0x19010a8
#11 unit_unref_uid_gid (u=, destroy_now=) at 
../src/core/unit.c:4549
__PRETTY_FUNCTION__ = "unit_unref_uid_gid"
#12 0x004bd1fc in unit_free (u=) at ../src/core/unit.c:593
i = {idx = 4294967295, next_key = 0x0}
t = 0x0
__PRETTY_FUNCTION__ = "unit_free"
#13 0x004699f5 in manager_dispatch_cleanup_queue.lto_priv.696 (m=) at ../src/core/manager.c:954
u = 
n = 1
__PRETTY_FUNCTION__ = "manager_dispatch_cleanup_queue"
#14 0x004a34cf in manager_loop (m=0x18e3810) at ../src/core/manager.c:2365
wait_usec = 
r = 
rl = {interval = 100, begin = 272559692, burst = 5, num = 2}
__PRETTY_FUNCTION__ = "manager_loop"
__func__ = "manager_loop"
#15 0x00429b77 in main (argc=, argv=) at 
../src/core/main.c:1948
m = 0x18e3810
r = 
retval = 1
before_startup = 
after_startup = 
timespan = 
"8\323\320\277\200\323\320\277\v\021\361\267\214\261l\267\070\323\320\277t\272\362\267\002\000\000\000\260\304b\267\001\000\000\000\000\000\000\000\001\000\000\000\200\305\202\267\000\000\000\000\000\260\362\267\b\035\360\267\020\323\320\277"
fds = 0x0
reexecute = false
shutdown_verb = 0x0
initrd_timestamp = 
userspace_timestamp = {realtime = 1512765045247913, monotonic = 
36461153}
kernel_timestamp = {realtime = , monotonic = 0}
Quit
#0  0xb7f05cc9 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7d2c7f6 in kill () at ../sysdeps/unix/syscall-template.S:84
No locals.
#2  0x004d4364 in crash.lto_priv.225 (sig=6) at ../src/core/main.c:191
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 }}, 
  sa_flags = 0, sa_restorer = 0x0}
__func__ = "crash"
__PRETTY_FUNCTION__ = "crash"
#3  
No symbol table info available.
#4  0xb7f05cc9 in __kernel_vsyscall ()
No symbol table info available.
#5  0xb7d2c4f2 in __libc_signal_restore_set (set=0xbfd0cd4c) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
No locals.
#6  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
set = {__val = {671173123, 2078523646, 0 , 3527, 0, 
3218132624}}
pid = 
tid = 
ret = 0
#7  0xb7d2dc57 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x5803a0 , 
sa_sigaction = 0x5803a0 }, sa_mask = {__val = {
  2048, 1, 2048, 5362496, 3218132820, 3218132848, 2406888448, 
3483063215, 3218132848, 5123065, 5764760, 5768096, 
  5281580, 2, 5125101, 3527, 5281580, 0, 0, 0, 0, 5768096, 5764760, 
5269462, 5121094, 5764760, 5170634, 
  3258919655, 4010340154, 5125019, 5764760, 5269462}}, sa_flags = 
5170634, sa_restorer = 0xdc7}
sigs = {__val = {32, 0 }}
#8  0x004d4b0b in 

Bug#884008: [Filesystems-devel] Bug#884008: aufs-dkms: aufs triggers kernel WARN during boot

[Ralf Jung]

Hi,

> Please provide me these necessary info.
> 
> (from aufs README file)

Oh wow, that's a long list...

> --
> When you have any problems or strange behaviour in aufs, please let me
> know with:
> - /proc/mounts (instead of the output of mount(8))

> sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
> proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> udev /dev devtmpfs rw,nosuid,relatime,size=3042000k,nr_inodes=760500,mode=755 
> 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 
> 0 0
> tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=610948k,mode=755 0 0
> /dev/xvda1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
> tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
> tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
> tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
> cgroup /sys/fs/cgroup/systemd cgroup 
> rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
>  0 0
> pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
> cgroup /sys/fs/cgroup/net_cls,net_prio cgroup 
> rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
> cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
> cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
> cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 
> 0 0
> cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
> cgroup /sys/fs/cgroup/cpu,cpuacct cgroup 
> rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
> cgroup /sys/fs/cgroup/perf_event cgroup 
> rw,nosuid,nodev,noexec,relatime,perf_event 0 0
> cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 
> 0 0
> cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
> systemd-1 /proc/sys/fs/binfmt_misc autofs 
> rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9285 
> 0 0
> mqueue /dev/mqueue mqueue rw,relatime 0 0
> hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
> debugfs /sys/kernel/debug debugfs rw,relatime 0 0
> tmpfs /run/user/117 tmpfs 
> rw,nosuid,nodev,relatime,size=610944k,mode=700,uid=117,gid=65534 0 0
> tmpfs /run/user/998 tmpfs 
> rw,nosuid,nodev,relatime,size=610944k,mode=700,uid=998,gid=998 0 0
> none /proc/xen xenfs rw,relatime 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944 
> ext4 ro,nosuid,noexec,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/lib
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/lib64
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/usr/bin
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/usr/lib
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/usr/share
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/usr/local/bin
>  ext4 ro,nosuid,nodev,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 
> /var/lib/schroot/mount/schsh-sphinxlog-81099fc9-d177-4e9f-b483-bf0768c05944/data
>  ext4 rw,nosuid,nodev,noexec,relatime,errors=remount-ro,data=ordered 0 0
> /dev/xvda1 /var/lib/docker/aufs ext4 
> rw,relatime,errors=remount-ro,data=ordered 0 0
> none 
> /var/lib/docker/aufs/mnt/df2e8ee3c0467263a3739bc31dcbe8b20020b4cf63420fe678e4dcd9980d01ce
>  aufs rw,relatime,si=9c8729566d35b73d,dio,dirperm1 0 0
> shm 
> /var/lib/docker/containers/2b0cb0d4354c7058a6f75bde59951666d11cee783d52b5b1ebdb486f1869/shm
>  tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0
> nsfs /run/docker/netns/55b873a60b7d nsfs rw 0 0
> binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
> tmpfs /run/user/1001 tmpfs 
> rw,nosuid,nodev,relatime,size=610944k,mode=700,uid=1001,gid=1001 0 0


> - /sys/module/aufs/*

> $ for f in $(find /sys/module/aufs/ -type f); do echo $f && sudo cat $f; done
> /sys/module/aufs/version
> 4.9-20161219
> /sys/module/aufs/notes/.note.gnu.build-id
> [binary garbage]
> /sys/module/aufs/taint
> O
> /sys/module/aufs/initsize
> 0
> /sys/module/aufs/initstate
> live
> /sys/module/aufs/srcversion
> EAC7876AD444CD8E2C103D2
> /sys/module/aufs/coresize
> 360448
> /sys/module/aufs/refcnt
> 314
> /sys/module/aufs/sections/.data..read_mostly
> 0xc06849c0
> 

Bug#884320: upgrade error libp11-2 -> libp11-3

[Matthias Klose]

Package: libp11-3
Version: 0.4.7-2
Severity: serious
Tags: sid buster

missing breaks/replaces

Unpacking libp11-3:amd64 (0.4.7-2) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-ZbKGej/78-libp11-3_0.4.7-2_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libp11.so.2.4.7', which is also
in package libp11-2:amd64 0.4.7-1
Preparing to unpack .../79-libp11-dev_0.4.7-2_amd64.deb ...

Bug#884319: Networking shutdown before NFS unmount on shutdown or reboot

[Michael Biebl]

Control: tags -1 + moreinfo


Am 13.12.2017 um 21:32 schrieb Peter De Schrijver:
> Package: systemd
> Version: 235-2
> Severity: important
Please include more information about your network setup.
What tools do you use (NM, ifupdown, networkd), what configuration
(ethernet, wifi, dhcp, static), how does your nfs mount configuration
look like (your fstab contains no information in that regard)


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



signature.asc
Description: OpenPGP digital signature

Bug#874259: [Pkg-nagios-devel] Bug#874259: nagios-plugins-contrib: check_memory regression on Debian 9 (don't work anymore)

[Jan Wagner]

tags 874259 + moreinfo unreproducible
thanks

Hi Tom,

Am 04.09.17 um 15:50 schrieb Tom LAREDO:
> nagios-plugins-contrib provides /usr/lib/nagios/plugins/check_memory that is 
> broken on Debian Stretch.
> 
> Here is the behaviour:
> 
> # /usr/lib/nagios/plugins/check_memory
> Can't call method "new" on an undefined value at ./check_memory line 55.
> 
> This may be due to the format change of 'free' command (or maybe a 
> broken/missing dependency?).

I can not reproduce this here. Did you have a look into
/usr/share/doc/nagios-plugins-contrib/README.Debian.plugins and
installed one of the listed packages which are needed to be installed?
Let me guess you are not installing recommends?

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#880544: [Pkg-nagios-devel] Bug#880544: nagios-plugins-contrib: check_rbl does not handle IPv6 addresses

[Jan Wagner]

tags 880544 + pending
thanks

Hi Hamish,

thanks for bringing this issue to our attention.

Am 02.11.17 um 02:18 schrieb Hamish Moffatt:
> check_rbl does not properly query the DNSBLs for IPv6 addresses.
> 
> The logic to convert the IP to .zen.spamhaus.org for example
> assumes an IPv4 dotted quad and doesn't handle IPv6.
Looks like this was fixed by
https://github.com/matteocorti/check_rbl/commit/565c94383ecb1f3e569192fd4de2bfc08f7d7789
which is part of version 1.4.1 of the plugin we imported recently into
out VCS.
It should be available with the next upload to unstable.

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#590645: [quassel-core] Please provide support for --listen option to init script

[Heinrich Schuchardt]

Dear maintainer,

unfortunately this request is now 7 years old and not yet considered. Please, 
give it some love.

The fix is easy:

Modify /etc/init.d/quasselcore as follows:

 # defaulting LOGLEVEL and PORT, just in case /etc/default/$name gets deleted
 LOGLEVEL="Info"
 PORT="4242"
+LISTEN="::,0.0.0.0"

...

 start_server() {
 start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile \
 --background --chuid $DAEMONUSER --exec $DAEMON \
 -- --logfile=$LOGFILE --loglevel=$LOGLEVEL --configdir=$DATADIR \
-   --port=$PORT \
+  --listen=$LISTEN --port=$PORT \
$DAEMON_OPTS
 }

Add two lines to /etc/default/quasselcore:

# Network address to listen on
LISTEN="::,0.0.0.0"

Best regards

Heinrich Schuchardt

Bug#880743: [Pkg-nagios-devel] Bug#880743: nagios-plugins-contrib: check_ssl_cert can't use -servername option of openssl s_client

[Jan Wagner]

tags 880743 + pending
thanks

Hi Johan,

thanks for bringing this to our attention.

Am 04.11.17 um 18:43 schrieb Johan Fleury:
> The check_ssl_cert plugin of nagios-plugins-contrib can't use TLS SNI
> due to a bug in the way it detects available options of `openssl
> s_client`.
> 
[...]

> Here is the output of check_ssl_cert on one of my domain that requires
> SNI:
> 
>   # /usr/lib/nagios/plugins/check_ssl_cert -v -H arcaik.net
>   expect not available
>   timeout available (/usr/bin/timeout)
>   found GNU date with timestamp support: enabling date computations
>   '/usr/bin/openssl s_client' does not support '-servername': disabling
>   virtual server support
>   downloading certificate to /tmp
>   parsing the certificate file
>   cannot find the CA Issuers in the certificate: disabling OCSP checks
>   The certificate will expire in 3649 day(s)
>   SSL_CERT CRITICAL subject=CN = vps01.br0.fr: Cannot verify
>   certificate, self signed certificate|days=3649
> 
> I can't use this version of check_ssl_cert to monitor my certs anymore.
> Is it possible to fix the script for the stable distribution? I already
> have a work around but I would rather use the Debian shipped plugins.
This is fixed with the imported version 1.57.0 of the plugin into our
VCS. It should be available with the next upload to unstable.

Cheers, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#883558: linux: not yet ready to enter testing

[Tianon Gravi]

Salvatore Bonaccorso wrote:
> We think 4.14.2-1 should not yet enter testing, thus filling a
> blocking bug to preventing migration.
>
> We will close the bug as soon we think 4.14.2-1 or an increment is
> good.

In the quest for a little more detail (because I'm wanting to test
4.14 on a buster machine), I asked about this on IRC and received the
response from Ben that there's an embargoed security issue pending,
and got permission to add this short note as to the context for this
bug filing. :)

Cheers!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#866073: bioperl: autopkgtest regression

[gregor herrmann]

On Wed, 13 Dec 2017 20:42:41 +0100, Andreas Tille wrote:

> > Fixes pushed to git.
> This means ready for upload, right?

Concerning the bug: yes.
I guess you want to bump the Standards-Version, and I totally leave
the further lintian warnings to your discretion :)


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Ralf Jung]

Hi,

>> The relevant bits of the /etc/network/interfaces.d/* looks as follows:
> [...]
>> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
>> ttl 255
> [...]
> 
> The problem with jessie was that it ignored any errors from
> pre/post-up/down commands. This was fixed in stretch. If you want
> ifupdown to ignore any errors from your pre-up command, just append "||
> true" to it, like:
> 
>  pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
> ttl 255 || true
> 
> However, this begs the question: why does this fail at all?

Actually, I am wondering even more why it tries to execute this again
even though the interface is already up.

> I tried the
> exact same iface stanza on a stretch machine, and doing repeated ifup and
> ifdowns just works as it should.

ifup should be idempotent, right?  Did you try "ifup && ifup"?

We also have another stretch machine on which this works.  So I am a bit
lost about why on one machine, "ifup" tries to bring up an already up
interface.

>> add tunnel "gre0" failed: File exists
> 
> I don't know why it prints "gre0" here, I think that's a bug in ip.

I see the same behavior.

> I do
> see it when I manually try to do the ip tunnel add command multiple
> times without ip tunnel del inbetween.
> 
>> With exactly the same setup (literally -- this is all automatically 
>> deployed), I
>> do not get any errors on our jessie systems.  Also the stretch system with a
>> slightly older kernel (4.9.0-3) is not affected.  The broken machine has
>> 4.9.0-4-amd64.
> 
> Hm, that is also weird. Maybe there is something that causes this tunnel
> to be brought up before ifup tries to do the same?

Does ifup have state?  So, could it be that on one machine it up'ed the
tunnel successfully and that's why it dos not try again, because it
remembers it already did that?
I thought it does not have any state beyond just the kernel network stack.

; Ralf

Bug#884286: use Switch breaks

[Damyan Ivanov]

Control: tag -1 upstream confirmed
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=97440
Control: clone -1 -2
Control: reassign -2 perl/5.20.2-3
Control: retitle -2 filter_read in block mode makes DATA handle empty
Control: tag -2 upstream
Control: forwarded -2 https://rt.cpan.org/Public/Bug/Display.html?id=101033
Control: block -1 by -2

-=| Christoph Berg, 13.12.2017 13:05:58 +0100 |=-
> Package: libswitch-perl
> Version: 2.17-2
> Severity: normal
> 
> Merely adding "use Switch;" to a perl program breaks the use of
> __DATA__ sections via :

Right.

As noted in https://rt.cpan.org/Public/Bug/Display.html?id=97440 this 
is a bug/limitation of Filter::Util::Call (reported as 
https://rt.cpan.org/Public/Bug/Display.html?id=101033)


Cheers,
dam

Bug#884266: [PKG-Openstack-devel] Bug#884266: heat-common: fails to install: installed heat-common package post-installation script subprocess returned error exit status 10

[Thomas Goirand]

On 12/13/2017 05:15 AM, Andreas Beckmann wrote:
> Does it fail on a debconf question not being asked under 
> DEBIAN_FRONTEND=noninteractive?

Nop, it fails because I moved a debconf template from heat-common to
heat-api, but forgot to remove the db_input from heat-common.config. I'm
uploading the fix.

Thanks a lot for this valuable bug report.

Cheers,

Thomas Goirand (zigo)

Bug#884076: [Pkg-nagios-devel] Bug#884076: nagios-plugins-standard: check_mysql segfaults with --extra-opts

[Jan Wagner]

tags 884076 + moreinfo unreproducible
thanks

Hi Joonas,

thanks for bringing this to our attention.

Am 11.12.17 um 10:06 schrieb Joonas Kylmälä:
> I ran the command "/usr/lib/nagios/plugins/check_mysql --extra-opts" and
> it gave me the following output: "Segmentation fault".

Unfortunately I'm not able to reproduce this:

waja@bb:~$ /usr/lib/nagios/plugins/check_mysql --extra-opts
Cannot find config file in any standard location.
waja@bb:~$ dpkg --print-architecture
amd64
waja@bb:~$ cat /etc/debian_version
9.2
waja@bb:~$ dpkg -l | grep monitoring-plugins-standard
ii  monitoring-plugins-standard  2.2-3
amd64Plugins for nagios compatible monitoring systems (standard)

Would be good to have more informations so we maybe can reproduce this.

Many thanks, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#884317: ITP: python-django-x509 -- x509 PKI certificates management for Django

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-x509
  Version : 0.3.2
  Upstream Author : Federico Capoano 
* URL : https://github.com/openwisp/django-x509/
* License : BSD-3-clause
  Programming Lang: Python
  Description : x509 PKI certificates management for Django

 Simple reusable django app implementing x509 PKI certificates management.
 .
 Features:
  * CA generation
  * Import existing CAs
  * End entity certificate generation
  * Import existing certificates
  * Certificate revocation
  * CRL view (public or protected)
  * Possibility to specify x509 extensions on each certificate
  * Random serial numbers based on uuid4 integers

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloxiEARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpH5gf/QqABUoqaxpWbsJJ5/Y7NGidCJXkdkk+t
8U+z3f41v8F3cnrOHjFA9Qx5tS8a6aChzZ+AEGgYYazavXnSr5rcXj9jptt6wqML
w8i5GXDOHuVqXtyf+D0Ky0CTiWcvfc9tJc1iyd4jfa9n6pQB9h0b7M12ohtTJB5t
Veb85cCFLnFz5wuOIzbs8Y7ZDpVmg8co6C2vAJ6xgj7cQqkKQGRyJ2P4UEPAl//u
KA+VG8dPf4+xuC5PpRKMg72whCuAw72YFBJxw94X+DzoQQSvQsJrHA3Ao4lvGzxL
oXqemstFuvr2/YHwc/pOdqrtGTxx6kDXSHD0kwP1ShjGBUqbQaEjTw==
=IfFR
-END PGP SIGNATURE-

Bug#748959: libr-cran-rcurl: Contains a ca-bundle

[Graham Inggs]

Hi Kurt

I'm guessing you are not subscribed to this bug and missed Andreas'
question below:

> I'm currently browsing long standing bugs in Debian Med team.  Could you
> please clarify what files from r-cran-rcurl you mean and how to replace
> them (symlinks to what?)
>
> Sorry for the naive question

Regards
Graham

Bug#858936: My builder thinks it's fixed.

[Adrian Bunk]

Control: tags -1 - patch

On Sun, Oct 08, 2017 at 11:53:50AM +0100, deb...@fau.xxx wrote:
> Control: tags -1 + patch
> 
> kannel does build successfully with libssl-dev in my sid builder,
> i.e. with this patch:
> 
> diff --git a/kannel-1.4.4/debian/control b/kannel-1.4.4/debian/control
> index a0148e7..7a2311c 100644
> --- a/kannel-1.4.4/debian/control
> +++ b/kannel-1.4.4/debian/control
> @@ -8,7 +8,7 @@ Build-Depends: cdbs,
>   dh-autoreconf,
>   debhelper,
>   libxml2-dev,
> - libssl1.0-dev | libssl-dev (<< 1.1~),
> + libssl-dev,
>   openssl,
>   default-libmysqlclient-dev | libmysqlclient-dev,
>   libsqlite0-dev,
> @@ -86,7 +86,7 @@ Architecture: any
>  Section: devel
>  Depends:
>   ${misc:Depends},
> - libssl1.0-dev | libssl-dev (<< 1.1~),
> + libssl-dev,
>   libpam0g-dev,
>   libxml2-dev,
>   libpcre3-dev,

It does build - due to build-time autodetection that disables SSL support.

I cannot judge whether or not it makes sense shipping this package 
without SSL support in a stable release.

> Cheers.

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#884216: [Pkg-xfce-devel] Bug#884216: libxfce4ui: FTBFS: dh_install: libxfce4ui-common missing files: usr/share/gtk-doc/*

[Yves-Alexis Perez]

control: tag -1 moreinfo unreproducible
On Tue, 2017-12-12 at 19:34 +0100, Andreas Beckmann wrote:
> Hi,
> 
> libxfce4ui/experimental recently started to FTBFS, probably due to
> debhelper getting more strict w.r.t. missing files:
> 
>debian/rules override_dh_install
> make[1]: Entering directory '/build/libxfce4ui-4.13.3'
> dh_install --sourcedir=/build/libxfce4ui-4.13.3 -plibxfce4ui-utils 
> debian/vendorinfo usr/share/xfce4
> dh_install -X .la
> dh_install: Cannot find (any matches for) "usr/share/gtk-doc/*" (tried in ., 
> debian/tmp)
> 
> dh_install: libxfce4ui-common missing files: usr/share/gtk-doc/*
> dh_install: missing files, aborting
> debian/rules:21: recipe for target 'override_dh_install' failed
> make[1]: *** [override_dh_install] Error 25
> make[1]: Leaving directory '/build/libxfce4ui-4.13.3'

I just tried a build (in pbuilder/amd64) and it worked just fine. Can you be
more specific about your test? Is it an arch-indep build for example?

Regards,
-- 
Yves-Alexis

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

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Hi again,

Markus Koschany wrote:

> Let me try to explain it this way: Take src:ufoai-data or src:netbeans
> for example. Both packages ship approximately a dozen different
> licenses. I can't simply copy the upstream license because I have
> to format it to make it copyright format 1.0 compliant.

Aha, that explains it.

Policy does not require using copyright format 1.0, but many packagers
choose to use it.  It sounds like we need better tools to help them.

But with a goal in mind of saving maintainer time, shouldn't we
discourage using copyright format 1.0 when the upstream LICENSE file
is clear?  (I personally think the maintainer time involved is very
little relative to the work of either manually or using tools
verifying that the license is correctly documented --- e.g. comparing
source file headers to the LICENSE file.  I'm just going along with
the saving time argument.  I suspect the best way forward will be to
improve tools.)

Thanks,
Jonathan

Bug#877966: This is happening again

[Tollef Fog Heen]

]] Julien Cristau 

> On 12/12/2017 03:39 PM, Tollef Fog Heen wrote:
> > DSA, thoughts on this?  Sounds reasonable?
> > 
> I think the issue is also made worse by mirror-bytemark being
> consistently much slower than the other backends, and how ftpsync
> behaves in a pathological way when mirrors have very different speeds.

Agreed, we should fix this on both the mirror-health side and how we
push.

> When doing a staged push, we start stage1 for all downstreams.  Each of
> those, when it's done, waits for up to $PUSHDELAY, by default 10
> minutes, for its siblings to signal they're also done with stage1.  If
> all goes well, everyone waits for everyone else to be done with stage1,
> then within 5 seconds of each other they run stage2.

Why do we do this?  To avoid having inconsistent mirrors?  Can we solve
this by having names that incorporate _health instead and just have
mirrors take whatever time they need?  This will cause some traffic to
slosh around as mirrors go healthy and unhealthy, but hopefully not more
than what we can handle?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884001: Similar issue

[Samuel Smith]

I've reported a similar issue here 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859639

Bug#859639: Similar issues here

[Samuel Smith]

Having the same problems here on a Lenovo T520. It used to happen only 
if I had the internal screen and an external monitor both active. Now it 
happens randomly with only and external monitor hooked up since the 
upgrade to 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 
GNU/Linux.


I get random screen freezes where I can still move the mouse cursor, but 
clicking on anything doesn't do anything. Usually only happens when 
heavily using Firefox. Machine has 16GB of ram as well.


Xorg logs would have:
[201653.062] (WW) modeset(0): flip queue failed: Cannot allocate memory
[201653.062] (WW) modeset(0): Page flip failed: Cannot allocate memory
[201730.916] (WW) modeset(0): flip queue failed: Cannot allocate memory
[201730.916] (WW) modeset(0): Page flip failed: Cannot allocate memory
[201730.916] (WW) modeset(0): flip queue failed: Cannot allocate memory
[201730.916] (WW) modeset(0): Page flip failed: Cannot allocate memory

dmesg would have:
[drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun


I have since stopped using the modeset driver and added to 
/etc/X11/xorg.conf.d/20-intel.conf



Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
EndSection


No issues yet but I will post back if it happens.

Bug#884309: starpu-examples: depends indirectly on nonfree package libsocl-contrib-1.2-0

[Samuel Thibault]

Jonas Smedegaard, on mer. 13 déc. 2017 20:16:50 +0100, wrote:
> Better would be that you change to use a different name for the
> virtual package, and then declare that virtual package last - like
> this:
> 
> Depends: libsocl-1.2-0 (= 1.2.3+dfsg-3) | libsocl-any-1.2-0

Ok, will do that, thanks.

Samuel

Bug#884173: Backtrace

[Tollef Fog Heen]

This happens for me too:

$ /usr/bin/chromium -g
# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/tfheen/bin:/usr/local/bin:/home/tfheen/.local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
#GTK_PATH=
#  CHROMIUM_FLAGS=--enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.be3nwP
GNU gdb (Debian 7.12-6+b1) 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/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/ca/13b14d742fddeb5910cd30a74e53d1af48ad1b.debug...(no 
debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/lib/chromium/chromium --enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdd739700 (LWP 14296)]
[New Thread 0x7fffdcf38700 (LWP 14301)]
[New Thread 0x7fffdb558700 (LWP 14302)]
[New Thread 0x7fffdad57700 (LWP 14303)]
[New Thread 0x7fffd9d55700 (LWP 14304)]
[New Thread 0x7fffda556700 (LWP 14305)]
[New Thread 0x7fffd9d4d700 (LWP 14306)]
[New Thread 0x7fffd954c700 (LWP 14307)]
[New Thread 0x7fffd7107700 (LWP 14308)]
[New Thread 0x7fffd6906700 (LWP 14309)]
[New Thread 0x7fffd6105700 (LWP 14310)]
[New Thread 0x7fffd5904700 (LWP 14311)]
[New Thread 0x7fffd5103700 (LWP 14312)]
[New Thread 0x7fffd4902700 (LWP 14313)]
[New Thread 0x7fffd4101700 (LWP 14314)]
[New Thread 0x7fffd3900700 (LWP 14315)]
[New Thread 0x7fffd30ff700 (LWP 14316)]
[New Thread 0x7fffd28fe700 (LWP 14317)]
[New Thread 0x7fffd20fd700 (LWP 14318)]
[New Thread 0x7fffd18fc700 (LWP 14319)]
[New Thread 0x7fffd10fb700 (LWP 14320)]
[New Thread 0x7fffd08fa700 (LWP 14321)]
[New Thread 0x7fffd00f9700 (LWP 14322)]
[New Thread 0x7fffcf8f8700 (LWP 14323)]
[New Thread 0x7fffcf0f7700 (LWP 14324)]
[New Thread 0x7fffce8f6700 (LWP 14325)]
[New Thread 0x7fffce0f5700 (LWP 14326)]
[New Thread 0x7fffcd8f4700 (LWP 14327)]
[New Thread 0x7fffcce6d700 (LWP 14328)]
[New Thread 0x7fffbbe42700 (LWP 14355)]
[14252:14324:1213/195506.734934:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffbb641700 (LWP 14356)]
[New Thread 0x7fffb9e3e700 (LWP 14358)]
[New Thread 0x7fffba63f700 (LWP 14359)]
[New Thread 0x7fffbae40700 (LWP 14357)]
[14252:14324:1213/195506.827087:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffb5a67700 (LWP 14362)]
[New Thread 0x7fffb5266700 (LWP 14363)]
[New Thread 0x7fffb4a65700 (LWP 14365)]
[New Thread 0x7fffb4264700 (LWP 14366)]
[New Thread 0x7fffb3a63700 (LWP 14367)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x7fffb28db700 (LWP 14368)]
[Thread 0x7fffb28db700 (LWP 14368) exited]
[New Thread 0x7fffb193d700 (LWP 14370)]
[New Thread 0x7fffb113c700 (LWP 14371)]
[New Thread 0x7fffb093b700 (LWP 14372)]
[New Thread 0x7fffb013a700 (LWP 14373)]
[14252:14355:1213/195506.960725:ERROR:connection.cc(1964)] Web sqlite error 1, 
errno 0: no such column: instant_url, sql: SELECT id, short_name, keyword, 
favicon_url, url, safe_for_autoreplace, originating_url, date_created, 
usage_count, input_encodings, suggest_url, prepopulate_id, created_by_policy, 
instant_url, last_modified, sync_guid, alternate_urls, 
search_terms_replacement_key, image_url, search_url_post_params, 
suggest_url_post_params, instant_url_post_params, image_url_post_params, 
new_tab_url, last_visited FROM keywords ORDER BY id ASC
[New Thread 0x7fffaf939700 (LWP 14374)]
[New Thread 0x7fffaf057700 (LWP 14375)]
[New Thread 0x7fffae856700 (LWP 14376)]
[New Thread 0x7fffade43700 (LWP 14377)]
[New Thread 0x7fffad43f700 (LWP 14387)]
[New Thread 0x7fffabdd7700 (LWP 14404)]
[Thread 0x7fffabdd7700 (LWP 14404) exited]
[New Thread 0x7fffabdd7700 (LWP 14405)]
[New Thread 0x7fffaaf4a700 (LWP 14406)]
[New Thread 0x7fffa9fc5700 (LWP 14407)]
[New Thread 0x7fffa79ec700 (LWP 14408)]
[New Thread 0x7fffa716b700 (LWP 14409)]

Bug#866073: bioperl: autopkgtest regression

[Andreas Tille]

On Wed, Dec 13, 2017 at 06:59:38PM +0100, gregor herrmann wrote:
> Or the pkg-perl-autopkgtest upload which started to run tests in t/
> recursively.
>  
> Interestingly, the tests pass during build and only fail during
> autopkgtest. -- Maybe Modul::Build is the relevant part after all
> (running Build.PL would be a difference between the two runs.)
> 
> Ok, with running `perl Build.PL' before the smoke tests we're down to
> one probably unrelated failure. -- Ah, yet another file needed.
> 
> * end of monlogue *

:-)
 
> Fixes pushed to git.

This means ready for upload, right?

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Bug#841499: uscan: support searching in multiple directories for matching files

[Paul Gevers]

On Tue, 25 Oct 2016 22:39:40 +0900 Osamu Aoki 
wrote:
> Hi,
> 
> On Tue, Oct 25, 2016 at 08:41:35AM +0800, Paul Wise wrote:
> > On Tue, 2016-10-25 at 01:54 +0900, Osamu Aoki wrote:
> > 
> > > If we do not do this, we need to loop over scanning many pages... Not a
> > > good idea.  Can you think of non-invasive change?
> ...
> > It isn't much of a complication at all really:
> > 
> > On error, if we scanned a directory, go back and scan the next
> > directory. Possibly with a configurable limit of scanned dirs.
> 
> I was thinking to bunch up all possible URL results by scanning all
> directory from low version to the high version.  But you have a point.
> Scan from high version and pick page which has matching URL.
> 
> This makes sense and not as bad situation as I thought. 
> 
> Just push down all the directories.  Scan from the latest one.

This would fix my current issue with uscan the version I am looking for
is in 1.95. I don't think upstream want to publish a newer version, but
nevertheless I like to add a watch file to be sure. There are multiple
festvox voices that have the same issue (because of the same upstream).

paul@testavoira ~/packages/festvox/festvox-ellpc11k $ uscan -v
uscan info: uscan (version 2.17.11) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="festvox-ellpc11k" version="1.95-1" (as seen in
debian/changelog)
uscan info: package="festvox-ellpc11k" version="1.95" (no epoch/revision)
uscan info: Check debian/watch and debian/changelog in ./.git/refs/tags
uscan info: Check debian/watch and debian/changelog in
./.git/dgit/unpack/festvox-ellpc11k-1.4.0
uscan info: ./debian/changelog sets package="festvox-ellpc11k"
version="1.95"
uscan info: Process ./debian/watch (package=festvox-ellpc11k version=1.95)
uscan info: opts:
filenamemangle=s#.*/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/festvox_ellpc11k#festvox-ellpc11k_$1#
uscan info: line:
http://festvox.org/packed/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/
festvox_ellpc11k(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
uscan info: Parsing
filenamemangle=s#.*/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/festvox_ellpc11k#festvox-ellpc11k_$1#
uscan info: line:
http://festvox.org/packed/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/
festvox_ellpc11k(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 1.95
uscan info: Last orig.tar.* tarball version (dversionmangled): 1.95
uscan info: dir=>/packed/festival/  dirpattern=>[-_]?(\d[\-+\.:\~\da-zA-Z]*)
uscan info: Requesting URL:
   http://festvox.org/packed/festival/
uscan info: Matching pattern:

(?:(?:http://festvox.org)?\/packed\/festival\/)?[-_]?(\d[\-+\.:\~\da-zA-Z]*)
uscan info: Matching target for dirversionmangle:   ?C=N;O=D
uscan info: Matching target for dirversionmangle:   ?C=M;O=A
uscan info: Matching target for dirversionmangle:   ?C=S;O=A
uscan info: Matching target for dirversionmangle:   ?C=D;O=A
uscan info: Matching target for dirversionmangle:   /packed/
uscan info: Matching target for dirversionmangle:   1.4.1/
uscan info: Matching target for dirversionmangle:   1.4.2/
uscan info: Matching target for dirversionmangle:   1.4.3/
uscan info: Matching target for dirversionmangle:   1.95/
uscan info: Matching target for dirversionmangle:   1.96/
uscan info: Matching target for dirversionmangle:   2.0.95/
uscan info: Matching target for dirversionmangle:   2.1/
uscan info: Matching target for dirversionmangle:   2.4/
uscan info: Matching target for dirversionmangle:   Linux-1.4.1/
uscan info: Matching target for dirversionmangle:   Linux-1.4.2/
uscan info: Matching target for dirversionmangle:   free-1.4.1/
uscan info: Matching target for dirversionmangle:   free-1.4.2/
uscan info: Matching target for dirversionmangle:   free-1.4.3/
uscan info: Matching target for dirversionmangle:   latest/
uscan info: Found the following matching directories (newest first):
   2.4/ (2.4)
   2.1/ (2.1)
   2.0.95/ (2.0.95)
   1.96/ (1.96)
   1.95/ (1.95)
   1.4.3/ (1.4.3)
   1.4.2/ (1.4.2)
   1.4.1/ (1.4.1)
uscan info: newest_dir => '2.4'
uscan info: Requesting URL:
   http://festvox.org/packed/festival/2.4/
uscan info: Matching pattern:

(?:(?:http://festvox.org)?\/packed\/festival\/2\.4\/)?festvox_ellpc11k(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
uscan warn: In debian/watch no matching files for watch line
  http://festvox.org/packed/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/
festvox_ellpc11k(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
uscan info: opts:
filenamemangle=s#.*/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/voices/festvox_ellpc11k#festvox-ellpc11k_$1#
uscan info: line:
http://festvox.org/packed/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/voices/
festvox_ellpc11k(?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)
uscan info: Parsing
filenamemangle=s#.*/festival/[-_]?(\d[\-+\.:\~\da-zA-Z]*)/voices/festvox_ellpc11k#festvox-ellpc11k_$1#
uscan info: line:

Bug#863841: Enable systemd hardening options for named

[Simon Deziel]

Hi,

It would be really nice to have those hardening options used. I use them
locally on Ubuntu. Please note that the Private*/Protect* options (using
the mount namespace) require this change to the Apparmor profile:

-/usr/sbin/named {
+/usr/sbin/named flags=(attach_disconnected) {

Thanks,
Simon



signature.asc
Description: OpenPGP digital signature

Bug#883980: Experimenting with 4.9.0-4-amd64 and 4.9.0-3-amd64

[Gerard M. Vignes]

Without installing, updating or removing any software, I am 
experimenting with kernels 4.9.0-4-amd64 and 4.9.0-3-amd64.


When I applied the Debian 9.3 upgrade, it installed a new kernel and 
retained the older kernel. I can select the newer or older kernel using 
the advanced boot menu.


When I boot with the newer 4.9.0-4-amd64 kernel, I experience the 
problem with screen going black for 1 second. This happens sporadically, 
but often enough to disrupt normal workstation activities.


When I boot with the older 4.9.0-3-amd64 kernel, I am not able to 
duplicate the problem.


I only discovered how to boot between old and new kernels last night, so 
I am going to continue booting on the older 4.9.0-3-amd64 kernel until a 
new kernel is released. I will post to this bug report again ONLY IF I 
discover that the problem occurs using the older 4.9.0-3-amd64 kernel.


I believe that the Debian 9.3 upgrade and/or newer 4.9.0-4-amd64 kernel 
introduced a problem that causes my screen to sporadically go black for 
1 second. The general conditions to duplicate this problem are outlined 
in my previous posts to this bug report. The simple diagnostics about my 
machine, which I provided as attachments, are also available in previous 
posts.


Thank you.

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[gregor herrmann]

On Wed, 13 Dec 2017 19:59:15 +0100, Markus Koschany wrote:

(Just as a side note, I'm in favour of adding more licenses to
common-licenses):

> Take a stopwatch,
> find a plain-text version of this license on the internet, format the
> file according to copyright format 1.0 and stop the time.

% time cme modify dpkg-copyright 'License:"AGPL-3"' -save 
cme: using Dpkg::Copyright model
License AGPL-3 is not used in Files: section
License AGPL-3 is not used in Files: section
Warning in 'License': Unused license: AGPL-3

Changes applied to dpkg-copyright configuration:
- License: added entry AGPL-3

cme modify dpkg-copyright 'License:"AGPL-3"' -save  0.95s user 0.04s system 99% 
cpu 0.990 total


(Admittedly it doesn't work or needs different runes for AGPL-3+.)


If you have the file lying around:

% time cme run paste-license  --arg license=AGPL-3+ --arg file=AGPL-3.0 
cme: using Dpkg::Copyright model
License AGPL-3+ is not used in Files: section

Changes applied to dpkg-copyright configuration:
- License: added entry AGPL-3+
- License:"AGPL-3+" text has new value: ' Copyright (C) 2007 Free 
Software Foundation, Inc. <[...]'

cme run paste-license --arg license=AGPL-3+ --arg file=AGPL-3.0  0.93s user 
0.03s system 99% cpu 0.957 total



Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Pink Floyd: The Great Gig In The Sky


signature.asc
Description: Digital Signature

Bug#880337: php-sabre-vobject-3: diff for NMU version 3.5.2-1.1

[Adrian Bunk]

Control: tags 880337 + patch
Control: tags 880337 + pending

Dear maintainer,

I've prepared an NMU for php-sabre-vobject-3 (versioned as 3.5.2-1.1) 
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

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

diff -Nru php-sabre-vobject-3-3.5.2/debian/changelog php-sabre-vobject-3-3.5.2/debian/changelog
--- php-sabre-vobject-3-3.5.2/debian/changelog	2016-04-27 20:10:21.0 +0300
+++ php-sabre-vobject-3-3.5.2/debian/changelog	2017-12-13 21:17:57.0 +0200
@@ -1,3 +1,11 @@
+php-sabre-vobject-3 (3.5.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove the Canada/East-Saskatchewan timezone
+that was removed in tzdata 2017c. (Closes: #880337)
+
+ -- Adrian Bunk   Wed, 13 Dec 2017 21:17:57 +0200
+
 php-sabre-vobject-3 (3.5.2-1) unstable; urgency=medium
 
   [ Visily Komrakov ]
diff -Nru php-sabre-vobject-3-3.5.2/debian/patches/0003-Remove-East-Saskatchewan.patch php-sabre-vobject-3-3.5.2/debian/patches/0003-Remove-East-Saskatchewan.patch
--- php-sabre-vobject-3-3.5.2/debian/patches/0003-Remove-East-Saskatchewan.patch	1970-01-01 02:00:00.0 +0200
+++ php-sabre-vobject-3-3.5.2/debian/patches/0003-Remove-East-Saskatchewan.patch	2017-12-13 21:17:57.0 +0200
@@ -0,0 +1,15 @@
+Description: Remove the Canada/East-Saskatchewan timezone
+ Removed in tzdata 2017c.
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/880337
+
+--- php-sabre-vobject-3-3.5.2.orig/lib/timezonedata/php-bc.php
 php-sabre-vobject-3-3.5.2/lib/timezonedata/php-bc.php
+@@ -67,7 +67,6 @@ return array(
+ 'Brazil/West',
+ 'Canada/Atlantic',
+ 'Canada/Central',
+-'Canada/East-Saskatchewan',
+ 'Canada/Eastern',
+ 'Canada/Mountain',
+ 'Canada/Newfoundland',
diff -Nru php-sabre-vobject-3-3.5.2/debian/patches/series php-sabre-vobject-3-3.5.2/debian/patches/series
--- php-sabre-vobject-3-3.5.2/debian/patches/series	2016-04-27 20:08:57.0 +0300
+++ php-sabre-vobject-3-3.5.2/debian/patches/series	2017-12-13 21:17:57.0 +0200
@@ -1,2 +1,3 @@
 0001-Use-homemade-autoloader.php.patch
 0002-Use-ClassLoader-from-Symfony-instead-of-autoLoader.patch
+0003-Remove-East-Saskatchewan.patch

Bug#857397: rdesktop: Failed to negotiate protocol with Windows server 2008

[cpd]

On Fri, 1 Dec 2017 13:33:58 +0100 Carsten Burkhardt 
 wrote:

> Hello Gabriel + Olaf,
>
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763599 (Nov. 
2016) I found a solution for connection problems to Windows 2008 R2 
(disconnect: Invalid licensing message). A newer version solved the 
problem. After this we got crash to connect to older Windows 2003 R2 
(segfaults/ Speicherzugriffsfehler). With the old version for jessie we 
can connect successful. But in this case we got no connection to Win 
2008 R2 any more. The solution for this is to install the original 
version from https://github.com/rdesktop/rdesktop. Now we can connect to 
older and newer versions of windows. But the version from git has a 
other bug if you start rdesktop without console. This we solved and now 
you can download the package from 
http://debian.b-c-s.net/dists/bcs/bcs/binary-amd64/x11/rdesktop_1.8.3-bcs_amd64.deb

> I hope the package solves your problem and you can close the bug.
>
> Mit freundlichen Grüßen
>
> Carsten Burkhardt
>
> --
> Dipl. Ing.Carsten Burkhardt | c.burkha...@b-c-s.de
> bcs kommunikationslösungen
> Inh. Dipl. Ing. Carsten Burkhardt
> Harz 51 | 06108 Halle (Saale) | Germany
> tel +49 345 29849-0 | fax +49 345 29849-22
>
> www.b-c-s.de | www.halle.it | www.wivewa.de
>
> EINFACH ADRESSEN, TELEFONATE UND DOKUMENTE VERWALTEN - MIT WIVEWA -
> IHREM WISSENSVERWALTER FUER IHREN BETRIEB!
>

Hello Carsten, thank you for the reply.

Your package works, but for some reason it forces the layout of my 
keyboard to english when I log in. I also will only mark this bug as 
solved when they fix this in the main repository package.


 But thank you very much.

--
Att: Gabriel Furtado Pires
Depto TI
Tel 4795-8323

Bug#884227: debian-policy: please add zlib to common licenses

[Markus Koschany]

Am 13.12.2017 um 19:21 schrieb Jonathan Nieder:
> Markus Koschany wrote:
> 
>> License: zlib
>> Source: https://opensource.org/licenses/Zlib
>> Example packages:
>> https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29
> 
> Hm.  The license says
> 
>   3. This notice may not be removed or altered from any source distribution.
> 
> And part of 'This notice' is a copyright line that varies from package
> to package.  Since the license text is very short, it seems simplest
> for packages to keep reproducing the license text --- it's not too
> painful disk space-wise and it is much clearer license-wise.
> 
> So I don't believe it belongs in common-licenses.

I respectfully disagree. The zlib license is one of the most common
permissive licenses in the world. The license text ("this notice") is
always the same. The only line that differs is the copyright holder but
the name is not part of the license text itself. So writing:

File: foo.bar
Copyright: 2017, John Smith
License: zlib

is exactly the same as saying

The file foo.bar is

Copyright 2017, John Smith

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must
   not claim that you wrote the original software. If you use this
   software in a product, an acknowledgment in the product
   documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must
   not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source
   distribution.



signature.asc
Description: OpenPGP digital signature

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[Bill Allombert]

On Wed, Dec 13, 2017 at 07:59:15PM +0100, Markus Koschany wrote:
> No, this is entirely about our most precious resources: time and human
> beings
> 
> You also have to format the license in such a way that it complies with
> copyright format 1.0. For instance that means you have to put dots on
> every empty line. You can make a simple experiment: Take a stopwatch,
> find a plain-text version of this license on the internet, format the
> file according to copyright format 1.0 and stop the time. Then stop the
> time how long it takes to write this:
> 
> License: [AGPL-3+]

The time will be about the same. The real time is spent look at all the
source files checking whether they do not carry different licences or license
grants that the main file, which is actually very common, for example
aclocal.m4. (yes, the ftp masters do that).

Otherwise we could write a script to generate the copyright file.

In any case, before going farther with this we need a run of
tools/license-count.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#881715: alsa-utils: High CPU usage on the default device

[Andoru]

Okay, so I installed Arch from scratch with a minimalist set-up of OpenBox
and tint2, installed alsa-utils and alsa-tools, and made that modprobe
config file to disable HDMI output, just like I did when I did the
netinstall of Debian. Then installed vlc and played all the files I played
previously (in FLAC, ogg, mp3, etc), and both when using the default device
and when selecting Analog Front Speakers subdevice, the CPU usage rarely
passes the 5% mark. I've also tried foobar2000 through wine, and got the
same result.

Here's some info about the alsa-utils package under Arch:


$ pacman -Qi alsa-utils
Name: alsa-utils
Version : 1.1.5-2
Description : An alternative implementation of Linux sound support
Architecture: x86_64
URL : http://www.alsa-project.org
Licenses: GPL
Groups  : None
Provides: None
Depends On  : alsa-lib>1.0.24  pciutils  ncurses  psmisc  libsamplerate
  fftw
Optional Deps   : None
Required By : None
Optional For: None
Conflicts With  : None
Replaces: None
Installed Size  : 2042.00 KiB
Packager: Anatol Pomozov 
Build Date  : Sat Nov 18 17:11:48 2017
Install Date: Wed Dec 13 16:44:06 2017
Install Reason  : Explicitly installed
Install Script  : No
Validated By: Signature
__



So this makes it pretty clear that I wasn't talking out of my ass, and that
there's something fishy going on with Debian's implementation of ALSA, or
there was something fixed between versions 1.1.3 and 1.1.5.

Bug#593940: [Pkg-dns-devel] Bug#593940: bind9utils: dnssec-{keygen, signzone} should not be in /usr/sbin

[Daniel Kahn Gillmor]

Hi all--

On Wed 2017-12-13 16:00:26 +0100, Bernhard Schmidt wrote:
> Control: tags -1 + wontfix

I don't think this is a good resolution for #593940, and i hope we can
revert it.

> On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote:
>
>> Package: bind9utils
>> Version: 1:9.7.1.dfsg.P2-2
>> Severity: normal
>> 
>> Why are dnssec-{keygen,signzone} in /usr/sbin?  They are perfectly usable
>> from normal user accounts and zone signing actions are not exactly carried
>> through by "system binaries" as specified by the FHS.
>
> This is where upstream (and every other distribution) puts these
> files.

By this argument, we would never fix any upstream bugs at all :)  Debian
has the opportunity to lead the way here.

> Changing this now would break compatibity with everyone else and
> existing scripts referencing the full path name.

Debian policy §6.1 (about maintainer scripts) says:

Programs called from maintainer scripts should not normally have a
path prepended to them. Before installation is started, the package
management system checks to see if the programs ldconfig,
start-stop-daemon, and update-rc.d can be found via the PATH
environment variable. Those programs, and any other program that one
would expect to be in the PATH, should thus be invoked without an
absolute pathname. Maintainer scripts should also not reset the
PATH, though they might choose to modify it by prepending or
appending package-specific directories. These considerations really
apply to all shell scripts.

Note the last sentence ;)

Yes, people do put the full path in their scripts, which makes them
brittle and unfortunate.  Why do people put the full path in their
scripts?  Often it's because the tools they want to use aren't shipped
already in the $PATH.  For example, the useful tools in bind9utils.

So actually fixing this bug would lead to less brittle systems in the
future, which is a good thing.

> Nothing prevents you from calling these programs with the full path (or
> changing PATH in your script). 

If we want to continue supporting things that have embedded the full
path, we can ship symlinks in /usr/sbin/ that point back to /usr/bin.

If we shipped these backward-compatibility symlinks, would that be
acceptable to address your concerns?

   --dkg


signature.asc
Description: PGP signature

Bug#884309: starpu-examples: depends indirectly on nonfree package libsocl-contrib-1.2-0

[Jonas Smedegaard]

Quoting Samuel Thibault (2017-12-13 19:54:59)
> Re-answering :)
> 
> Jonas Smedegaard, on mer. 13 déc. 2017 19:36:47 +0100, wrote:
>> The issue I raise here is more generally that the package 
>> dependencies declared are not deterministic regarding main versus 
>> non-main packages.
> 
> I understand, but I don't know how to express what we want: both 
> choice for the user, and main by default.

I believe (as I just now posted in a separate mail) it is doable by 
first declaring with version and then without version.

But possibly that is not strict enough, because recently APT gained 
support for versioned virtual packages.  Better would be that you change 
to use a different name for the virtual package, and then declare that 
virtual package last - like this:

Depends: libsocl-1.2-0 (= 1.2.3+dfsg-3) | libsocl-any-1.2-0


 - Jonas

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

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


signature.asc
Description: signature

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Markus Koschany]

Am 13.12.2017 um 19:56 schrieb Jonathan Nieder:
> Hi,
> 
> Markus Koschany wrote:
> 
>> I would like to argue that disk space is no longer an issue in 2017 and
>> people with special needs (embedded systems) will most likely remove
>> /usr/share/common-licenses anyway.
> 
> I agree: space on installation media and network transfer time are more
> important than disk space these days.
> 
> 
>>Thus the more DFSG-licenses we
>> install into /usr/share/common-licenses the more time can be saved for
>> more important issues than quoting licenses.
> 
> I'm confused.  Can you explain your workflow a little more?
> 
> I wouldn't expect using upstream's LICENSE file to take significantly
> more time than replacing it with a pointer to common-licenses.  I'd
> actually expect it to take more time.
> 
> If all we care about is maintainer time spent, then we should
> eliminate common-licenses.
> 
> Puzzled,
> Jonathan

Let me try to explain it this way: Take src:ufoai-data or src:netbeans
for example. Both packages ship approximately a dozen different
licenses. I can't simply copy the upstream license because I have
to format it to make it copyright format 1.0 compliant. As an
experienced packager I have already done this before and I can just copy
my previous work but imagine all the other (maybe new) Debian
contributors who are facing the same problem at the moment. They will
have to do the same thing over and over again. So the simplest solution
would be to bundle all DFSG-licenses in one place and to allow that
people can reference them like that

License: [EPL-1.0]

and then everyone knows that this file is licensed under the same
license located in /usr/share/common-licenses/EPL-1.0

Plain and simple. It's not a big deal if you can save 5 minutes for one
license. It's a big deal if all people can save this time. Just multiply
this with all affected packages. Please let us do more important work
for Debian than copy licenses.

Thanks

Markus







signature.asc
Description: OpenPGP digital signature

Bug#884316: mailman3-suite: Unable to use nginx because of a typo in control file

[Philip Frei]

Package: mailman3-suite
Version: 0+20170523-2
Severity: minor
Tags: patch

Hi,

it's great to see mailman3 in Debian. Thanks a lot for your efforts.

There is a small typo in the control file that prevents to use nginx
with this package. Patch is attached.

regard,
Phil
--- control.orig2017-12-13 19:49:17.022251933 +0100
+++ control 2017-12-13 19:49:26.078320831 +0100
@@ -26,7 +26,7 @@
  uwsgi,
  uwsgi-plugin-python,
  ${misc:Depends}
-Recommends: libapache2-mod-proxy-uwsgi | nxginx, postgresql
+Recommends: libapache2-mod-proxy-uwsgi | nginx, postgresql
 Description: Django project integrating Mailman3 Postorius and HyperKitty
  This django web application provides the Mailman3 Postorius web interface
  and the HyperKitty mailinglist archiver integrated into one project.