Bug#798323: Building for i386 on amd64 tries to install amd64 packages into i386 chroot

[Gaudenz Steinlin]

 installation failed
Not removing build depends: cloned chroot in use

┌──┐
│ Cleanup  │
└──┘

Not cleaning session: cloned chroot in use
Keeping session: jessie-i386-42fc61d4-1d1f-4d26-8660-ba04a5cffb6c
E: Core build dependencies not satisfied; skipping

┌──┐
│ Summary  │
└──┘

Build Architecture: i386
Build-Space: 0
Build-Time: 0
Distribution: jessie-backports
Fail-Stage: install-deps
Host Architecture: i386
Install-Time: 0
Job: /home/gaudenz/debian/owncloud/owncloud-client_2.0.0+dfsg-1~bpo8+1.dsc
Machine Architecture: amd64
Package: owncloud-client
Package-Time: 0
Source-Version: 2.0.0+dfsg-1~bpo8+1
Space: 0
Status: failed
Version: 2.0.0+dfsg-1~bpo8+1

Finished at 20150908-0018
Build needed 00:00:00, 0k disc space

Bug#798305: [Android-tools-devel] Bug#798305: android-tools-adb: Packaged version of adb (1.0.31) fails to recognize newer devices.

[GCS]

Hi Scott,

On Sat, Sep 5, 2015 at 1:24 AM, Scott James Wakeling  wrote:
>I have re-packaged android-tools against upstream version
>android-5.1.1_r13, which includes adb version 1.0.32.
 Sounds good. Did you try it with several devices?

>I will contact the maintainers to see if an NMU is required.
 No need to NMU. Please give me the location of your package and I can
review it.

Regards,
Laszlo/GCS

Bug#798329: ifconfig: changed output format breaks scripts

[Martín Ferrari]

THorsten,

On 08/09/15 10:25, Thorsten Glaser wrote:

> the changed output format of ifconfig breaks scripts parsing it.
[..]
> This particularily breaks both getting the MAC address and
> the/an IP address.

I don't think it is feasible to try and keep the old format, I have
finally updated net-tools to what upstream has been doing in the past 10
years..

Is this breaking a package or just your scripts?

In any case, I think you should be doing this differently. Either using
iproute2 that has a parseable format (although that has changed too), or
direcly parsing files in /proc/net

-- 
Martín Ferrari (Tincho)

Bug#798334: opu: package maven2/2.2.1-12+deb7u1

[Emmanuel Bourg]

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

Hi,

Please accept maven2/2.2.1-12+deb7u1 in wheezy-proposed-updates, this update
combined with the maven2-core update (#779670) fixes a security concern with
Maven 2 (#779337).

Thank you,

Emmanuel Bourg


--- maven2-2.2.1/debian/changelog   2012-08-16 21:09:02.0 +0200
+++ maven2-2.2.1/debian/changelog   2015-09-08 10:01:32.0 +0200
@@ -1,3 +1,11 @@
+maven2 (2.2.1-12+deb7u1) wheezy-proposed-updates; urgency=high
+
+  * Rebuild with libmaven2-core-java 2.2.1-8+deb7u1: Use a secure connection
+by default to download artifacts from the Maven Central repository
+(Closes: #779337)
+
+ -- Emmanuel Bourg   Tue, 08 Sep 2015 09:59:46 +0200
+
 maven2 (2.2.1-12) unstable; urgency=low

   * Team upload.
diff -Nru maven2-2.2.1/debian/control maven2-2.2.1/debian/control
--- maven2-2.2.1/debian/control 2012-08-16 21:07:22.0 +0200
+++ maven2-2.2.1/debian/control 2015-09-08 10:00:50.0 +0200
@@ -7,7 +7,7 @@
 Build-Depends-Indep: maven-repo-helper, ant-optional, junit, 
libmaven-clean-plugin-java,
   libmaven-compiler-plugin-java, libmaven-install-plugin-java, 
libmaven-jar-plugin-java,
   libmaven-resources-plugin-java, libmaven-shade-plugin-java,
-  libmaven2-core-java (>= 2.2.1-4~), maven-ant-helper
+  libmaven2-core-java (>= 2.2.1-8+deb7u1~), maven-ant-helper
 Build-Depends: debhelper (>= 7), cdbs (>= 0.4.5.3), default-jdk, ant
 Standards-Version: 3.9.3
 Homepage: http://maven.apache.org/

Bug#798261: [Pkg-fonts-devel] Bug#798261: ITP: fonts-roboto-fontface -- largely geometric, friendly and open curves font

[Jonas Smedegaard]

Quoting Thomas Goirand (2015-09-08 09:28:15)
> On 09/07/2015 08:42 PM, Jonas Smedegaard wrote:
>>> If you wish to drop the generation of fonts-roboto from the 
>>> fonts-android package, then good.
>>
>> I think the better approach is to keep the fonts-roboto package, have 
>> your package exclude fonts, depend on the fonts-roboto package, and 
>> symlink font files from there as needed.
>
> I don't think so. The fonts-roboto package currently only provides 
> .tff files, which are useless for the web. The sources aren't the 
> same.

What are the sources, then?


> Also, I don't think the FTP masters would like to have even more 
> binary packages and dependencies. If these can be avoided, it's best 
> for the Debian infrastructure, I heard.

It is not best for Debian to track actual upstreams as our upstream 
rather than redistributors.


>>> Do you think I should join the pkg-fonts group to maintain these 
>>> fonts under the group?
>>
>> We can always use more helping hands in the fonts team :-)
>>
>> But if your focus is on OpenStack then perhaps just coordinate with 
>> the font team on tuning the fonts-roboto package to provide what is 
>> needed for reuse with OpenStack - i.e. those web representations of 
>> the font (CSS/Sass/Less sounds like OpenStack-specific glue so 
>> probably makes best sense to package separately).
>
> They aren't OpenStack specific, it's just modern Javascript stuff, 
> which can be reused by any project.

Great - then suggest maintainers of the existing package to adopt those 
tiny files too.


 - 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#798239: logger: wrong timestamps for long-running connections

[Andreas Henriksson]

Hello again.

On Tue, Sep 08, 2015 at 10:17:28AM +0200, Thorsten Glaser wrote:
[...]
> Does this mean that the syslog-specific part of logger(1) is
> basically unmaintained in Debian?
[...]

It means that util-linux, just like almost any other package, is
maintained with volunteer efforts. That effort relies on contributions.
We share the burden. You repay my work with contributing your own
improvements. If you want an actual support contract then you can always
make me your bitch by paying the standard consulting fee... I need to
eat too.
My volunteer time is limited and this issue is nowhere near the
top of my list as it doesn't even affect me.
I hope you appreciate the free support (and shitload of free work)
you've been given so far.

[...]
> If so, were I to suggest a fix for the other problem with it, would you
> consider adding it? (The one where when the syslog dæmon is restarted, input
> is no longer sent to it.)
[...]

You open up a bug report for every separate issue. Then attach
whatever information you can provide to each bug report.

Please do not mix up information about different issues in
all bug reports. Try also not to clutter the bug reports, eg.
do not send inquiries about support contracts through bug reports.

Regards,
Andreas Henriksson

Bug#796885: [rt.debian.org #5963] AutoReply: Please add Tomasz Nitecki's key to the DM keyring

[Aníbal Monsalve Salazar]

Control: package debian-maintainers
Control: tags -1 + pending

Hello Tomasz Nitecki,

Your DM application was accepted and the corresponding RT ticket is
posted at https://rt.debian.org/Ticket/Display.html?id=5963

Currently, rt.debian.org isn't accessible for the general public. It
was sometime ago. Maybe one of your advocates will look at your RT
ticket for you, after it has been taken by a keyring maintainer. See
http://wiki.debian.org/rt.debian.org

Thank you for your contribution to the Debian Project.

Cheers,

Aníbal

On Tue, 2015-09-08 06:05:05 +, Debian Keyring requests (Incoming) via RT 
wrote:
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding
>
>   "Please add Tomasz Nitecki's key to the DM keyring",
>
> a summary of which appears below the dashed line.
>
> There is no need to reply to this message right now.  Your ticket has
> been assigned an ID of [rt.debian.org #5963].
>
> Please include the string
>
>   [rt.debian.org #5963]
>
> in the subject line of all future correspondence about this issue. To
> do so, you may reply to this message.
>
> -
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> keyring-maint:
>   please add key ID 7C0B0DE7EA5992117BA2F5CCE6C710E2E5C1E4A3
> to the DM keyring
>   please notify 796885-d...@bugs.debian.org
> 
> Changed-By: Anibal Monsalve Salazar 
> Date: Tue, 08 Sep 2015 05:47:04 +
> BTS: http://bugs.debian.org/796885
> Comment: Add Tomasz Nitecki  as a Debian Maintainer
> Agreement: https://lists.debian.org/debian-newmaint/2015/08/msg00032.html
> Advocates: 
>   lucas - https://lists.debian.org/debian-newmaint/2015/08/msg00033.html
>   boutil - https://lists.debian.org/debian-newmaint/2015/08/msg00037.html
>   holger - https://lists.debian.org/debian-newmaint/2015/08/msg00041.html
> KeyCheck:
>   pub   4096R/E5C1E4A3 2014-02-16 [expires: 2017-08-05]
> Key fingerprint = 7C0B 0DE7 EA59 9211 7BA2  F5CC E6C7 10E2 E5C1 E4A3
>   uid  Tomasz Nitecki 
>   sig! DD079461 2015-08-26  Gerfried Fuchs 
>   sig! E0163787 2015-08-27  Kristoffer H Rose 
>   sig! 8AD04B1A 2015-08-22  Philipp Matthias Hahn (Privat) 
> 
>   sig! C2B35520 2015-04-12  Cyril Brulebois 
>   sig! 93052E03 2015-04-14  Christian Hofstaedtler 
> 
>   sig! B29B232A 2015-04-19  Maximiliano Curia 
>   sig! 1DDD8C9B 2015-04-25  Aurelien Jarno 
>   sig! 11E149E9 2015-06-04  Cedric Boutillier 
>   sig! 24B17D29 2015-08-18  Tomasz Buchert 
>   sig! 1A2D268D 2015-08-20  Andrew Shadura 
>   sig! A6357FB7 2015-08-23  Tobias Frost 
>   sig! F00A2BE6 2015-08-28  Ritesh Raj Sarraf 
>   sig! F4DFBE99 2015-08-31  Lucas Nussbaum 
>   sig! 76E2AC7B 2015-09-02  Hector Oron Martinez (zumbi) 
> 
>   sig! 7BD756C4 2015-04-13  Daniel Pocock 
>   sig! A218D83C 2015-04-13  Jean-Michel Vourgere 
>   sig! CD460BDE 2015-04-15  Antonio Terceiro 
> 
>   sig! 2502FE39 2015-08-21  Cord Beermann 
>   sig! D49AE731 2015-08-23  Christoph Egger 
>   sig! 6D866396 2015-08-24  Stefano Zacchiroli 
>   sig! 12D2A7AE 2015-08-24  Christoph Berg 
>   sig! F14A64A2 2015-08-26  Aaron M. Ucko 
>   sig! B35FEC3C 2015-09-03  Eduard Bloch 
>   sig! A7457645 2015-08-21  Piotr Ozarowski 
>   sig! 7FD863FE 2015-08-23  Salvatore Bonaccorso 
> 
>   sig! 2BEF0A33 2015-08-24  Didier Raboud 
>   sig! C1A00121 2015-08-21  Jonas Smedegaard 
>   sig!3E5C1E4A3 2014-02-16  Tomasz Nitecki 
>   sig!3E5C1E4A3 2015-08-06  Tomasz Nitecki 
>   sig!3E5C1E4A3 2014-02-16  Tomasz Nitecki 
>   sig!3E5C1E4A3 2014-12-15  Tomasz Nitecki 
>   uid  Tomasz Nitecki 
>   sig! DD079461 2015-08-26  Gerfried Fuchs 
>   sig! E0163787 2015-08-27  Kristoffer H Rose 
>   sig! 8AD04B1A 2015-08-22  Philipp Matthias Hahn (Privat) 
> 
>   sig! C2B35520 2015-04-12  Cyril Brulebois 
>   sig! 93052E03 2015-04-14  Christian Hofstaedtler 
> 
>   sig! B29B232A 2015-04-19  

Bug#798329: ifconfig: changed output format breaks scripts

[Thorsten Glaser]

Package: net-tools
Version: 1.60+git20150829.73cef8a-1
Severity: important

Hi,

the changed output format of ifconfig breaks scripts parsing it.

Before:

br0   Link encap:Ethernet  HWaddr 90:e2:ba:0c:b8:17  
  inet addr:172.26.3.108  Bcast:172.26.255.255  Mask:255.255.0.0
  inet6 addr: fe80::21b:21ff:fe62:2577/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2351724 errors:0 dropped:2931 overruns:0 frame:0
  TX packets:525699 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:1659213748 (1.5 GiB)  TX bytes:216861337 (206.8 MiB)

After:

br0: flags=4163  mtu 1500
inet 172.26.3.108  netmask 255.255.0.0  broadcast 172.26.255.255
inet6 fe80::21b:21ff:fe62:2577  prefixlen 64  scopeid 0x20
ether 90:e2:ba:0c:b8:17  txqueuelen 0  (Ethernet)
RX packets 2351867  bytes 1659222913 (1.5 GiB)
RX errors 0  dropped 2931  overruns 0  frame 0
TX packets 525708  bytes 216861987 (206.8 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This particularily breaks both getting the MAC address and
the/an IP address.

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

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

Versions of packages net-tools depends on:
ii  libc6  2.19-19

net-tools recommends no packages.

net-tools suggests no packages.

-- no debconf information

Bug#785216: pgbadger: New upstream releases available

[Paolo Cavallini]

What is the specific problem in upgrading this? The current version has
a rather serious bug, fixed upstream[0].
Available for help if necessary.
Thanks.

[0]https://github.com/dalibo/pgbadger/issues/57
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Bug#798328: ITP: golang-github-spf13-jwalterweatherman -- Go library for printing to the terminal and logging to files

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-spf13-jwalterweatherman
  Version : 0.0~git20141219.0.3d60171-1
  Upstream Author : Steve Francia
* URL : https://github.com/spf13/jwalterweatherman
* License : MIT
  Programming Lang: Go
  Description : Go library for printing to the terminal and logging to files

 jWalterWeatherman provides seamless printing to the terminal (stdout)
 and logging to a io.Writer (file) that's as easy to use as fmt.Println.
 .
 JWW is primarily a wrapper around the excellent Go standard log library.
 It provides a few advantages over using the standard log library alone:
 .
  * One library for both printing to the terminal and logging (to files).
  * Allow the user to easily control what levels are printed and logged
  * No unnecessary initialization cruft.  Just use it.

Reason for packaging:

 Needed by Hugo, A Fast and Flexible Static Site Generator - http://gohugo.io/

Bug#798325: new upstream (5.1.1)

[Jérémy Bobbio]

Daniel Baumann:
> it would be nice if you could upgrade to the current upstream version
> (5.1.1).

Upstream has still not pushed the tag on the Git repository. I'm asking
again.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#798261: [Pkg-fonts-devel] Bug#798261: ITP: fonts-roboto-fontface -- largely geometric, friendly and open curves font

[Thomas Goirand]

On 09/07/2015 08:42 PM, Jonas Smedegaard wrote:
>> If you wish to drop the generation of fonts-roboto from the 
>> fonts-android package, then good.
> 
> I think the better approach is to keep the fonts-roboto package, have 
> your package exclude fonts, depend on the fonts-roboto package, and 
> symlink font files from there as needed.

I don't think so. The fonts-roboto package currently only provides .tff
files, which are useless for the web. The sources aren't the same.

Also, I don't think the FTP masters would like to have even more binary
packages and dependencies. If these can be avoided, it's best for the
Debian infrastructure, I heard.

>> Do you think I should join the pkg-fonts group to maintain these fonts 
>> under the group?
> 
> We can always use more helping hands in the fonts team :-)
> 
> But if your focus is on OpenStack then perhaps just coordinate with the 
> font team on tuning the fonts-roboto package to provide what is needed 
> for reuse with OpenStack - i.e. those web representations of the font 
> (CSS/Sass/Less sounds like OpenStack-specific glue so probably makes 
> best sense to package separately).

They aren't OpenStack specific, it's just modern Javascript stuff, which
can be reused by any project.

Cheers,

Thomas Goirand (zigo)

Bug#796956: Note that this is a docked laptop using external monitor

[eric2.valette]

I now have half a dozen boxes that works correctly and this is the only 
one that is a docked laptop using an external monitor with internal LVDS 
display off. So far as I had multiple temporary breakage on various 
boxes due to partial/incompatible packages versions uploads, I did not 
consider it was a specific case but now only this docked laptop remains 
broken.


--eric


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#798332: witty: blank page

[ioann sys]

Package: witty
Version: 3.3.4+dfsg-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Hello! After upgrading witty,my projects has been run, but i can see content
(images, buttons and title!)



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

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

Versions of packages witty depends on:
ii  libwt38 3.3.4+dfsg-3
ii  libwtdbo38  3.3.4+dfsg-3
ii  libwtdbofirebird38  3.3.4+dfsg-3
ii  libwtdbopostgres38  3.3.4+dfsg-3
ii  libwtdbosqlite383.3.4+dfsg-3
ii  libwtext38  3.3.4+dfsg-3
ii  libwthttp38 3.3.4+dfsg-3
ii  witty-examples  3.3.4+dfsg-3

witty recommends no packages.

witty suggests no packages.

-- no debconf information

Bug#798333: linux: remove loongson 2E/2F support and add octeon to mipsel

[YunQiang Su]

Package: src:linux
Version: 4.2-1~exp1

We are planning to migrate mips/mipsel to MIPS32R2 from MIPS II.
So loongson 2E/2F won't supported any more.
So please remove these 2 flavors.

On the other hand, please add octeon support to mipsel,
as it has been in mips64el now.

-- 
YunQiang Su


0001-remove-Loongson-2E-F-support.patch
Description: Binary data


0002-add-octeon-support-to-mipsel.patch
Description: Binary data

Bug#798305: [Android-tools-devel] Bug#798305: Bug#798305: android-tools-adb: Packaged version of adb (1.0.31) fails to recognize newer devices.

[Scott Wakeling]

> > I have re-packaged android-tools against upstream version
> > android-5.1.1_r13, which includes adb version 1.0.32.
> > Sounds good. Did you try it with several devices?
> 
I've tested it with a Cubot X12 and Nexus 9.

The package is here:

https://github.com/scottwakeling/android-tools
I may move it to alioth soon, as recommended by Hans-Christoph.

A review and perhaps testing on other devices would be valuable.

-scott

Bug#798339: upgrade-reports: NIS fails to restart after apt-get upgrade

[Koen De Maeyer]

Package: upgrade-reports
Severity: normal

Dear Maintainer,

   * What led up to the situation?
"Apt-get update && apt-get -y upgrade" failed to restart the nis and
autofs services (autofs failures were caused by nis)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Manually restarting the nis service was not successful, full reboot was

   * What was the outcome of this action?
   * What outcome did you expect instead?
I expect post-upgrade reboots to be neccessary on windows only

This is the apt-history log associated with the upgrade:
Start-Date: 2015-09-08  08:52:26
Commandline: apt-get -y upgrade
Upgrade: bind9-host:amd64 (9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3),
libio-socket-ssl-perl:amd64 (2.002-2, 2.002-2+deb8u1), liblwres90:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3), apt:amd64 (1.0.9.8,
1.0.9.8.1), libgnutls-openssl27:amd64 (3.3.8-6+deb8u1, 3.3.8-6+deb8u3),
multiarch-support:amd64 (2.19-18, 2.19-18+deb8u1), libdns100:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3), libisc-export95:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3),
linux-image-3.16.0-4-amd64:amd64 (3.16.7-ckt11-1+deb8u2,
3.16.7-ckt11-1+deb8u3), libisccfg90:amd64 (9.9.5.dfsg-9+deb8u2,
9.9.5.dfsg-9+deb8u3), libbind9-90:amd64 (9.9.5.dfsg-9+deb8u2,
9.9.5.dfsg-9+deb8u3), dbus:amd64 (1.8.18-0+deb8u1, 1.8.20-0+deb8u1),
libgnutls-deb0-28:amd64 (3.3.8-6+deb8u1, 3.3.8-6+deb8u3),
libgdk-pixbuf2.0-common:amd64 (2.31.1-2, 2.31.1-2+deb8u2),
libgl1-mesa-dri:amd64 (10.3.2-1, 10.3.2-1+deb8u1), apt-utils:amd64
(1.0.9.8, 1.0.9.8.1), libgudev-1.0-0:amd64 (215-17+deb8u1,
215-17+deb8u2), python-apt:amd64 (0.9.3.11, 0.9.3.12),
libc-dev-bin:amd64 (2.19-18, 2.19-18+deb8u1), libpam-systemd:amd64
(215-17+deb8u1, 215-17+deb8u2), libc-bin:amd64 (2.19-18,
2.19-18+deb8u1), libc6:amd64 (2.19-18, 2.19-18+deb8u1),
libglapi-mesa:amd64 (10.3.2-1, 10.3.2-1+deb8u1), libapt-inst1.5:amd64
(1.0.9.8, 1.0.9.8.1), libslp1:amd64 (1.2.1-10, 1.2.1-10+deb8u1),
libgtk-3-bin:amd64 (3.14.5-1, 3.14.5-1+deb8u1), dnsutils:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3), libdbus-1-3:amd64
(1.8.18-0+deb8u1, 1.8.20-0+deb8u1), udev:amd64 (215-17+deb8u1,
215-17+deb8u2), base-files:amd64 (8+deb8u1, 8+deb8u2), libruby2.1:amd64
(2.1.5-2+deb8u1, 2.1.5-2+deb8u2), libudev1:amd64 (215-17+deb8u1,
215-17+deb8u2), libgl1-mesa-glx:amd64 (10.3.2-1, 10.3.2-1+deb8u1),
libapt-pkg4.12:amd64 (1.0.9.8, 1.0.9.8.1), libgtk-3-0:amd64 (3.14.5-1,
3.14.5-1+deb8u1), systemd-sysv:amd64 (215-17+deb8u1, 215-17+deb8u2),
systemd:amd64 (215-17+deb8u1, 215-17+deb8u2), libgtk-3-common:amd64
(3.14.5-1, 3.14.5-1+deb8u1), libgdk-pixbuf2.0-0:amd64 (2.31.1-2+b1,
2.31.1-2+deb8u2), tzdata:amd64 (2015e-0+deb8u1, 2015f-0+deb8u1),
libsystemd0:amd64 (215-17+deb8u1, 215-17+deb8u2), libc6-dbg:amd64
(2.19-18, 2.19-18+deb8u1), linux-libc-dev:amd64 (3.16.7-ckt11-1+deb8u2,
3.16.7-ckt11-1+deb8u3), python-apt-common:amd64 (0.9.3.11, 0.9.3.12),
libisccfg-export90:amd64 (9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3),
libdns-export100:amd64 (9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3),
locales:amd64 (2.19-18, 2.19-18+deb8u1), libirs-export91:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3), libisccc90:amd64
(9.9.5.dfsg-9+deb8u2, 9.9.5.dfsg-9+deb8u3), libc6-dev:amd64 (2.19-18,
2.19-18+deb8u1), libisc95:amd64 (9.9.5.dfsg-9+deb8u2,
9.9.5.dfsg-9+deb8u3), rsyslog:amd64 (8.4.2-1, 8.4.2-1+deb8u1),
cron:amd64 (3.0pl1-127, 3.0pl1-127+deb8u1)
End-Date: 2015-09-08  08:55:28




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

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

Bug#798338: Please package 0.23.2 available upstream

[Thomas Goirand]

Source: libgit2
Version: 0.22.2-2
Severity: important

Hi,

Version 0.23.2 is available upstream, and is needed to fix the FTBFS with
the latest version of python-pygit2, which I need to package in order to
fix the RC bug #796657.

I saw that in your Git, you already prepared version 0.23.1. What was
preventing you from uploading?

If you can't upload, please let me know, and I'll help (with NMU or
sponsoring).

Also, since pygit2 and libgit2 are really related, it'd be nice to
maintain them both in a single team, so that we can coordinate the
upload of both at the same time. Would you like to join the OpenStack
packaging team and maintain libgit2 there? Or shall we create a new team
for it? Anything which is ok to you will be ok for me, as long as we can
work in a better way, as a team.

Cheers,

Thomas Goirand (zigo)

Bug#798329: ifconfig: changed output format breaks scripts

[Thorsten Glaser]

On Tue, 8 Sep 2015, Martín Ferrari wrote:

> Is this breaking a package or just your scripts?

This is breaking at least two scripts of mine, which is where and why
I noticed this immediately after the dist-upgrade today, but there’ll
be others lurking. Probably none of them packaged, though.

> In any case, I think you should be doing this differently. Either using
> iproute2 that has a parseable format (although that has changed too), or

This won’t work, I did quite the WTF today at iproute2 now, as it
appends “@NONE” to the interface names.

I need reliable, consistent, parsable output across all Debian versions
(and some derivates).

> direcly parsing files in /proc/net

Excuse me, but WTF?

The standard Unix interface for things is stdout of other commands,
as in, filters and pipes. ifconfig is *the* standard utility to get
information about interfaces.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#790809: Please enable ARM64 support

[Andreas Beckmann]

On 2015-09-08 09:53, Edmund Grimley Evans wrote:
> I think the package nvidia-settings should probably be built for all
> architectures, even if there's no prospect of a working driver.
> 
> See this:
> 
> https://buildd.debian.org/status/package.php?p=mate-sensors-applet=sid

You probably want libxnvctrl-dev available for all architectures, that
might be a good idea.


Andreas

Bug#712662: conntrackd: cannot restart daemon after first start

[Arturo Borrero Gonzalez]

Control: tags -1 + fixed
Control: fixed -1 1:1.2.1-1

Hi,

I can confirm that this issue is solved in 1:1.2.1-1, which is
oldstable (wheezy).

Closing now this bug.

best regards.
-- 
Arturo Borrero González

Bug#796044: \heightof stopped working after upgrade

[Christoph Pfister]

FWIW, there is a workaround that has the desired effect (at least in
my context); it's attached in case somebody finds it useful.


2015-08-19 10:58 GMT+02:00 Christoph Pfister :
> 2015-08-19 2:23 GMT+02:00 Norbert Preining :
> 
>> Could you please:
>> * check whether the mwe *plus* loading calc.sty works in older
>>   version?
>
> Yes, that combination works in the older version.
>
>> * check whether your real world example works when loading calc.sty?
>
> No, it also fails with "\pgfmath@dimen@ ...men@@ #1=0.0pt\relax \pgfmath@".
>
>> Thanks
>>
>> Norbert
>
> Christoph


workaround.tex
Description: TeX document

Bug#493322: [Aptitude-devel] Bug#493322: aptitude: pressing 'escape' in search/tree limit dialog should cancel

[Axel Beckert]

Hi Manuel,

Manuel A. Fernandez Montecelo wrote:
> > Just in case you're still in there with your mind: The very same
> > happens with pressing Ctrl-G while Ctrl-G (as well as Escape) closes
> > the according minibuffer-style search box.
> >
> > Maybe you can fix that for Ctrl-G as well. Being an Emacs user, I tend
> > to press Ctrl-G more often than Escape. :-) See also #607118. ;-)
> 
> I am not sure if I understand correctly.

You do:

> I think that what you ask is if this can also be implemented for
> 'Ctrl-G' as well as for 'Esc'.
> 
> In this case, the answer is that yes, it has been implemented for both,
> because I am using what cwidget considers as "Cancel" keys,

Ah, great! Thanks!

> which are these:
> 
>  cancelkey.push_back(KEY_CTRL(L'g'));
>  cancelkey.push_back(key(L'\e', true));
>  cancelkey.push_back(KEY_CTRL(L'['));

Yeah, I remember that code from looking for the cause for #607118. :-)

> (If you can confirm that it works for both before the next release, it
> would be great).

Will try to do so.

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

Bug#798325: new upstream (5.1.1)

[Daniel Baumann]

Package: xul-ext-https-everywhere
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version
(5.1.1).

Regards,
Daniel

Bug#180283: rrdtool: CDEF function PREV(name) timesteps far too mauch

[Goswin von Brederlow]

On Wed, Aug 26, 2015 at 09:26:42AM +, Jean-Michel Vourgère wrote:
> Control: tags -1 +moreinfo
> Control: noowner -1
> 
> Hello Goswin
> 
> I'm cleaning up the rrdtool bug list, and I dig a bit into this one
> submitted back in 2003!
> https://bugs.debian.org/180283
> 
> I'm sorry no one from the Debian project answered you since then.
> 
> 
> You listed the cgi source, but not the actual command used to create the
> rrd database.
> A cgi only works if a database is created first. This is almost
> impossible to answer to your bug report without that information.
> 
> I can only assume you are (were) using code from the original donitor
> whose source code is available at http://sourceforge.net/projects/donitor/
> There, in file /sbin/update_rrd.pl, in function create_rrd, the step is
> set to 120 seconds, and the heartbeat to 240 seconds:
> 
> > rrdcreate esel.rrd --step 120 DS:workload_down:GAUGE:240:U:U 
> > DS:workload_up:GAUGE:240:U:U DS:overhead_in:GAUGE:240:U:U 
> > DS:overhead_out:GAUGE:240:U:U DS:connections:GAUGE:240:U:U 
> > DS:ds1:GAUGE:240:U:U DS:ds2:GAUGE:240:U:U RRA:AVERAGE:0.5:1:360 
> > RRA:AVERAGE:0.5:4:360 RRA:AVERAGE:0.5:16:360 RRA:AVERAGE:0.5:64:360 
> > RRA:AVERAGE:0.5:256:360 RRA:MIN:0.5:4:360 RRA:MIN:0.5:16:360 
> > RRA:MIN:0.5:64:360 RRA:MIN:0.5:256:360 RRA:MAX:0.5:4:360 RRA:MAX:0.5:16:360 
> > RRA:MAX:0.5:64:360 RRA:MAX:0.5:256:360
> 
> Actually, your variable names are different (urate3 versus ds2) but I'll
> assume a moment you were using these settings.
> 
> This means you have:
> - A 2 minutes resolution for 12 hours (meaning if last value is "now",
> then first value is now-11h58)
> - A 8 minutes resolution for 48 hours
> - A 32 minutes resolution for 8 days
> - ...
> 
> 
> Also, you defined:
> CDEF:sdrate3=PREV(sdrate3)
> which is impossible. PREV must be applied to another value, not to
> itself! This may be the source of the problem.
> I'll assume you meant sdrate3=PREV(drate3)
> 
> 
> I may have been able to reproduce the issue, but not just for sdrate3,
> all the data is showing a 8 minutes resolution.
> 
> Therefore, it seems normal that PREV() is 8 minutes earlier. Is it
> possible you did not notice that everything has a 8 pixel horizontal
> resolution but only that the two lines were 8 pixels apart?
> 
> As far as I can tell, x=PREV(x) is not working any more, it doesn't show
> weird things and does not loop nor overflow any more. This may have been
> fixed upstream.
> 
> 
> Now why do we have a 8 minutes resolution?
> 
> It tried different values for --start.
> --start 'end-12h00' yield a 8 minutes resolution
> --start 'end-11h00' yield a 8 minutes resolution
> --start 'end-10h59' yield a 2 minutes resolution
> 
> I may dig a bit in that part. There may be two issues there. A time zone
> one (I'm UTC+1) and an interval one...
> 
> If you still have the data, know the way you created the rrd file,
> and/or how it's filled, it will help pin point that issue.
> 
> Thanks
> 
> -- 
> Nirgal

Sorry, after 12 years I have no idea how I did set that up anymore nor
do I still run it.

MfG
Goswin

Bug#531756: closed by Stéphane Glondu <glo...@debian.org> (Re: Bug#531756: [ocaml] code_of_unix_error available now)

[Goswin von Brederlow]

On Fri, Aug 28, 2015 at 12:27:25PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the ocaml package:
> 
> #531756: Add extern int code_of_unix_error (value error);
> 
> It has been closed by Stéphane Glondu .
> 
> 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 Stéphane Glondu 
>  by
> replying to this email.

Thanks.

MfG
Goswin

Bug#798206: gnome-orca: Binding to report notifications does not work

[Mario Lang]

Jean-Philippe MENGUAL  writes:

> Package: gnome-orca
> Version: 3.16.2-1
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> I use orca 3.16 here, with MATE desktop.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> 1. ins-space
> 2. Create 3 bindings in Bindings tab:
> - ins-f8 for speaking previous notification message;
> - ins-f9 for speaking latest notif message
> - ins-f10 to have notif messages list
>
> 3. Save. 
> 4. On an IRC client in MATE, be highlighted by someone. O!ca reads the notif.
>
>* What was the outcome of this action?
>
> If you issue ins-f8 f9 f10, orca says: "not notification message"
>
>* What outcome did you expect instead?
>
> It should speak the latest message, at least.
>
> *** End of the template - remove these template lines ***
>
> Attached a patch which will likely be applied upst!eam.

Thanks for your report.

The patch attached is already applied upstream.

> Could you apply it to the Debian release?

The patch you sent does not apply to 3.16.2, which is what we have in
Debian unstable right now.
There was an early change during the 3.17 cycle (b1c3c11) which prevents
it from applying cleanly on top of 3.16.2.

> It fixes the problem. This feature is quite useful. The Debian sackage
> should ship it via patch before the next Orca release.

Yes, it is simple.  It would have been simpler (for me) if you actually
submitted a patch that applied cleanly to 3.16.2.
However, indirectly pointing at the corresponding upstream commit is
somewhat sufficient, I managed to manually rebase the patch via git.

[...]

> You could apply too for Jessie.

To make one thing clear, we do not randomly patch stable.
A patch to stable has to fix a serious security issue.
Random simple fixes are *never* going to be applied to stable in
Debian.  This is how things go in Debian.
The reason for this is simply, that even if you think you are sure, you
will accidentally introduce new bugs into the system distribution if you
apply fixes to it more or less at random.

-- 
CYa,
  ⡍⠁⠗⠊⠕


signature.asc
Description: PGP signature

Bug#798340: Whishlist: getting PID or scriptname in mawk

[guerrarob]

Package: mawk
Version: 1.3.3-17ubuntu2

Sometimes it's useful (e.g. to print an help screen) to be able to printout the 
name of the running script:

$ mawk ./myscript.awk
myscript.awk
$

In bash ARGV[0] contains the name of the script, but in awk it just contains 
"awk" regardless the script name. So, to get the script name inside awk one 
could make use of something like

 "ps -p " PROCINFO["pid"] " -o comm=" | getline CMDNAME

but PROCINFO is only a gawk feature.

Is it possible to add such feature?

I'm using Ubuntu 14.04 (trusty).

Bug#798327: xfig: Unable to modify colors of any area except canvas

[sidhu1f]

Package: xfig
Version: 1:3.2.5.c-5
Severity: important

Dear Maintainer,

Unable to change the foreground or background colors of any screen
region (except canvas) such as menus, and tool icons region. Tried
foreground and background options in Xresources as well as commandline
-bg and -fg options. Colors specified as above change the color of
_only_ the canvas regions, not others.


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

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

Versions of packages xfig depends on:
ii  libc62.19-19
ii  libjpeg62-turbo  1:1.4.1-2
ii  libpng12-0   1.2.50-2+b2
ii  libx11-6 2:1.6.3-1
ii  libxpm4  1:3.5.11-1+b1
ii  libxt6   1:1.1.4-1+b1
ii  xaw3dg   1.5+E-18.2

Versions of packages xfig recommends:
ii  transfig   1:3.2.5.e-4
ii  xfig-libs  1:3.2.5.c-5

Versions of packages xfig suggests:
ii  cups-bsd [lpr]  2.0.3-10
ii  cups-client 2.0.3-10
ii  ghostscript 9.16~dfsg-2
ii  gimp2.8.14-1+b1
ii  gsfonts-x11 0.23
ii  netpbm  2:10.0-15.2
pn  spell   
pn  xfig-doc

-- no debconf information

Bug#798324: dpkg-deb: Fix off-by-one write access on versionbuf variable

[Salvatore Bonaccorso]

Package: dpkg
Version: 1.18.2
Severity: normal
Tags: patch

The following was reported by Jacek Wielemborek:

- Begin forwarded message -

Dear Maintainer,

I built dpkg with afl-gcc and AFL_USE_ASAN=1. Here's the base64-encoded
 .deb file it generated:

ITxhcmNoPopkZWJpYW4tYmluYXJ5ICAgMTQ0MTIxMTQ1NiAgMCAgICAgMCAgICAgMTAwNjQ0ICA0
ICAgICAgICAgYAoyLjAKY29udHJvbC50YXIuZ3ogIDE0NDEyMTE0NTYgIDAgICAgIDAgICAgIDEw
MDY0NCAgNDc1ICAgICAgIGAKH4sIAAACA+3RS4vbMBAAYJ/1K+bWBBK/uo6paZcWUmgpC4GE
3rXWJBarSEaSN00P/e1V/Ng+oO0ppYX5sLEsyTNjTZxEV5cGZVH0z+DnZz/O8qLMVnme9fNlmRYR
FNFf0DnPLUBkjfG/2/en9f9UnNRGe2vUlfu/urn5Vf+ztMh/7H+WPU9XEaTU/6vb8PqBH7CC9uwb
o5f4iR9bhY5tTWfrb/MC97xT3rGPaJ00uoI8LuMXy4y9sXUjPda+s2E7V4rdcal9uNFWcMe9byR3
8EEZh/BSmAfzWuC95Do29nDL3uvQAKVQLLfycwiwYmtsUQs3pYbZ7asp2XwxTob3p1K/3/Blzrah
lL7AYSfbWGms9OcKTHtZ4Iq9M0ds+79uvG+rJDmdTvGw/VJUEkpwtZXtEOcpz95Y8A3CZqhLcX3o
QhSYjYcDj8PZzBm8Hb9ZwBqPxgHXAnbGqCHIECCGXYPhTLhF2MtLAqlr1QkUYcD6TF3rvEV+nFIK
Gd7lfXcpLGYQrl0jHbRDEyEMOYj++FDX52l+AadG1s244iAEWvcdeOZgLJ1NGcZfgFndWYvaqzM8
hrOdxywihBBCCCGEEEIIIYQQQgghhBBCCCH/oK+zNHmVACgAAAo=

And here's the crash:

root@1442a2c3a089:~/fuzz/dpkg/o/crashes# dpkg --info
id\:00\,sig\:06\,src\:00\,op\:flip1\,pos\:7
=
==11286==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffbdcdf338 at pc 0x0040cf49 bp 0x7fffbdcdef70 sp 0x7fffbdcdef68
WRITE of size 1 at 0x7fffbdcdf338 thread T0
#0 0x40cf48  (/usr/bin/dpkg-deb+0x40cf48)
#1 0x410dfe  (/usr/bin/dpkg-deb+0x410dfe)
#2 0x4056e2  (/usr/bin/dpkg-deb+0x4056e2)
#3 0x7f38390b8b44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#4 0x4074ca  (/usr/bin/dpkg-deb+0x4074ca)

Address 0x7fffbdcdf338 is located in stack of thread T0 at offset 872 in
frame
#0 0x40b4bf  (/usr/bin/dpkg-deb+0x40b4bf)

  This frame has 13 object(s):
[32, 33) 'nlc'
[96, 100) 'dummy'
[160, 168) 'version'
[224, 232) 'ctrllennum'
[288, 304) 'err'
[352, 384) 'cmd'
[416, 424) 'p1'
[480, 488) 'p2'
[544, 604) 'arh'
[640, 784) 'stab'
[832, 872) 'versionbuf' <== Memory access at offset 872 overflows
this variable
[928, 968) 'ctrllenbuf'
[1024, 1224) 'buf'
HINT: this may be a false positive if your program uses some custom
stack unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x100077b93e10: f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00
  0x100077b93e20: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 f4
  0x100077b93e30: f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 00 00
  0x100077b93e40: 00 00 00 00 00 04 f2 f2 f2 f2 00 00 00 00 00 00
  0x100077b93e50: 00 00 00 00 00 00 00 00 00 00 00 00 f4 f4 f2 f2
=>0x100077b93e60: f2 f2 00 00 00 00 00[f4]f4 f4 f2 f2 f2 f2 00 00
  0x100077b93e70: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00
  0x100077b93e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100077b93e90: 00 00 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x100077b93ea0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
  0x100077b93eb0: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
==11286==ABORTING

To be on the safe side, I'm reporting it as a critical security vuln
because this is a memory error in the core component. Please contact me
on d33...@gmail.com.

- End forwarded message -

Quoting Guillem:

> The .deb is an ar archive w/o the '\n' trailer on the «!» magic
> value. The dpkg-deb/extract.c:extracthalf() function calls read_line()
> passing to it versionbuf with the off-by-one length, that one writes
> 41 bytes into it (with a trailing \0), stomping on whatever is next in
> the stack. But this should in principle have no visible effect because
> regardless of how the compiler has organized the local stack, any
> subsequently used local variable is first assigned so the trailing \0
> would not be in effect, and versionbuf is only ever used to compare
> against shorter constant strings, which should all fail, the first
> against "!\n", then against "0.93", and after that it just
> aborts the program.

Attached is the corresponding patch.

Regards,
Salvatore
>From ac3ee4c3db5ecca5d2c343415273823da4c107ae Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 6 Sep 2015 

Bug#798317: xserver-xorg-video-radeon: Strange interaction of radeon config, screenshot and x11vnc

[Michel Dänzer]

On 08.09.2015 09:58, Luis Mochan wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:7.5.0-1+b1
> Severity: normal
> 
> For some time I have found a strange behavior in the behavior of my radeon
> under X. After a fresh bootstrap I can start an X session without problem,
> except that if I make a screen shot it turns out completely black and if I
> access my computer by running x11vnc locally and vncviewer remotely, the 
> screen
> is also completely black and unusable from the remote location. If I logout 
> and
> login again, the behavior doesn't change.
> 
> If I uncomment the line
>   #   Option  "EXAPixmaps""on"
> in the configuration file
>   /etc/X11/xorg.conf.d/20-radeon.conf
> and restart my display manager (lightdm) X tries to run repeatedly and
> unsuccesfully. Thus, it seems that option doesn't work with my card. The
> strange behavior is the following. When I comment back that line, I recover X
> and furthermore, screenshot and magically x11vnc start working normally!
> 
> Thus, it seems that something good happens irreversibly after I turn on the
> invalid option and then turn it off. Whatever happens, should have happened
> normally without me having to perform this magic, accidentaly discovered step.
> 
> Please let me know what additional information I can provide that may prove
> useful.

[...]

> [   542.255] (**) RADEON(0): Option "SWcursor" "off"
> [   542.255] (**) RADEON(0): Option "EnablePageFlip" "on"
> [   542.255] (**) RADEON(0): Option "RenderAccel" "on"
> [   542.255] (**) RADEON(0): Option "AccelMethod" "EXA"
> [   542.255] (**) RADEON(0): Option "EXAVSync" "off"

I don't know what the problem is, but FWIW you shouldn't enable Option
"RenderAccel", because RENDER acceleration uses the 3D engine, which
isn't validated on RN100 GPUs. That might explain at least the issue
with Option "EXAPixmaps" enabled.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#798239: logger: wrong timestamps for long-running connections

[Thorsten Glaser]

On Mon, 7 Sep 2015, Andreas Henriksson wrote:

> Could you please try the bsdutils version from experimental
> (as the version I just uploaded to unstable has probably not
> yet reached the mirrors when you read this) to check if

No, the version from sid was what I just installed.

Preparing to unpack .../bsdutils_1%3a2.27-1_x32.deb ...
Unpacking bsdutils (1:2.27-1) over (1:2.26.2-9) ...
Processing triggers for man-db (2.7.2-1) ...
Setting up bsdutils (1:2.27-1) ...

This version still exhibits the problem.

> Given you have reproducible testcase, in case you're interested in
> seeing this issue resolved you could run git bisect to find out

Hm, I guess… need to learn how to do that first though…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#798331: RFA: sundials

[Sylvestre Ledru]

Package: wnpp
Severity: normal

Hello,

Not involved in debian science anymore, it would be great if someone could start
maintaining sundial.
There is a new upstream release (2.6.2)

Cheers,
Sylvestre

Bug#798330: ITP: golang-github-samalba-dockerclient -- Docker client library in Go

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Owner: Dmitry Smirnov 

* Package name: golang-github-samalba-dockerclient
  Version : 0.0~git20150905.0.77b723e-1
  Upstream Author : Sam Alba
* URL : https://github.com/samalba/dockerclient
* License : Apache-2.0
  Programming Lang: Go
  Description : Docker client library in Go
 Well maintained docker client library.


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

Bug#797999: sddm fails to start whereas kdm works correctly

[eric2.valette]

On 09/07/2015 11:00 PM, Dominik George wrote:

Control: tags -1 + moreinfo

Hi Eric,

On Fri, 4 Sep 2015 13:00:11  0200 Eric Valette 
wrote:

If I do dpkg-reconfigure sddm, select it and reboot, I just get a black
screen, with X running, no cursor, no mouse nothing in/var/log/sddm.log

Note its a docked laptop, with external monitor used, lid closed and laptop
monitor automatically desactivated.

Are you by any chance running plymouth? If so, could this be a duplicate of
#793637?

Unfortunately no. This is likely to be due to docking as I now have a 
half dozen boxes that work with sddm the only one that fails is a docked 
laptop.


-- eric


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#798239: logger: wrong timestamps for long-running connections

[Andreas Henriksson]

Hello Thorsten Glaser.

On Tue, Sep 08, 2015 at 09:13:00AM +0200, Thorsten Glaser wrote:
> On Mon, 7 Sep 2015, Andreas Henriksson wrote:
> 
> > Could you please try the bsdutils version from experimental
> > (as the version I just uploaded to unstable has probably not
> > yet reached the mirrors when you read this) to check if
> 
> No, the version from sid was what I just installed.
> 
> Preparing to unpack .../bsdutils_1%3a2.27-1_x32.deb ...
> Unpacking bsdutils (1:2.27-1) over (1:2.26.2-9) ...
> Processing triggers for man-db (2.7.2-1) ...
> Setting up bsdutils (1:2.27-1) ...
> 
> This version still exhibits the problem.

I'm not able to reproduce your problem (only tested on 2.27-1),
but I'm also not using syslog (only journal). This might mean
that the problem is somewhere in the syslog-specific code
in logger (which is where I think the most changes has been
done lately).

> 
> > Given you have reproducible testcase, in case you're interested in
> > seeing this issue resolved you could run git bisect to find out
> 
> Hm, I guess… need to learn how to do that first though…

It's quite simple here's a quick tutorial:

cd /tmp
debcheckout --git-track '*' util-linux
# Syntax: git bisect start [--no-checkout] [ [...]] [--] [...]
# To limit the scope, we'll guess that the problem is in logger.c
# (If it's in a library or whereever, just leave the paths part out.)
git bisect start v2.26.2 v2.25.2 -- misc-utils/logger.c
# 10: now build the checkout you where given
./autogen.sh && ./configure && make logger
# is the problem reproducible (or not)?
( echo foo ; sleep 5 ; echo bar ) | ./logger 
# Assuming it's still broken:
git bisect bad
# or if it was ok, use: git bisect good
# goto 10

In just a few build/reproduce/mark-good-or-bad git will
tell you the exact commit introducing the regression
(via a binary search on the git history).

Good luck!

Regards,
Andreas Henriksson

Bug#798326: ruby-2.1: Provide debug symbols (-dbg)

[azul]

Attached is a patch to enable a debugging symbols package.

I created it from the similar patch for ruby 2.2.
It builds for me. It's the first patch of this kind i ever created
though. So please have a close look.

diff --git a/debian/control b/debian/control
index a481e46..9c33f60 100644
--- a/debian/control
+++ b/debian/control
@@ -63,6 +63,22 @@ Description: Libraries necessary to run Ruby 2.1
  This package includes the 'libruby-2.1' library, necessary to run Ruby 2.1.
  (API version 2.1.0)
 
+Package: libruby2.1-dbg
+Section: debug
+Priority: extra
+Multi-Arch: same
+Architecture: any
+Depends:
+libruby2.1 (= ${binary:Version}),
+${misc:Depends}
+Description: Debugging symbols for libruby2.1
+ Ruby is the interpreted scripting language for quick and easy
+ object-oriented programming.  It has many features to process text
+ files and to do system management tasks (as in perl).  It is simple,
+ straight-forward, and extensible.
+ .
+ This package includes the debugging symbols for the 'libruby-2.1' library.
+
 Package: ruby2.1-dev
 Multi-Arch: same
 Architecture: any
diff --git a/debian/rules b/debian/rules
index 3fb31b0..6b844f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,3 +91,7 @@ override_dh_install-arch:
 	dh_install
 	# split Ruby/Tk files
 	$(baseruby) debian/split-tk-out.rb
+
+.PHONY: override_dh_strip
+override_dh_strip:
+	dh_strip --dbg-package=libruby2.1-dbg

Bug#798239: logger: wrong timestamps for long-running connections

[Thorsten Glaser]

On Tue, 8 Sep 2015, Andreas Henriksson wrote:

> I'm not able to reproduce your problem (only tested on 2.27-1),
> but I'm also not using syslog (only journal). This might mean

…okaaay…

> that the problem is somewhere in the syslog-specific code

Yes, probably.

Does this mean that the syslog-specific part of logger(1) is
basically unmaintained in Debian? If so, were I to suggest a
fix for the other problem with it, would you consider adding
it? (The one where when the syslog dæmon is restarted, input
is no longer sent to it.)

> It's quite simple here's a quick tutorial:

Thanks. Not “quite”, but doable.

> # goto 10

;-)

> In just a few build/reproduce/mark-good-or-bad git will
> tell you the exact commit introducing the regression
> (via a binary search on the git history).

Right, I knew “of” it, but I haven’t ever used it, because
all the setup around it is very complex, and the docs are
more for people who know the things already. Your quick
instructions should help.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#798332: witty: blank page

[Pau Garcia i Quiles]

Hello,

Have you tried to clean the browser cache, close & reopen the browser and
press Control + F5 to make sure a new copy is reloaded?

Have you tried with other browsers and/or from a different computer?

If that does not work, could you please provide sample code that leads to a
blank page so that I can try it?

Thank you



On Tue, Sep 8, 2015 at 10:07 AM, ioann sys  wrote:

> Package: witty
> Version: 3.3.4+dfsg-3
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
> Hello! After upgrading witty,my projects has been run, but i can see
> content
> (images, buttons and title!)
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.1.6 (SMP w/4 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages witty depends on:
> ii  libwt38 3.3.4+dfsg-3
> ii  libwtdbo38  3.3.4+dfsg-3
> ii  libwtdbofirebird38  3.3.4+dfsg-3
> ii  libwtdbopostgres38  3.3.4+dfsg-3
> ii  libwtdbosqlite383.3.4+dfsg-3
> ii  libwtext38  3.3.4+dfsg-3
> ii  libwthttp38 3.3.4+dfsg-3
> ii  witty-examples  3.3.4+dfsg-3
>
> witty recommends no packages.
>
> witty suggests no packages.
>
> -- no debconf information
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Bug#796657: I need libgit2 0.23.2 to be able to fix this bug

[Thomas Goirand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

With the latest upstream release, ie: 0.23.0, this bug is fixed.
However, I can't upload it unless libgit2 0.23.2 is also uploaded to
Sid. I have already filled bug #798338 for this, and I'll have to wait
until it's resolved to be able to upload pygit2 0.23 (which otherwise
wouldn't build).

Note that I have locally built libgit2 0.23.2 and the latest pygit2, and
I can confirm everything is fixed (I have it all working in Sid...).

Cheers,

Thomas Goirand (zigo)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJV7qMqAAoJENQWrRWsa0P+xyYQAJ4cOobFp/XpXA7ITiCylkTI
Xtz2S7eTC67uOpbOUF65tSx8wCLrkxvU6Fd9bvS4RuDM7FSIZ+jyfa30q3o9XsNi
ZhJblCAxCiuTEPiIzpaFYl0oGScLlyauhNputHfYuhIHxOo+EGB3cJ25aW53LGhi
cfYWzRyI1wP3kLJJ93WILK6yr/UnBsHRNH+wB/IM05XPQHu/bHMcv9nOiKbiE8zB
tdRqaoOxoLWWWfJa3lUILNDbejosfvep7qsvzPhYkSrV/RqeOUc+FlI4HQUx5Ki9
/6uAu2zn5XqxjatQO1BItEg9yN2EwnmXR2tF2NaSgFmWnnp4V3hx78AQgt1N05gC
gziaJyC4cwWJUFcguXXP/t16/j5gtn5tkFNoI2MZVeXVZ8ilYGpMZ6vXke7o9MA+
7378IFj4xF9YpAPmIlgw25dv7pyIzdPENagBgyuaDqeNNQ+GZ5kezTcw/aUB7Yjq
ii7DFzrC9lDb+34Gm5Lrbp5vAIMRmbIPZC4uAruVPthMBnK/pTlmuIBbMpJ48zQz
x87D5DysdMZBO5bNiIjEG/cbE+WsMuu0j2B1dbgscPYGsGsgYh+9Uv1NrH5gBNzq
Ep+eAba8e7mzUMLzshZesc6qvj3a7BYjyB1xTdjtCoeYnMePZTHmXR3R+wIOeQhe
psfYINL6PNNPnj/HW5R0
=i8yW
-END PGP SIGNATURE-

Bug#790809: Please enable ARM64 support

[Edmund Grimley Evans]

I think the package nvidia-settings should probably be built for all
architectures, even if there's no prospect of a working driver.

See this:

https://buildd.debian.org/status/package.php?p=mate-sensors-applet=sid

It's failing to build on most architectures because nvidia-settings is
not available. Obviously one could make mate-sensors-applet depend on
nvidia-settings only on certain architectures, but then you'd have (at
least) two packages that need to be updated whenever a new
architecture gets a driver. If nvidia-settings were to be built on all
architectures then it would only be necessary to update
nvidia-settings when there's a change and other packages could safely
depend on it unconditionally.

I'm assuming that nvidia-settings would be buildable and installable
without the driver and that there's a sensible way for it to report
"no driver" at run time.

On the other hand, I've never used either package so I might be
talking rubbish...

Bug#738119: complicated

[Hans-Christoph Steiner]

What makes it complicated to package all of these Android SDK tools is that
the source code is organized into semi-arbitrary "projects" that are split up
between many different git repos.  Those git repos are then all checked out at
the same time using Google's crazy `repo` tool.  Then the entire Android OS
and SDK are built using a single, unified build system that requires something
like 8 gigs of source code be downloaded.

This 'android-tools' package, like Arch's 'android-tools' package, was created
by manually copying various source files into this package's git repo.  When
trying to build the whole Android SDK, that would be a massive amount of work
to maintain.

For more info, follow the team's progress here:

https://wiki.debian.org/AndroidTools

Bug#798335: testdisk: Dependency problem renders package impossible to install

[Ara Keary]

Package: testdisk
Version: 6.14-3+b4
Severity: grave
Justification: renders package unusable

Dear maintainer,

current version 6.14-3+b4 of testdisk depends on libntfs-3g853, a virtual 
package formerly provided by
  ntfs-3g 1:2014.2.15AR.3-3
but not anymore by the new version
  ntfs-3g 1:2015.3.14AR.1-1
which in its stead provides libntfs-3g861 .

This renders the installation of testdisk impossible in unstable.

Consider also the opportunity to package the new 7.0 upstream version
  http://www.cgsecurity.org/wiki/TestDisk_7.0_Release


Best,

Ara


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

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

Versions of packages testdisk depends on:
ii  e2fslibs 1.42.13-1
ii  libc62.19-19
ii  libcomerr2   1.42.13-1
ii  libjpeg62-turbo  1:1.4.1-2
ii  libncursesw5 6.0+20150810-1
ii  libtinfo56.0+20150810-1
ii  libuuid1 2.27-1
ii  ntfs-3g [libntfs-3g853]  1:2014.2.15AR.3-3
ii  zlib1g   1:1.2.8.dfsg-2+b1

testdisk recommends no packages.

testdisk suggests no packages.

-- no debconf information

Bug#782837: [Pkg-xfce-devel] Bug#782837: xfce4-session: Fails to shutdown/reboot or logout.

[Dominik Szmek]

Dear Maintainer,

the problem was also solved by installing the package x11-xserver-utils on a
fresh jessie machine.

I suggest adding x11-xserver-utils as a dependency.

Regards,

Dominik



On Mon, Apr 27, 2015 at 04:45:33PM +0500, Филипп Васькин wrote:
> The problem was solved by installing the package x11-xserver-utils.

-- 

Bug#798326: ruby-2.1: Provide debug symbols (-dbg)

[Azul]

Package: src:ruby2.1
Severity: wishlist
File: ruby-2.1

Dear Maintainer,

Could you consider providing debug symbols for ruby 2.1? We have a stuck
process and it'd make debugging with gdb a lot easier.

There's a similar bug for ruby 2.2 with a patch to fix it. This might be
helpful: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785685

thanks,
 azul

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#798336: fails to start: TypeError: attributes() got an unexpected keyword argument 'apply_with_init'

[Stéphane Glondu]

Package: torbrowser-launcher
Version: 0.2.0-2
Severity: grave

Dear Maintainer,

Since this morning, torbrowser-launcher fails to start with the following error:

Traceback (most recent call last):
  File "/usr/bin/torbrowser-launcher", line 29, in 
import torbrowser_launcher
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py", line 
33, in 
from launcher import Launcher
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
31, in 
from twisted.web.client import Agent, RedirectAgent, ResponseDone, 
ResponseFailed
  File "/usr/lib/python2.7/dist-packages/twisted/web/client.py", line 767, in 

from twisted.internet.ssl import (CertificateOptions,
  File "/usr/lib/python2.7/dist-packages/twisted/internet/ssl.py", line 223, in 

from twisted.internet._sslverify import (
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py", line 
192, in 
verifyHostname, VerificationError = _selectVerifyImplementation(OpenSSL)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py", line 
167, in _selectVerifyImplementation
from service_identity import VerificationError
  File "/usr/lib/python2.7/dist-packages/service_identity/__init__.py", line 
12, in 
from . import pyopenssl
  File "/usr/lib/python2.7/dist-packages/service_identity/pyopenssl.py", line 
14, in 
from ._common import (
  File "/usr/lib/python2.7/dist-packages/service_identity/_common.py", line 
136, in 
@attributes(["pattern"], apply_with_init=False)
TypeError: attributes() got an unexpected keyword argument 'apply_with_init'

I suspect this is due to the following upgrade:

  python-service-identity:amd64 1.0.0-3 -> 14.0.0-1


Cheers,

-- 
Stéphane

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

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, 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 torbrowser-launcher depends on:
ii  gnupg1.4.19-5
ii  python   2.7.9-1
ii  python-gtk2  2.24.0-4
ii  python-lzma  0.5.3-3
ii  python-parsley   1.2-1
ii  python-psutil2.2.1-3
ii  python-twisted   15.2.1-1
ii  python-txsocksx  1.15.0.2-1
ii  tor  0.2.6.10-1
ii  wmctrl   1.07-7

torbrowser-launcher recommends no packages.

Versions of packages torbrowser-launcher suggests:
pn  apparmor   
pn  python-pygame  

-- no debconf information

Bug#798337: unfulfillable breaks/replaces compton-conf-qt5 (<< 0.2.0)

[Matthias Klose]

Package: compton-conf
Version: 0.1.0+20150626-1
Severity: serious
Tags: sid stretch

the package has breaks/replaces hardcoded in the control file.

Package: compton-conf
Architecture: any
Breaks: compton-conf-qt5 (<< 0.2.0)
Replaces: compton-conf-qt5 (<< 0.2.0)

I assume the version needs adjustment.

Bug#798341: [inkscape] impossible to install inkscape

[Marco Righi]

Package: inkscape
Version: 0.91-5
Severity: important

--- Please enter the report below this line. ---
Hi,
if I try to install inkscape I got some errors on dependences (follows
the complete list).

I check the first two libraries and I noticed that the name is slightly
changed:
- from libatkmm-1.6-1 to libatkmm-1.6-1v5
- from libcairomm-1.0-1 to libcairomm-1.0-1v5

I seguenti pacchetti hanno dipendenze non soddisfatte:
 inkscape : Dipende: libatkmm-1.6-1 (>= 2.22.1) ma non sta per essere
installato
Dipende: libcairomm-1.0-1 (>= 1.6.4) ma non sta per essere
installato
Dipende: libglibmm-2.4-1c2a (>= 2.44.0) ma non sta per
essere installato
Dipende: libgtkmm-2.4-1c2a (>= 1:2.24.0) ma non sta per
essere installato
Dipende: libmagick++-6.q16-5 (>= 8:6.8.9.6) ma non sta per
essere installato
Dipende: libpangomm-1.4-1 (>= 2.36.0) ma non sta per essere
installato
Dipende: libsigc++-2.0-0c2a (>= 2.2.0) ma non sta per essere
installato
E: Impossibile correggere i problemi, ci sono pacchetti danneggiati
bloccati.

Please contact me if you need more informations.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.1.0-1-amd64

Debian Release: stretch/sid
  500 testing-updates ftp.fr.debian.org
  500 testing www.deb-multimedia.org
  500 testing security.debian.org
  500 testing ftp.fr.debian.org
  500 testing apt.jenslody.de
  500 stable-updates  ftp.it.debian.org
  500 stable  security.debian.org
  500 stable  repo.wuala.com
  500 stable  ftp.it.debian.org
  500 stable  dl.google.com
  500 stable  apt.spideroak.com
  500 jessie  linux.dropbox.com
  500 debian  packages.linuxmint.com
  100 jessie-backports ftp.it.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-=
python:any (>= 2.6.6-7~) |
gconf-service| 3.2.6-3
libaspell15 (>= 0.60.7~20110707) | 0.60.7~20110707-3
libatk1.0-0  (>= 1.12.4) | 2.16.0-2
libatkmm-1.6-1   (>= 2.22.1) | 2.22.7-2.1
libc6  (>= 2.14) |
libcairo2(>= 1.10.0) |
libcairomm-1.0-1  (>= 1.6.4) |
libfontconfig1 (>= 2.11) |
libfreetype6  (>= 2.2.1) |
libgc1c2 (>= 1:7.2d) |
libgcc1 (>= 1:4.1.1) |
libgconf-2-4  (>= 3.2.5) |
libgdk-pixbuf2.0-0   (>= 2.22.0) |
libglib2.0-0 (>= 2.35.9) |
libglibmm-2.4-1c2a   (>= 2.40.0) |
libgnomevfs2-0(>= 1:2.17.90) |
libgomp1(>= 4.9) |
libgsl0ldbl (>= 1.9) |
libgtk2.0-0  (>= 2.24.0) |
libgtkmm-2.4-1c2a  (>= 1:2.24.0) |
libgtkspell0 (>= 2.0.10) |
liblcms2-2  (>= 2.2+git20110628) |
libmagick++5(>= 8:6.7.7.10+dfsg) |
libmagickcore5  (>= 8:6.7.7.10+dfsg) |
libpango-1.0-0   (>= 1.14.0) |
libpangocairo-1.0-0  (>= 1.14.0) |
libpangoft2-1.0-0(>= 1.14.0) |
libpangomm-1.4-1 (>= 2.27.1) |
libpng12-0 (>= 1.2.13-4) |
libpoppler-glib8 (>= 0.18.0) |
libpoppler46 (>= 0.26.3) |
libpopt0   (>= 1.14) |
librevenge-0.0-0 |
libsigc++-2.0-0c2a(>= 2.2.0) |
libstdc++6  (>= 4.9) |
libwpg-0.3-3 |
libx11-6 |
libxml2   (>= 2.7.4) |
libxslt1.1   (>= 1.1.25) |
zlib1g  (>= 1:1.1.4) |


Recommends  (Version) | Installed
=-+-===
aspell| 0.60.7~20110707-3
imagemagick   | 8:6.8.9.9-5
libgnomevfs2-extra| 1:2.24.4-6.1
libwmf-bin| 0.2.8.4-10.4
perlmagick| 8:6.8.9.9-5
pstoedit  | 3.62-2+b1
python-lxml   | 3.4.4-1
python-numpy  | 1:1.8.2-2
transfig  | 1:3.2.5.e-4


Suggests (Version) | Installed
==-+-===
dia| 0.97.3-1
 OR dia-gnome  | 0.97.3-1
libsvg-perl|
libxml-xql-perl|
python-uniconvertor|
ruby   | 1:2.1.5.1

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-09-06 22:08, Otto Kekäläinen wrote:
> This is still the status. Over 40 days has already passed of waiting
> for mysql-5.6.

d/copyright needs to be updated, fixed in git.
That is hopefully the only blocker left for a migration.

Btw, why aren't you in Uploaders?

Anything else that should be included in the next upload?
There is a patch for mips64el in #798126
Please get into contact wth the hurd porters to fix #793358

someone should look into handlersocket, there is a new upstream release
that could add mysql 5.6 support.

> Andreas: are you still into making mysql-common a separate source
> package as you suggested in the summer? I think it would be a good
> time now.

Ack, I'm in :-)

IIRC I wrote a lengthy mail with several questions regarding this, but
didn't see a reply so far ...


Andreas

Bug#798344: Expects /etc/check_mk/conf.d directory

[Joachim Breitner]

Package: check-mk-multisite
Version: 1.2.6p7-1~bpo8+1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

the package prevents successfull upgrades on my server:

$ LANG=C apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up check-mk-multisite (1.2.6p7-1~bpo8+1) ...
chown: cannot access '/etc/check_mk/conf.d': No such file or directory
dpkg: error processing package check-mk-multisite (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 check-mk-multisite
E: Sub-process /usr/bin/dpkg returned an error code (1)

I do not know why I do not have a /etc/check_mk/conf.d directory, but I cannot
remember removing it myself.

Greetings,
Joachim

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlXut2QACgkQ9ijrk0dDIGxFwgCgy8VIfUZtBE2Pvy6kXozB8T0Q
nSoAoIie6x+7eKOuBXVcBh2yXhkLo0ma
=JD+g
-END PGP SIGNATURE-

Bug#797463: M-A:same package is broken by binnmu; please do a sourceful upload

[Ralf Jung]

This is currently blocking the gcc5 transition from being installed on
i386-amd64 systems having ffmpeg installed - by far not an uncommon
setup. As a consequence, I can't install any system update currently.
For example, I remain vulnerable to critical security issues uncovered
in iceweasel due to this bug in ffmpeg. Please consider to fix this
situation ASAP, either by doing a binNMU on i386 (bringing the version
numbers back in sync) or by doing a sourceful upload.

On a more general note, is there any solution in sight to the issue of
binNMUs breaking MS:same packages? Really, all binNMUs issued for such
packages *must* involve all architectures, until a better solution is found.

Bug#797999: sddm fails to start whereas kdm works correctly

[eric2.valette]

On 09/08/2015 12:43 PM, Dominik George wrote:

Hi Eric,


Unfortunately no. This is likely to be due to docking as I now have a
half dozen boxes that work with sddm the only one that fails is a docked
laptop.

And this laptop, does it by any chance use an Intel graphics chip?
No. It uses nvidia chipset with nvidia proprietary drivers like four 
others among the six  that are non docked were sddm correcly works.


-- eric


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#781530: Acknowledgement (ITP: libdfp -- Decimal Floating Point C Library)

[Frederic Bonnard]

It seems that there is what we need there :
https://launchpad.net/ubuntu/+source/libdfp

Can anyone import this in Debian ?

F.

Bug#794847: Patch

[Matt Kraai]

tag 794847 + patch
thanks

Hi,

The attached patch fixes this issue by making torbrowser-launcher use
IPolicyForHTTPS.

-- 
Matt   https://ftbfs.org/~kraai/
Description: Use IPolicyForHTTPS
Bug: https://github.com/micahflee/torbrowser-launcher/issues/192
Forwarded: https://github.com/micahflee/torbrowser-launcher/pull/196
Author: Matt Kraai 
Last-Update: 2015-09-07

diff --git a/torbrowser_launcher/launcher.py b/torbrowser_launcher/launcher.py
index 698949d..2f75366 100644
--- a/torbrowser_launcher/launcher.py
+++ b/torbrowser_launcher/launcher.py
@@ -30,9 +30,12 @@ import os, subprocess, time, json, tarfile, hashlib, lzma, threading, re
 from twisted.internet import reactor
 from twisted.web.client import Agent, RedirectAgent, ResponseDone, ResponseFailed
 from twisted.web.http_headers import Headers
+from twisted.web.iweb import IPolicyForHTTPS
 from twisted.internet.protocol import Protocol
-from twisted.internet.ssl import ClientContextFactory
+from twisted.internet.ssl import CertificateOptions
+from twisted.internet._sslverify import ClientTLSOptions
 from twisted.internet.error import DNSLookupError
+from zope.interface import implementer
 
 import OpenSSL
 
@@ -49,12 +52,13 @@ class TryDefaultMirrorException(Exception):
 class DownloadErrorException(Exception):
 pass
 
-class VerifyTorProjectCert(ClientContextFactory):
+class TorProjectCertificateOptions(CertificateOptions):
 def __init__(self, torproject_pem):
+CertificateOptions.__init__(self)
 self.torproject_ca = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, open(torproject_pem, 'r').read())
 
 def getContext(self, host, port):
-ctx = ClientContextFactory.getContext(self)
+ctx = CertificateOptions.getContext(self)
 ctx.set_verify_depth(0)
 ctx.set_verify(OpenSSL.SSL.VERIFY_PEER | OpenSSL.SSL.VERIFY_FAIL_IF_NO_PEER_CERT, self.verifyHostname)
 return ctx
@@ -62,6 +66,16 @@ class VerifyTorProjectCert(ClientContextFactory):
 def verifyHostname(self, connection, cert, errno, depth, preverifyOK):
 return cert.digest('sha256') == self.torproject_ca.digest('sha256')
 
+@implementer(IPolicyForHTTPS)
+class TorProjectPolicyForHTTPS:
+def __init__(self, torproject_pem):
+self.torproject_pem = torproject_pem
+
+def creatorForNetloc(self, hostname, port):
+certificateOptions = TorProjectCertificateOptions(self.torproject_pem)
+return ClientTLSOptions(hostname.decode('utf-8'),
+certificateOptions.getContext(hostname, port))
+
 class Launcher:
 def __init__(self, common, url_list):
 self.common = common
@@ -451,12 +465,12 @@ class Launcher:
 
 # default mirror gets certificate pinning, only for requests that use the mirror
 if self.common.settings['mirror'] == self.common.default_mirror and '{0}' in url:
-agent = SOCKS5Agent(reactor, VerifyTorProjectCert(self.common.paths['torproject_pem']), proxyEndpoint=torEndpoint)
+agent = SOCKS5Agent(reactor, TorProjectPolicyForHTTPS(self.common.paths['torproject_pem']), proxyEndpoint=torEndpoint)
 else:
 agent = SOCKS5Agent(reactor, proxyEndpoint=torEndpoint)
 else:
 if self.common.settings['mirror'] == self.common.default_mirror and '{0}' in url:
-agent = Agent(reactor, VerifyTorProjectCert(self.common.paths['torproject_pem']))
+agent = Agent(reactor, TorProjectPolicyForHTTPS(self.common.paths['torproject_pem']))
 else:
 agent = Agent(reactor)
 

Bug#798354: warning: not replacing /usr/bin/py-afl-fuzz with a link

[Daniel Stender]

On 08.09.2015 13:51, Jakub Wilk wrote:
> Package: python-afl
> Version: 0.5-2
> 
> If you have python3-afl_0.2.1-1, and then install python-afl_0.5-2, you get:
> 
> update-alternatives: using /usr/share/python-afl/py-afl-fuzz to provide 
> /usr/bin/py-afl-fuzz (py-afl-fuzz) in auto mode
> update-alternatives: warning: not replacing /usr/bin/py-afl-fuzz with a link
> update-alternatives: warning: not replacing 
> /usr/share/man/man1/py-afl-fuzz.1.gz with a link
> 
> ...and you end up with the old py-afl-fuzz, which is not compatible with the 
> new afl module.
> 
> Suggested solution: use Breaks to make sure than python-afl and python3-afl 
> versions are always in sync.

Yep, breaks missing against the pre-alternatives package (0.2.1-1). Thanks for 
reporting this.

Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#798355: colord-sensor-argyll: fails to upgrade from 'jessie' - trying to overwrite /usr/lib/x86_64-linux-gnu/colord-sensors/libcolord_sensor_argyll.so

[Andreas Beckmann]

Package: colord-sensor-argyll
Version: 1.2.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package colord-sensor-argyll.
  Preparing to unpack .../colord-sensor-argyll_1.2.11-1_amd64.deb ...
  Unpacking colord-sensor-argyll (1.2.11-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/colord-sensor-argyll_1.2.11-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/colord-sensors/libcolord_sensor_argyll.so', which is 
also in package colord 1.2.1-1+b2


cheers,

Andreas


colord=1.2.1-1+b2_colord-sensor-argyll=1.2.11-1.log.gz
Description: application/gzip

Bug#798311: Processed: Re: Bug#798311: nvidia-kernel-dkms: fails to build against 4.2.0-trunk in experimental

[Luca Boccassi]

On Tue, 2015-09-08 at 12:46 +0100, Ben Hutchings wrote:
> Control: tag 798311 - wontfix
> Control: tag 798311 fixed-upstream patch
> 
> As this has been fixed upstream (commit
> 1dadafa86a779884f14a6e7a3ddde1a57b0a0a65) I'm prepared to cherry-pick
> that fix.  But this doesn't set a precedent that I'm going to help with
> GPL-incompatible modules.

Hi Ben,

Thank you very much, really appreciate it.

Kind regards,
Luca Boccassi


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

Bug#798306: [Piuparts-devel] Bug#798306: 'unknown location' errors with [trusted=yes] file deb src

[Scott Wakeling]

> > piuparts gives 'unknown location' errors when sources.list has the
> > following first line:
> > deb [trusted=yes] file:/home/scott/debian/apt ./
> > 
> this is because piuparts uses a customs sources.list parser, which was written
> before "[trusted=yes/no]" was introduced…
> 
> That said, I'm not sure I *want* to support it, because trust doesnt work this
> way.
> 
> 
> > If I comment out the aforementioned [trusted=yes] file: deb src from my
> > sources.list, piuparts works and all tests pass.
> > 
> then why do you want these "trusted=yes" lines in the first place?
> 
> 
I mention commenting out the trusted line as proof of it being the source of 
the problem.

If a fix isn't appropriate, I can leave that trusted file src in place and use 
'piuparts -m' instead.

Bug#798306: [Piuparts-devel] Bug#798306: 'unknown location' errors with [trusted=yes] file deb src

[Holger Levsen]

Hi Scott,

thanks for your bug report!

On Montag, 7. September 2015, Scott Wakeling wrote:
> piuparts gives 'unknown location' errors when sources.list has the
> following first line:
>  deb [trusted=yes] file:/home/scott/debian/apt ./

this is because piuparts uses a customs sources.list parser, which was written 
before "[trusted=yes/no]" was introduced…

That said, I'm not sure I *want* to support it, because trust doesnt work this 
way.

> If I comment out the aforementioned [trusted=yes] file: deb src from my
> sources.list, piuparts works and all tests pass.

then why do you want these "trusted=yes" lines in the first place?


cheers,
Holger


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

Bug#798347: fdisk-udeb: not installable, depends on libtinfo5

[Cyril Brulebois]

Package: fdisk-udeb
Version: 2.27-1
Severity: grave
Justification: renders package unusable

Hi,

Your package gained a dependency on libtinfo5, which makes it no longer
installable, along with lilo-installer and rescue-mode, which both
depend on it.

Example on mips:
  Depends: libblkid1-udeb (>= 2.25), libc6-udeb (>= 2.19), libfdisk1-udeb (>= 
2.26), libsmartcols1-udeb (>= 2.25), libtinfo5 (>= 6), libuuid1-udeb (>= 2.20.1)

Mraw,
KiBi.

Bug#793508: kmail: contacts gravatar.com to fetch face images of senders of opened mails by default

[Dominik George]

Package: kmail
Version: 4:4.14.10-2
Followup-For: Bug #793508

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I also see this happen. Suddenly, one of my coworkers had a donkey in
every mail he sent.

This effectively leaks information about who I receive mail from to any
network operator on the route to the internet.

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

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

Versions of packages kmail depends on:
ii  kde-runtime   4:15.08.0-2
ii  kdepim-runtime4:4.14.10-2
ii  kdepimlibs-kio-plugins4:4.14.10-1
ii  libakonadi-calendar4  4:4.14.10-1
ii  libakonadi-contact4   4:4.14.10-1
ii  libakonadi-kde4   4:4.14.10-1
ii  libakonadi-kmime4 4:4.14.10-1
ii  libakonadiprotocolinternals1  1.13.0-8
ii  libc6 2.19-19
ii  libcalendarsupport4   4:4.14.10-2
ii  libfollowupreminder4  4:4.14.10-2
ii  libgcc1   1:5.2.1-16
ii  libgpgme++2v5 4:4.14.10-1
ii  libgrantlee-core0 0.4.0-3
ii  libincidenceeditorsng44:4.14.10-2
ii  libkabc4  4:4.14.10-1
ii  libkalarmcal2 4:4.14.10-1
ii  libkcalcore4  4:4.14.10-1
ii  libkcalutils4 4:4.14.10-1
ii  libkcmutils4  4:4.14.10-3
ii  libkdecore5   4:4.14.10-3
ii  libkdepim44:4.14.10-2
ii  libkdeui5 4:4.14.10-3
ii  libkio5   4:4.14.10-3
ii  libkleo4  4:4.14.10-2
ii  libkmanagesieve4  4:4.14.10-2
ii  libkmime4 4:4.14.10-1
ii  libknotifyconfig4 4:4.14.10-3
ii  libkontactinterface4a 4:4.14.10-1
ii  libkparts44:4.14.10-3
ii  libkpimidentities44:4.14.10-1
ii  libkpimtextedit4  4:4.14.10-1
ii  libkpimutils4 4:4.14.10-1
ii  libkprintutils4   4:4.14.10-3
ii  libksieveui4  4:4.14.10-2
ii  libmailcommon44:4.14.10-2
ii  libmailimporter4  4:4.14.10-2
ii  libmailtransport4 4:4.14.10-1
ii  libmessagecomposer4   4:4.14.10-2
ii  libmessagecore4   4:4.14.10-2
ii  libmessagelist4   4:4.14.10-2
ii  libmessageviewer4 4:4.14.10-2
ii  libpimcommon4 4:4.14.10-2
ii  libqt4-dbus   4:4.8.7+dfsg-3
ii  libqt4-network4:4.8.7+dfsg-3
ii  libqt4-xml4:4.8.7+dfsg-3
ii  libqtcore44:4.8.7+dfsg-3
ii  libqtgui4 4:4.8.7+dfsg-3
ii  libqtwebkit4  2.3.4.dfsg-4
ii  libsendlater4 4:4.14.10-2
ii  libsolid4 4:4.14.10-3
ii  libstdc++65.2.1-16
ii  libtemplateparser44:4.14.10-2
ii  perl  5.20.2-6

Versions of packages kmail recommends:
ii  gnupg-agent 2.1.7-2
ii  gnupg2  2.1.7-2
ii  kdepim-doc  4:4.14.10-2
pn  kdepim-themeditors  
ii  ktnef   4:4.14.10-2
ii  pinentry-gnome3 [pinentry-x11]  0.9.5-4
ii  pinentry-gtk2 [pinentry-x11]0.9.5-4
ii  pinentry-qt4 [pinentry-x11] 0.9.5-4

Versions of packages kmail suggests:
pn  clamav  
ii  kaddressbook4:4.14.10-2
ii  kleopatra   4:4.14.10-2
ii  procmail3.22-25
pn  spamassassin | bogofilter | annoyance-filter | spambayes | bsf  

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJV7sKHMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbPHA//f9+OoQ8YwolnAkfuvlS9
RKsolaMje1k/dAsru/Rxl/4FenUecVtRqBbR+VLxWojksrj7i+lKow3bZmTo/vGc
gwzgpgEOjnB/PEFvq1WsvcdUUJ0BxtQ7FOgZ6c0eE5nBx8+s30exn/fJR6zuXP3V
hlRsn7BjH2gzZkq3GT6uJIWIniQ55fr3ClqHjvyTdtp8gVLNoqKIhX/8/EEtxFrC
Jxwd4HaennvrOyNHW6lR7DIU4V5Qr02NRyIcqhH/YkgYAFq0vge65XfTvKOZ3kbk
kNrMRWojZH7UefvrB3913YlxwI640zbdJrrlSpkiRbwQBV5es8gjO/KhHH2QN7wf
+CV/DDhtPGvw8K0HzBYzZbX6pbQ3KvV91cTXRkMsD3BcfGn0/mKSQn/W6r6FckLJ
QxEoWoiqRm1b+8PIqOgQm7zBt+BODEBGZ1+uDZFvA4kd4BrmZLw2pM9+p5pM78wZ
Z0vobWRM+vKTKot55gbFr/fuVUd6uK3d2k4XbQZPXejrvaxIjLY0H4dvRslED17e
YDE7m13N3+1PIUU9Xtt+1H4tvZBmG780lfjchKQA59scyOuB6ZDeimaeNbdmJ461
AEjyn3hhPzdbs7gx4WbwbSPR8zE1vhwsISvREPafsSGba/lbGMEsmaTce+j3G6Xt
kUGtIWRVf5SLOF7JyAmKvbk=
=x/fp
-END PGP SIGNATURE-

Bug#798350: wordpress: Arguments switched in wp_batch_split_terms Cron Job

[Marc Wilson]

Package: wordpress
Version: 4.3+dfsg-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

Wordpress performance degrades over time dues to increasing high CPU usage and 
become unusable under moderaate to high loads (20 plus connections)
Finally located thousands of wp_cron entries with numbers as hooks and 
wp_batch_split_terms under "Next run" with old date Thu 1970/01/01 00:00:00
Every hit on the site results in more of these cron entries causing 
increasingly large database loads of the cron entry from wp_options on every 
connection

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

Applied changes to wordpress/wp-includes/taxonomy.php as per
https://core.trac.wordpress.org/ticket/33423

Line: 4448

wp_schedule_single_event( 'wp_batch_split_terms', time() + MINUTE_IN_SECONDS );

Meant to call

wp_schedule_single_event( time() + MINUTE_IN_SECONDS, 'wp_batch_split_terms' );

Ran from theme's functions.php:

add_action("init", "remove_taxonomy_cron_job");

function remove_taxonomy_cron_job()
{
$cron = get_option("cron");
unset($cron["wp_batch_split_terms"]);
update_option("cron", $cron);
}

   * What was the outcome of this action?

Restored normal performance

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


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

Kernel: Linux 4.1.0-1-amd64 (SMP w/5 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages wordpress depends on:
ii  apache2 [httpd]  2.4.16-3
ii  ca-certificates  20150426
ii  libapache2-mod-php5  5.6.12+dfsg-1
ii  libjs-cropper1.2.2-1
ii  libjs-mediaelement   2.15.1+dfsg-1
ii  libphp-phpmailer 5.2.10+dfsg-1
ii  mysql-client 5.5.44-0+deb8u1
ii  mysql-client-5.5 [mysql-client]  5.5.44-0+deb8u1
ii  php-getid3   1.9.9+dfsg-2
ii  php5 5.6.12+dfsg-1
ii  php5-gd  5.6.12+dfsg-1
ii  php5-mysql   5.6.12+dfsg-1

Versions of packages wordpress recommends:
ii  wordpress-l10n 4.3+dfsg-1
ii  wordpress-theme-twentyfifteen  4.3+dfsg-1

Versions of packages wordpress suggests:
pn  mysql-server  
pn  php5-ssh2 

-- Configuration Files:
/etc/wordpress/htaccess changed [not included]

-- no debconf information

Bug#798349: ITP: golang-github-inconshreveable-mousetrap -- Go library to detect starting from Windows Explorer

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-inconshreveable-mousetrap
  Version : 0.0~git20141017.0.76626ae-1
  Upstream Author : Alan Shreve
* URL : https://github.com/inconshreveable/mousetrap
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library to detect starting from Windows Explorer

 mousetrap is a tiny Go library that answers a single question:
 On a Windows machine, was the process invoked by someone double clicking
 on the executable file while browsing in Explorer?
 .
 Motivation: Windows users unfamiliar with command line tools will
 often "double-click" the executable for a tool. Because most CLI tools
 print the help and then exit when invoked without arguments, this is
 often very frustrating for those users.
 .
 mousetrap provides a way to detect these invocations so
 that you can provide more helpful behavior and instructions
 on how to run the CLI tool.

Reason for packaging:

 * github.com/inconshreveable/mousetrap is a dependency of
   github.com/spf13/cobra, which in turn is used by
   Hugo ( http://gohugo.io/ ) and Kubernetes ( http://kubernetes.io/ ).

Bug#798348: ruby-tzinfo: Loading tzdata may break because of encoding

[Herwin Weststrate]

Package: ruby-tzinfo
Version: 1.1.0-2
Severity: normal

Dear Maintainer,

Last weekend the tzdata package has had an update. This update added an
accent to the file /usr/share/zoneinfo/iso3166.tab, making it UTF8
instead of ASCII. Depending on your locale settings, this may break
ruby-tzinfo, with an error like this:

  /usr/lib/ruby/vendor_ruby/tzinfo/zoneinfo_data_source.rb:325:in
  `block (2 levels) in load_country_index': invalid byte sequence in
  US-ASCII (ArgumentError)

This has been fixed upstream in release 1.2.0 (see fifth bullet of
)

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

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

Versions of packages ruby-tzinfo depends on:
ii  ruby1:2.1.5+deb8u1
ii  ruby-thread-safe0.3.3-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-2+deb8u2

ruby-tzinfo recommends no packages.

ruby-tzinfo suggests no packages.

-- no debconf information

Bug#798329: ifconfig: changed output format breaks scripts

[Guillem Jover]

Hi!

On Tue, 2015-09-08 at 12:56:09 +0300, Martín Ferrari wrote:
> On 08/09/15 12:34, Thorsten Glaser wrote:
> > I need reliable, consistent, parsable output across all Debian versions
> > (and some derivates).
> 
> There is no software that currently offers that promise. I understand it
> is annoying, and myself have reported a bug to iproute2 (#726417) for a
> similar situation, but the maintainer also did not want to diverge from
> upstream, so I had to live with that.

Well, the ifconfig implementation in inetutils provides selectable
output formats, which might be close to that promise, but I think
I agree in general that relying on this kind of output is not wise.

> >> direcly parsing files in /proc/net
> > 
> > Excuse me, but WTF?
> > 
> > The standard Unix interface for things is stdout of other commands,
> > as in, filters and pipes. ifconfig is *the* standard utility to get
> > information about interfaces.
> 
> Sorry, but ifconfig output is not standarised by policy or any other
> doc. In fact, it varies wildly in its many implementations. It has been
> deprecated as a means of talking with the network stack in Linux since
> iproute exists, which is a Long Time Ago.

Yes, see the above comment on inetutils' ifconfig selectable output.

> Also, it is not breaking other Debian packages, nor it is
> malfunctioning, so severity can't be more than wishlist.

We might not know yet, I do actually expect this might break some
stuff also parsing output from ifconfig. Perhaps a quick check could
be performed on codesearch.d.n?

> Finally, I have no intentions on maintaining a fork of net-tools to
> support the 14 years old output format of ifconfig, so I am closing this
> as wontfix.

This is quite reasonable IMO.

Thanks,
Guillem

Bug#798353: libsndio-dev and libroar-dev: error when trying to install together

[Andreas Beckmann]

Followup-For: Bug #798353

libsndio-dev still needs to add Breaks+Replaces against the buggy
libroar-dev versions.


Andreas

Bug#798311: Processed: Re: Bug#798311: nvidia-kernel-dkms: fails to build against 4.2.0-trunk in experimental

[Ben Hutchings]

Control: tag 798311 - wontfix
Control: tag 798311 fixed-upstream patch

As this has been fixed upstream (commit
1dadafa86a779884f14a6e7a3ddde1a57b0a0a65) I'm prepared to cherry-pick
that fix.  But this doesn't set a precedent that I'm going to help with
GPL-incompatible modules.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#777934: libalog: ftbfs with GCC-5

[Nicolas Boulenguez]

Package: src:libalog
Followup-For: Bug #777934

Hello.
You may be interested in the last commit of branch
org.debian.libgnatcoll in the Ada France monotone repository,
closing the exact same issue.

Bug#798342: ITP: golang-github-fsouza-go-dockerclient -- Docker client library in Go

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Owner: Dmitry Smirnov 

* Package name: golang-github-fsouza-go-dockerclient
  Version : 0.0+git20150905-1
  Upstream Author : go-dockerclient authors
* URL : github.com/fsouza/go-dockerclient
* License : BSD-2-clause
  Programming Lang: Go
  Description : Docker client library in Go
 Client for the Docker remote API with support for the extensions in the
 Swarm API.
 .
 This package also provides support for docker's network API, which is a
 simple passthrough to the libnetwork remote API.  Note that docker's
 network API is only available in docker 1.8 and above, and only enabled in
 docker if DOCKER_EXPERIMENTAL is defined during the docker build process.


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

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

[Jürgen Bausa]

Dear Maintainer,

 

i am running jessie and I have exactly the same bug as described in post #25. My system is connected to the net by wlan (NM).

 

Regards,

 

Jürgen

Bug#798332: witty: blank page

[Pau Garcia i Quiles]

Hello,

This looks like a bug in Wt itself, not in the packaging.

When you run the Wt app in localhost and access it from the same machine,
everything works fine. Or at least it works fine for me on Debian Sid and
Ubuntu 15.04: web page is generated, content is fine and is displayed just
fine.

But when I run the Wt app in another host (e. g. Wt app in a guest VM,
access from main host), then the code is generated (check "View Source" in
your browser) but the automatic redirection does not work. That is why you
end up with a blank page. If you disable JavaScript, it works fine again
(albeit more limited: that's the Basic HTML version of the page).

I will forward this upstream but please report it yourself too.



On Tue, Sep 8, 2015 at 12:28 PM, ioann sys  wrote:

> Thank for your reply!
>
> It primitive code don't work:
>
> --
> main.cpp
> --
> #include 
> #include 
> #include 
> #include 
> #include 
> using namespace std;
> using namespace Wt;
>
>
> class c_web_app : public WApplication
> {
> public:
> c_web_app(const WEnvironment& env) : WApplication(env)
> {
> this->setTitle("Web App! Now title not work.");
> WContainerWidget *webpage = new WContainerWidget(this->root());
>
> webpage->addWidget(new WText("Hello!"));
> }
>
> private:
>
> };
>
> WApplication* create_app(const WEnvironment& env)
> {
> return new c_web_app(env);
> }
>
> int main(int argc, char *argv[])
> {
> const int a = 9;
> char *v[a];
>
> v[0] = argv[0];
>
> v[1] = (char*) "--http-address";
> v[2] = (char*) "0.0.0.0";
>
> v[3] = (char*) "--http-port";
> v[4] = (char*) "8080";
>
> v[5] = (char*) "--deploy-path";
> v[6] = (char*)  "/";
>
>
> v[7] = (char*) "--docroot";
> v[8] = (char*) ".;/resources";
>
>
>
> return WRun(a, v, _app);
> }
> -
> //
> //
> //
> //
> //
> //
> -
> CMakeLists.txt
> -
> project(test1)
> cmake_minimum_required(VERSION 2.8)
> aux_source_directory(. SRC_LIST)
> add_executable(${PROJECT_NAME} ${SRC_LIST})
>
> set(CMAKE_CXX_FLAGS "-lwt -lwthttp")
> -
>
>
>
>
>
> But, i see requests in stdout:
>
> Запускается /home/ioann/workspace/test1/build/test1...
>
> [2015-Sep-08 13:22:53.445993] 2948 - [info] "config: reading Wt config
> file: /etc/wt/wt_config.xml (location =
> '/home/ioann/workspace/test1/build/test1')"
>
> [2015-Sep-08 13:22:53.446968] 2948 - [info] "WServer/wthttp: initializing
> built-in wthttpd"
>
> [2015-Sep-08 13:22:53.447312] 2948 - [info] "wthttp: started server:
> http://0.0.0.0:8080;
>
> [2015-Sep-08 13:22:55.253040] 2948 - [info] "Wt: session created
> (#sessions = 1)"
>
> [2015-Sep-08 13:22:55.253141] 2948 [/ Iw6fNZRGMugn8FUO] [info]
> "WEnvironment: UserAgent: Mozilla/5.0 (X11; Linux x86_64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36"
>
> [2015-Sep-08 13:22:55.253847] 2948 - [info] "WebRequest: took 0.875ms"
>
> 127.0.0.1 - - [2015-Sep-08 13:22:55.253797] "GET / HTTP/1.1" 200 2649
>
> 127.0.0.1 - - [2015-Sep-08 13:22:55.307885] "GET
> /?wtd=Iw6fNZRGMugn8FUO=style HTTP/1.1" 200 91
>
> [2015-Sep-08 13:22:55.307919] 2948 - [info] "WebRequest: took 40.434ms"
>
> 127.0.0.1 - - [2015-Sep-08 13:22:55.319758] "GET
> /resources/themes/default/wt.css HTTP/1.1" 404 85127.0.0.1 - - [2015-Sep-08
> 13:22:55.319810] "GET /resources/webkit-transitions.css HTTP/1.1" 404 85
>
>
> 127.0.0.1 - - [2015-Sep-08 13:22:55.322411] "GET
> /?wtd=Iw6fNZRGMugn8FUO=1424260071=true=1920=1080=180=true=%2F=script=1081462392
> HTTP/1.1" 200 57830
>
> [2015-Sep-08 13:22:55.322455] 2948 - [info] "WebRequest: took 15.143ms"
>
> [2015-Sep-08 13:22:55.335467] 2948 - [info] "Wt: session created
> (#sessions = 2)"
>
> 127.0.0.1 - - [2015-Sep-08 13:22:55.337313] "GET /favicon.ico HTTP/1.1"
> 200 2659
>
> [2015-Sep-08 13:22:55.335793] 2948 [/ MoPc9f0Pg6bxsbGy] [info]
> "WEnvironment: UserAgent: Mozilla/5.0 (X11; Linux x86_64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36"
>
> [2015-Sep-08 13:22:55.337402] 2948 - [info] "WebRequest: took 2.095ms"
>
>
>
>
>
>
>
> 08.09.2015 11:47, Pau Garcia i Quiles пишет:
>
> Hello,
>
> Have you tried to clean the browser cache, close & reopen the browser and
> press Control + F5 to make sure a new copy is reloaded?
>
> Have you tried with other browsers and/or from a different computer?
>
> If that does not work, could you please provide sample code that leads to
> a blank page so that I can try it?
>
> Thank you
>
>
>
> On Tue, Sep 8, 2015 at 10:07 AM, ioann sys  wrote:
>
>> Package: witty
>> Version: 

Bug#797463: M-A:same package is broken by binnmu; please do a sourceful upload

[Felipe Sateler]

Control: reassign -1 release.debian.org

On 8 September 2015 at 07:26, Ralf Jung  wrote:
> This is currently blocking the gcc5 transition from being installed on
> i386-amd64 systems having ffmpeg installed - by far not an uncommon
> setup. As a consequence, I can't install any system update currently.
> For example, I remain vulnerable to critical security issues uncovered
> in iceweasel due to this bug in ffmpeg. Please consider to fix this
> situation ASAP, either by doing a binNMU on i386 (bringing the version
> numbers back in sync) or by doing a sourceful upload.
>
> On a more general note, is there any solution in sight to the issue of
> binNMUs breaking MS:same packages? Really, all binNMUs issued for such
> packages *must* involve all architectures, until a better solution is found.

Dear release team, please schedule binnmus to fix multiarch
coinstallability of ffmpeg.

nmu ffmpeg_7:2.7.2-1 . ANY . -m 'allow co-installs with binnmu-ed ffmpeg'

I don't know if that will cause a +b2 to be built on amd64 and mips*,
though, so:

nmu ffmpeg_7:2.7.2-1 . arm64 armel armhf hurd-any kfreebsd-any powerpc
powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32 . -m 'allow co-installs
with binnmu-ed ffmpeg'


-- 

Saludos,
Felipe Sateler

Bug#785926: pidgin removed after last apt-get dist-upgrade

[Omar Crea]

Dear Maintainer,

after I've done an apt-get update && apt-get dist-upgrade yesterday, pidgin
had been removed from the system. Trying to reinstall it outputs the
following:

$ apt-get install pidgin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pidgin : Depends: libpurple0 (>= 2.8.0) but it is not going to be installed
  Recommends: gstreamer0.10-plugins-good but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.

Trying to install libpurple0 the output becomes:

libpurple0 : Depends: libfarstream-0.1-0 (>= 0.1.1) but it is not going to
be installed

and so on:

libfarstream-0.1-0 : Depends: gstreamer0.10-plugins-good (>= 0.10.29) but
it is not going to be installed
...
gstreamer0.10-plugins-good : Depends: libtag1c2a (>= 1.5) but it is not
going to be installed

Maybe this is correlated to the original bug report.

Best regards, Omar

-- 
Omar Crea

Mobile: +39 3926192511
Email: omar.c...@thyme.it
Skype: omarc.work

Thyme S.r.l.
Sede operativa:
Laboratorio Innovazione Breda
Via Venezia 23
20099 Sesto San Giovanni (MI)

Sede legale:
Via Fiordaliso 36
20095 Cusano Milanino (MI)

P.IVA 06416960968

Bug#798361: mercurial-server: fails to install: mercurial-server.postinst: update-python-modules: not found

[Andreas Beckmann]

Package: mercurial-server
Version: 1.2-2.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package mercurial-server.
  (Reading database ... 
(Reading database ... 8959 files and directories currently installed.)
  Preparing to unpack .../mercurial-server_1.2-2.1_all.deb ...
  Unpacking mercurial-server (1.2-2.1) ...
  Setting up mercurial-server (1.2-2.1) ...
  /var/lib/dpkg/info/mercurial-server.postinst: 17: 
/var/lib/dpkg/info/mercurial-server.postinst: update-python-modules: not found
  dpkg: error processing package mercurial-server (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   mercurial-server


cheers,

Andreas


mercurial-server_1.2-2.1.log.gz
Description: application/gzip

Bug#798329: ifconfig: changed output format breaks scripts

[Martín Ferrari]

severity 798329 wishlist
tags 798329 wontfix
close 798329
thanks

On 08/09/15 12:34, Thorsten Glaser wrote:

> I need reliable, consistent, parsable output across all Debian versions
> (and some derivates).

There is no software that currently offers that promise. I understand it
is annoying, and myself have reported a bug to iproute2 (#726417) for a
similar situation, but the maintainer also did not want to diverge from
upstream, so I had to live with that.

>> direcly parsing files in /proc/net
> 
> Excuse me, but WTF?
> 
> The standard Unix interface for things is stdout of other commands,
> as in, filters and pipes. ifconfig is *the* standard utility to get
> information about interfaces.

Sorry, but ifconfig output is not standarised by policy or any other
doc. In fact, it varies wildly in its many implementations. It has been
deprecated as a means of talking with the network stack in Linux since
iproute exists, which is a Long Time Ago.

Also, it is not breaking other Debian packages, nor it is
malfunctioning, so severity can't be more than wishlist.

Finally, I have no intentions on maintaining a fork of net-tools to
support the 14 years old output format of ifconfig, so I am closing this
as wontfix.

-- 
Martín Ferrari (Tincho)

Bug#797999: sddm fails to start whereas kdm works correctly

[Dominik George]

Hi Eric,

> Unfortunately no. This is likely to be due to docking as I now have a
> half dozen boxes that work with sddm the only one that fails is a docked
> laptop.

And this laptop, does it by any chance use an Intel graphics chip?

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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

Bug#798346: gnome metapackage still uninstallable on sid since gcc5 transition

[Giacomo Mulas]

Package: gnome
Version: 1:3.14+3
Severity: important

Dear Maintainer,

since there was the big switch of sid to use gcc5 as default compiler suite,
the gnome metapackage became uninstallable.  While this is less bad right
now (apparently almost all of the dependencies are satisfied), compared to
taking out the entire desktop environment with a seemingly innocent "apt-get
dist-upgrade", as it happened at the beginning of the switch, it still is
uninstallable after weeks, and I could not even find a bug report explaining
what needs to be done before it can become installable again.  
While I understand that this can only be fixed working on other packages,
not in the metapackage itself, at least this information ("we know it's
broken, we know what needs to be done to fix it, we are doing it (add URL to
what's being done)) should be visible in a bug on gnome (where else should
one look for it?).

Thanks, bye
Giacomo


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

Kernel: Linux 4.0.8-jak (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome depends on:
ii  alacarte   3.11.91-2
ii  avahi-daemon   0.6.31-5
ii  bijiben3.16.2-2
ii  brasero3.12.1-1
ii  cheese 3.16.1-1
ii  cups-pk-helper 0.2.5-2+b1
ii  desktop-base   8.0.2
ii  evolution  3.16.3-1
ii  evolution-plugins  3.16.3-1
ii  file-roller3.16.3-1
ii  gedit  3.16.3-1
ii  gedit-plugins  3.16.0-1
ii  gimp   2.8.14-1+b1
ii  gnome-clocks   3.14.1-1
ii  gnome-color-manager3.16.0-1
ii  gnome-core 1:3.14+3
ii  gnome-documents3.16.3-1
ii  gnome-games1:3.14+3
ii  gnome-getting-started-docs 3.16.2-1
ii  gnome-logs 3.16.2-1
ii  gnome-maps 3.16.2-1
ii  gnome-music3.16.2-1
ii  gnome-nettool  3.8.1-1+b1
ii  gnome-orca 3.16.2-1
ii  gnome-photos   3.14.2-1+b1
ii  gnome-shell-extension-weather  0~20150615.git0162cf7-1
ii  gnome-sound-recorder   3.16.0-1
ii  gnome-tweak-tool   3.16.2-2
ii  goobox 3.3.4-1+b2
ii  gstreamer1.0-libav 1:1.4.5-dmo1
ii  gstreamer1.0-plugins-ugly  1.4.5-2+b1
ii  hamster-applet 2.91.3+git20120514.b9fec3e1-1
ii  inkscape   0.91-5
ii  libgtk2-perl   2:1.2495-1
ii  libreoffice-calc   1:4.4.5-2
ii  libreoffice-evolution  1:4.4.5-2
ii  libreoffice-gnome  1:4.4.5-2
ii  libreoffice-impress1:4.4.5-2
ii  libreoffice-writer 1:4.4.5-2
ii  nautilus-sendto3.8.2-1
ii  network-manager-gnome  1.0.4-1
ii  polari 3.16.1-2
ii  rhythmbox  3.2.1-1
ii  rhythmbox-plugin-cdrecorder3.2.1-1
ii  rhythmbox-plugins  3.2.1-1
ii  rygel-playbin  0.26.1-3
ii  rygel-tracker  0.26.1-3
ii  seahorse   3.16.0-1
ii  simple-scan3.17.4-1
ii  sound-juicer   3.16.1-1+b1
ii  telepathy-gabble   0.18.3-1+b1
ii  telepathy-rakia0.8.0-3
ii  telepathy-salut0.8.1-4
ii  totem-plugins  3.16.2-1
ii  transmission-gtk   2.84-2
ii  vinagre3.16.1-1
ii  xdg-user-dirs-gtk  0.10-1

Versions of packages gnome recommends:
ii  gnome-software  3.16.5-2

Versions of packages gnome suggests:
pn  iceweasel-l10n-all 
ii  xul-ext-adblock-plus   2.6.10+dfsg-1
ii  xul-ext-gnome-keyring  0.10-1

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme   3.16.2.1-2
ii  at-spi2-core 2.16.0-1
ii  baobab   3.16.1-1
ii  caribou  0.4.18.1-1
ii  caribou-antler   0.4.18.1-1
ii  dconf-gsettings-backend  0.24.0-2
ii  dconf-tools  0.24.0-2
ii  empathy  3.12.10-1
ii  eog  3.16.3-1
ii  evince   3.16.1-1
ii  evolution-data-server3.16.3-1+b1
ii  fonts-cantarell  0.0.16-1
ii  gdm3 3.14.2-2
ii  gkbd-capplet 3.6.0-1
ii  glib-networking  2.44.0-2
ii  gnome-backgrounds3.16.0-1
ii  gnome-bluetooth  3.16.1-1
ii  

Bug#798345: ITP: golang-github-seandolphin-bqschema -- Go library to process Google Big Query

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Owner: Dmitry Smirnov 

* Package name: golang-github-seandolphin-bqschema
  Version : 0.0~git20150424.0.f92a08f-1
  Upstream Author : Sean Dolphin
* URL : https://github.com/SeanDolphin/bqschema
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library to process Google Big Query
 BQSchema is a library to create Google Big Query schema directly
 from Go structs and import BigQuery QueryResponse into arrays of Go
 structs.


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

Bug#798329: ifconfig: changed output format breaks scripts

[Thorsten Glaser]

On Tue, 8 Sep 2015, Martín Ferrari wrote:

> Finally, I have no intentions on maintaining a fork of net-tools to
> support the 14 years old output format of ifconfig, so I am closing this
> as wontfix.

Hmpf. I’ll search for scripts using either ip or ifconfig
and do some hackery to work with either output format then.

Will the current format at least stay?

//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#798298: icedove segfaults after sometime

[shirish शिरीष]

In-line :-

On 9/8/15, Carsten Schoenert  wrote:
> On Tue, Sep 08, 2015 at 02:34:57AM +0530, shirish शिरीष wrote:
>
>> I definitely have icedove-dbg.
>>
>> $ dpkg -l icedove-dbg
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>> ||/ NameVersion  Architecture
>>Description
>> +++-===---
>> ii  icedove-dbg 40.0~b1-1amd64
>>Debug Symbols for Icedove
>
> O.k., then there must be something going wrong. I can't find any
> relation to a segfault within your log. This look more like a log of a
> running application.
>
>> I am/was under the impression that just running gdb will do the needful.
>>
>> https://wiki.debian.org/HowToGetABacktrace
>
> This wiki site helds a lot of usfull additional information, but just
> one small step away there is also the wiki site for Icedove and there is
> a detailed explanation how to create a gdb log that is usfull for us.
>
> https://wiki.debian.org/Icedove#Starting_Debugging
>
> I thought you know this ... as this is not your first report.
>
>> The only difference is that I forgot to set the pagination bit, could
>> that be the reason or something else ?
>
> No, if you use the correct command line to call gdb there is normally no
> need for this, it's just set automatically pagination to off.

Hi Carsten,
Sorry for being a nuisance. Didn't mean to be. I actually had another
session running and this is what it showed (again) . I do have it's
backtrace but am hesitant.

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffdeafe700 (LWP 3383)]
0x77bcdd8f in __libc_send (fd=68,
buf=buf@entry=0x7fffbcf46000, n=n@entry=53, flags=flags@entry=0) at
../sysdeps/unix/sysv/linux/x86_64/send.c:31
31  ../sysdeps/unix/sysv/linux/x86_64/send.c: No such file or directory.

This surely means that the program (Broken pipe) bit.



Anyways, will get back to you will the file. I'm sorry it will be big
as I'm also not an expert in reading gdb files.

> Regards
> Carsten

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#798354: warning: not replacing /usr/bin/py-afl-fuzz with a link

[Jakub Wilk]

Package: python-afl
Version: 0.5-2

If you have python3-afl_0.2.1-1, and then install python-afl_0.5-2, you 
get:


update-alternatives: using /usr/share/python-afl/py-afl-fuzz to provide 
/usr/bin/py-afl-fuzz (py-afl-fuzz) in auto mode
update-alternatives: warning: not replacing /usr/bin/py-afl-fuzz with a link
update-alternatives: warning: not replacing 
/usr/share/man/man1/py-afl-fuzz.1.gz with a link

...and you end up with the old py-afl-fuzz, which is not compatible with 
the new afl module.


Suggested solution: use Breaks to make sure than python-afl and 
python3-afl versions are always in sync.


--
Jakub Wilk

Bug#795518: selinux-utils: neither labels set or SELinux enabled

[Raphael Hertzog]

Control: severity -1 important

On Fri, 14 Aug 2015, Richard Jasmin wrote:
> when using "sudo selinux-activate" to enable SELinux and setting rcS properly,
> nothing actually happens once you reboot.The system respawns itself into a
> working state once more but SELinux remains disabled with no clue as to
> why.There is no other way to enable it and force a relabel of the system, 
> which
> does not seem to happen when enabling SELinux.
> 
> This seems to be a stretch problem as other version of debian seem to succeed
> at this point.Id use Jessie but xarchiver and ark have SEVERE data loss issues
> when making a backup set.

The same version of selinux-utils is in jessie and in stretch. And I got
it to work in jessie so I'm not sure that your report is accurate. Until
then I drop the severity to important to avoid the removal of the package
from testing...

How did you come to the conclusion that it was not working?

Please give the output of the following commands (on the system that is
supposed to be SELinux enabled):

cat /proc/cmdline
grep GRUB_CMDLINE_LINUX /etc/default/grub
sudo selinuxenabled && echo yes

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#798357: libnetcdf-cxx-legacy-dev: fails to upgrade from 'jessie' - trying to overwrite /usr/share/info/netcdf-cxx.info.gz

[Andreas Beckmann]

Package: libnetcdf-cxx-legacy-dev
Version: 4.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libnetcdf-cxx-legacy-dev.
  Preparing to unpack .../libnetcdf-cxx-legacy-dev_4.2-1_amd64.deb ...
  Unpacking libnetcdf-cxx-legacy-dev (4.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libnetcdf-cxx-legacy-dev_4.2-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/info/netcdf-cxx.info.gz', which is also in 
package netcdf-doc 1:4.1.3-7.2
  Errors were encountered while processing:
   /var/cache/apt/archives/libnetcdf-cxx-legacy-dev_4.2-1_amd64.deb


cheers,

Andreas


netcdf-doc=1%4.1.3-7.2_libnetcdf-cxx-legacy-dev=4.2-1.log.gz
Description: application/gzip

Bug#797228: filezilla: FTBFS on mips/mipsel/powerpc (undefined reference to __atomic_store_8)

[Jurica Stanojkovic]

tags 797228 + patch
thanks

Hello,

I have attached patch created from upstream source:

2015-08-16 17:57 codesquid, revision 
6931

  *   M 
/FileZilla3/trunk/configure.ac
  *   A 
/FileZilla3/trunk/m4/check_atomic.m4

Add check whether we need -latomic

2015-08-18 18:19 codesquid, revision 
6938

  *   M 
/FileZilla3/trunk/m4/check_atomic.m4

Use LIBS instead of LDFLAGS in -latomic detection.

With this patch package builds from source on mipsel successfully.

Please consider including this patch to current package version.
Thank you!

Regards,
Jurica
--- filezilla-3.12.0.2.orig/configure.ac
+++ filezilla-3.12.0.2/configure.ac
@@ -53,6 +53,9 @@ if ! test "$localesonly" = "yes"; then
   # No thread_local in GCC 4.7 and it for some reason isn't supported on OS X either
   CHECK_THREAD_LOCAL
 
+  # std::atomic on PPC seems to require -latomic
+  CHECK_ATOMIC
+
   # Add build information to config.h
   # -
 
--- /dev/null
+++ filezilla-3.12.0.2/m4/check_atomic.m4
@@ -0,0 +1,39 @@
+# Some versions of gcc/libstdc++ require linking with -latomic if
+# using the C++ atomic library.
+
+m4_define([_CHECK_ATOMIC_testbody], [[
+  #include 
+  #include 
+
+  int main() {
+std::atomic a{};
+
+int64_t v = 5;
+int64_t r = a.fetch_add(v);
+return static_cast(r);
+  }
+]])
+
+AC_DEFUN([CHECK_ATOMIC], [
+
+  AC_LANG_PUSH(C++)
+
+  AC_MSG_CHECKING([whether std::atomic can be used without link library])
+
+  AC_LINK_IFELSE([AC_LANG_SOURCE([_CHECK_ATOMIC_testbody])],[
+  AC_MSG_RESULT([yes])
+],[
+  AC_MSG_RESULT([no])
+  LIBS="$LIBS -latomic"
+  AC_MSG_CHECKING([whether std::atomic needs -latomic])
+  AC_LINK_IFELSE([AC_LANG_SOURCE([_CHECK_ATOMIC_testbody])],[
+  AC_MSG_RESULT([yes])
+],[
+  AC_MSG_RESULT([no])
+  AC_MSG_FAILURE([cannot figure our how to use std::atomic])
+])
+])
+
+  AC_LANG_POP
+])
+

Bug#798332: witty: blank page

[ioann sys]

Thank for your reply!

It primitive code don't work:

--
main.cpp
--
#include 
#include 
#include 
#include 
#include 
using namespace std;
using namespace Wt;


class c_web_app : public WApplication
{
public:
c_web_app(const WEnvironment& env) : WApplication(env)
{
this->setTitle("Web App! Now title not work.");
WContainerWidget *webpage = new WContainerWidget(this->root());

webpage->addWidget(new WText("Hello!"));
}

private:

};

WApplication* create_app(const WEnvironment& env)
{
return new c_web_app(env);
}

int main(int argc, char *argv[])
{
const int a = 9;
char *v[a];

v[0] = argv[0];

v[1] = (char*) "--http-address";
v[2] = (char*) "0.0.0.0";

v[3] = (char*) "--http-port";
v[4] = (char*) "8080";

v[5] = (char*) "--deploy-path";
v[6] = (char*)  "/";


v[7] = (char*) "--docroot";
v[8] = (char*) ".;/resources";



return WRun(a, v, _app);
}
-
//
//
//
//
//
//
-
CMakeLists.txt
-
project(test1)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})

set(CMAKE_CXX_FLAGS "-lwt -lwthttp")
-





But, i see requests in stdout:

Запускается /home/ioann/workspace/test1/build/test1...

[2015-Sep-08 13:22:53.445993] 2948 - [info] "config: reading Wt config 
file: /etc/wt/wt_config.xml (location = 
'/home/ioann/workspace/test1/build/test1')"


[2015-Sep-08 13:22:53.446968] 2948 - [info] "WServer/wthttp: 
initializing built-in wthttpd"


[2015-Sep-08 13:22:53.447312] 2948 - [info] "wthttp: started server: 
http://0.0.0.0:8080;


[2015-Sep-08 13:22:55.253040] 2948 - [info] "Wt: session created 
(#sessions = 1)"


[2015-Sep-08 13:22:55.253141] 2948 [/ Iw6fNZRGMugn8FUO] [info] 
"WEnvironment: UserAgent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36"


[2015-Sep-08 13:22:55.253847] 2948 - [info] "WebRequest: took 0.875ms"

127.0.0.1 - - [2015-Sep-08 13:22:55.253797] "GET / HTTP/1.1" 200 2649

127.0.0.1 - - [2015-Sep-08 13:22:55.307885] "GET 
/?wtd=Iw6fNZRGMugn8FUO=style HTTP/1.1" 200 91


[2015-Sep-08 13:22:55.307919] 2948 - [info] "WebRequest: took 40.434ms"

127.0.0.1 - - [2015-Sep-08 13:22:55.319758] "GET 
/resources/themes/default/wt.css HTTP/1.1" 404 85127.0.0.1 - - 
[2015-Sep-08 13:22:55.319810] "GET /resources/webkit-transitions.css 
HTTP/1.1" 404 85



127.0.0.1 - - [2015-Sep-08 13:22:55.322411] "GET 
/?wtd=Iw6fNZRGMugn8FUO=1424260071=true=1920=1080=180=true=%2F=script=1081462392 
HTTP/1.1" 200 57830


[2015-Sep-08 13:22:55.322455] 2948 - [info] "WebRequest: took 15.143ms"

[2015-Sep-08 13:22:55.335467] 2948 - [info] "Wt: session created 
(#sessions = 2)"


127.0.0.1 - - [2015-Sep-08 13:22:55.337313] "GET /favicon.ico HTTP/1.1" 
200 2659


[2015-Sep-08 13:22:55.335793] 2948 [/ MoPc9f0Pg6bxsbGy] [info] 
"WEnvironment: UserAgent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36"


[2015-Sep-08 13:22:55.337402] 2948 - [info] "WebRequest: took 2.095ms"








08.09.2015 11:47, Pau Garcia i Quiles пишет:

Hello,

Have you tried to clean the browser cache, close & reopen the browser 
and press Control + F5 to make sure a new copy is reloaded?


Have you tried with other browsers and/or from a different computer?

If that does not work, could you please provide sample code that leads 
to a blank page so that I can try it?


Thank you



On Tue, Sep 8, 2015 at 10:07 AM, ioann sys > wrote:


Package: witty
Version: 3.3.4+dfsg-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Hello! After upgrading witty,my projects has been run, but i can
see content
(images, buttons and title!)



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

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

Versions of packages witty 

Bug#796179: tesseract-ocr: tesseract fails to generate output

[Boris Pek]

control: severity 796179 normal
control: tags 796179 = moreinfo unreproducible


Hi,

I have tested [1] tesseract/3.04.00-5 [2] on two Debian testing systems (amd64)
and on two Debian unstable systems (amd64 and i386) and I can not reproduce this
problem. All works as expected. Therefore I decrease the severity of this bug
and tag it as moreinfo and unreproducible. Maybe it should be closed at all.
But this is a maintainer decision.

Best regards,
Boris


[1] Only english and russian text were checked from yagf and from command line.
[2] List of tesseract packages:
$ LC_ALL=C dpkg -l '*tesseract*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---===
ii  libtesseract3   3.04.00-5i386 Tesseract OCR 
library
ii  tesseract-ocr   3.04.00-5i386 Tesseract command 
line OCR tool
un  tesseract-ocr-data(no description 
available)
ii  tesseract-ocr-eng   3.04.00-1all  tesseract-ocr 
language files for English
ii  tesseract-ocr-equ   3.04.00-1all  tesseract-ocr 
language files for equations
ii  tesseract-ocr-osd   3.04.00-1all  tesseract-ocr 
language files for script and
ii  tesseract-ocr-rus   3.04.00-1all  tesseract-ocr 
language files for Russian
ii  tesseract-ocr-ukr   3.04.00-1all  tesseract-ocr 
language files for Ukranian

Bug#798329: ifconfig: changed output format breaks scripts

[Martín Ferrari]

On 08/09/15 13:44, Thorsten Glaser wrote:

> Will the current format at least stay?

Honestly, I don't know upstream plans, but I don't foresee many more
changes. If I read the git logs correctly, this change dates back to
2003, and the latest upload is just catching up with 14 years of
upstream development with no releases.


-- 
Martín Ferrari (Tincho)

Bug#798352: bash: xmalloc: ../bash/variables.c:3532: cannot allocate 1433 bytes (32768 bytes allocated

[Gianluca Renzi]

Package: qemu-user-static
Version: 1:2.1+dfsg-12+deb8u2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

using a debian chroot for armel in a powerpc linux environment this issue can 
be obtained:

sudo chroot debian-systems/armel/wheezy/
bash: xmalloc: ../bash/variables.c:3532: cannot allocate 1433 bytes (32768 
bytes allocated)

on a x86_64 linux enviroment it works fine.

On the powerpc(32 bit) using:

sudo chroot debian-systems/armel/wheezy/ /bin/sh

it works.

sudo chroot debian-systems/armel/wheezy/ /bin/dash

it works.

Only bash seems to be affected.

Please help me to workaround this situation on powerpc because it is the only 
laptop I have and I need a working qemu chroot environment as in x86_64.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.16.0-4-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.5-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.10p3-1+deb8u2

-- no debconf information

Bug#798356: ITP: libnftables -- high-level library for nftables framework

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 

* Package name: libnftables
  Version : 0.0.1
  Upstream Author : Pablo Neira Ayuso 
* URL : http://www.netfilter.org
* License : GPL
  Programming Lang: C
  Description : high-level library for nftables framework

libnftables is high-level library for the nftables framework.

A bit of background: at first, the current libnftnl (low-level library for the
nftables framework) was called libnftables. But just before libnftables was
released, the Netfilter folks renamed it to libnftnl, so the name
libnftables was keep reserved for this high-level library.

As announced by the Netfilter folks, the release of libnftables is about
to happen.

Bug#798360: vim-voom: fails to install: vim-voom.postinst: line 23: vim-addon-manager: command not found

[Andreas Beckmann]

Package: vim-voom
Version: 5.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package vim-voom.
  (Reading database ... 
(Reading database ... 11248 files and directories currently installed.)
  Preparing to unpack .../vim-voom_5.1-2_all.deb ...
  /var/lib/dpkg/tmp.ci/preinst: 19: /var/lib/dpkg/tmp.ci/preinst: vim-addons: 
not found
  Unpacking vim-voom (5.1-2) ...
  Setting up vim-voom (5.1-2) ...
  /var/lib/dpkg/info/vim-voom.postinst: line 23: vim-addon-manager: command not 
found
  dpkg: error processing package vim-voom (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   vim-voom


cheers,

Andreas


vim-voom_5.1-2.log.gz
Description: application/gzip

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

On Mon, 31 Aug 2015 14:14:35 +0200 Danny Edel wrote:
> I am currently working on a proof-of-concept version of d/rules doing
> all of that, I will report back here once I've got a working draft.

I have pushed a working packaging to github. It's not of
release-quality, but it should serve as a proof-of-concept for building
from git tags.

git clone git://github.com/dannyedel/pkg-borgbackup.git
gbp buildpackage -uc -us [-S/-b]

Browse: https://github.com/dannyedel/pkg-borgbackup

Things left to do/discuss:

* Lintian notices that the binaries are not properly hardened. I've
tried including /usr/share/dpkg/buildflags.mk, but enabling pie in the
hardening options breaks the build on the cython files. I am not sure
what's the right course of action here.

* If we symlink borg to borgbackup (like the package name), lintian
complains that /usr/bin/borgbackup has no manpage. Do we also symlink
the manpage or is there a special syntax to say "load 'man borg' when
someone types 'man borgbackup'"?


Just to make clear, I don't think this packaging is ready for production
use as-is.  It's meant as a proof-of-concept of building from the
minimal set of source files (i.e. the ones versioned in git), using
debian packaged versions of cython and sphinx to re-generate the rest.
If you also think that's a good idea, please use as much or as little as
seems appropriate.


Danny

Bug#798202: ITP: fonts-leckerli-one -- Leckerli One font

[Johannes Schilling]

hi,

On Sun, Sep 06, 2015 at 06:05:19PM +, Gioele Barabucci wrote:
> * URL : 
> http://www.example.org://www.google.com/fonts/specimen/Leckerli+One

that doesn't seem right

lg,
   dario

Bug#798351: ITP: aioxmlrpc -- XML-RPC for asyncio

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ożarowski 

* Package name: aioxmlrpc
  Version : 0.1
  Upstream Author : Guillaume Gauvrit 
* URL : https://github.com/mardiros/aioxmlrpc
* License : BSD-3-clause 
  Programming Lang: Python
  Description : XML-RPC for asyncio

Binary package names: python3-aioxmlrpc

 Asyncio version of the standard lib xmlrpc.
 .
 Currently only aioxmlrpc.client, which works like xmlrpc.client but
 with coroutine is implemented.
 .
 aioxmlrpc is based on aiohttp for the transport, and just patch
 the necessary from the python standard library to get it working.
 .
 Example of usage:
 .
  import asyncio
  from aioxmlrpc.client import ServerProxy
 .
  @asyncio.coroutine
  def print_gandi_api_version():
  api = ServerProxy('https://rpc.gandi.net/xmlrpc/')
  result = yield from api.version.info()
  print(result)
 .
  if __name__ == '__main__':
  loop = asyncio.get_event_loop()
  loop.run_until_complete(print_gandi_api_version())
  loop.stop()

Bug#795597: Conkeror crashes on start up with SyntaxError, ReferenceError and TypeError

[Axel Beckert]

Control: tag -1 = confirmed jessie patch
Control: severity -1 grave

Hi Thomas,

Thomas Bach wrote:
> thanks for investigating. I have little time myself and couldn't
> further stick into it myself.

No problem.

> On 09/05/2015 12:33 PM, Axel Beckert wrote:
> > Thomas Bach wrote:
> >> iceweasel is on version 38.2.0esr-1~deb8u1
> > [...]
> >> I guess this is related to the last update of iceweasel.
> > 
> > I thought so, too, but it works for me with iceweasel 
> > 38.2.1esr-1~deb8u1. (there was one more update shortly after 
> > 38.2.0esr-1~deb8u1.)

I must admit that I didn't check carefully enough: While it was indeed
a Jessie desktop machine where I tested it, I forgot that it tracks
the nightly builds repo of conkeror.

Today I worked on a machine where I could clearly reproduce your
issue. And given that the nightly snapshots work fine Jessie, it was
clear that I just had to find out which upstream commit fixes it.

It's this one:

http://repo.or.cz/conkeror.git/commit/6906955ef78caeb357b729e1f608dfe1f0171dcc

I'll prepare an upload to stable-proposed-updates this evening. Sorry
for the delay.

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

Bug#798354: warning: not replacing /usr/bin/py-afl-fuzz with a link

[Daniel Stender]

... or even better, as you suggest, always against older versions to get sure.

Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#797793: Test failure of python-htseq on 32bit arches

[Andreas Tille]

Hi Simon,

I guess/hope you know that the Debian Med team (namely Diane Trout)
packaged htslib for the Debian distribution.  Recently we upgraded to
the latest version (0.6.1p1) which caused some trouble with one test
(out of 37) for 32 bit architectures.  The issue is reported as Debian
bug #797793.  For instance here is one build log of i386:

   
https://buildd.debian.org/status/fetch.php?pkg=htseq=i386=0.6.1p1-1=1439721264

with the critical part of

python2.7 test/test.py
Doctest of tss.rst:
**
File "../doc/tss.rst", line 114, in tss.rst
Failed example:
wincvg
Expected:
array([0, 0, 0, ..., 0, 0, 0], dtype=int32)
Got:
array([0, 0, 0, ..., 0, 0, 0])
**
1 items had failures:
   1 of  37 in tss.rst
***Test Failed*** 1 failures.
1 of 37 tests failed.


Could you please give some hint how to deal with this?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#798248: Patch to fix FTBFS on Alpha

[Felipe Sateler]

Control: tags -1 upstream

Hi Michael,

On 7 September 2015 at 17:39, Michael Cree  wrote:
> Control: tags -1 + patch
>
> Here goes a patch to fix the FTBFS on Alpha.  It protects the
> floating point addition of volumes in dB from adding any infinities.
> An assumption is made that negative infinity is the only possible
> non-finite number since dB are calculated via a logarithm from
> volumes and volumes are necessarily non-negative.

I am happy to apply this patch to the debian package. However, it
would be great if you could forward this upstream (to
pulseaudio-disc...@lists.freedesktop.org) for eventual inclusion
(either as-is or in modified form). This way the debian diff can be
maintained minimal over the long run.

-- 

Saludos,
Felipe Sateler

Bug#798358: cryptmount: fails to install: cryptmount.postinst: deb-systemd-helper: not found

[Andreas Beckmann]

Package: cryptmount
Version: 5.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package cryptmount.
  (Reading database ... 
(Reading database ... 7440 files and directories currently installed.)
  Preparing to unpack .../cryptmount_5.1-2_amd64.deb ...
  Unpacking cryptmount (5.1-2) ...
  Setting up cryptmount (5.1-2) ...
  /var/lib/dpkg/info/cryptmount.postinst: 25: 
/var/lib/dpkg/info/cryptmount.postinst: deb-systemd-helper: not found
  dpkg: error processing package cryptmount (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   cryptmount


cheers,

Andreas


cryptmount_5.1-2.log.gz
Description: application/gzip

Bug#798284: [kwin-x11] Crashes on multi monitor setup

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 07 September 2015 17:00:18 Franz Schrober wrote:
> Package: kwin-x11
> Version: 4:5.4.0-2
> Severity: normal
> 
> I can login to plasma via sddm quite fine when I have my laptop removed
> from the docking station. But when I start kwin_x11 or plasma via sddm
> when I have it inside the docking station (2x HDMI) it will crash. I
> have no idea how to get a backtrace from these situation.
> 
> But it was possible for me to start openbox via sddm. Then I've
> activated via xrandr both HDMI outputs and disabled the laptop screen.
> I could then run kwin_x11 --replace
> 
> The crash backtrace program started and showed me following:

You might want to try with the current Qt version in experimental, or wait 
until it lands in unstable. i'm not saying this will fix it, but might.

-- 
"La política es una actividad noble. Hay que revalorizarla, ejerciéndola con
vocación y una dedicación que exige testimonio, martirio, o sea, morir
por el bien común."
  Padre Bergoglio - http://www.lanacion.com.ar/1153060

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#798359: lintian: list of autopkgtest restrictions is not up-to-date

[Jérémy Bobbio]

Package: lintian
Version: 2.5.36.1

Hi!

It seems that the list of known restrictions for debian/tests/control is
not up-to-date.

Several packages raise unknown-runtime-tests-restriction [1] despite
using restrictions properly listed in the reference documentation [2].

 [1]: https://lintian.debian.org/tags/unknown-runtime-tests-restriction.html
 [2]: 
https://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD

Thanks!
-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature