Bug#808125: libreoffice-base: c/p from calc to create table, character_data does not exist on postgresql

[Wim Bertels]

> > Problem:
> > - base takes a datatype character_data which doens't exist in postgresql, 
> > it should be varchar for example
> > 

> Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=92538?
> 
> Which suggests at least that it's definitely only PostgreSQL being affected
> and that only with the "native" connection which might make it a bug of
> libreoffice-sdbc-postgresql...

Nice link, didn't find it,
but i think its more likely to be unrelated to postgresql, but related
to base (and possibly only sdbc as you say)

i checked the oracle docu: there is also no character_datatype..
https://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#i3253

To continue:
i tried the same setup with a local hsqldb:
* there the character_data type doesn't exist and isn't even available
as an option, the value here is varchar , as it should be

mvg,
Wim

Bug#808093: gnome-panel: text color is the same of background

[Sandro Tosi]

On Wed, Dec 16, 2015 at 12:01 PM, Dmitry Shachnev  wrote:
> Control: tags -1 moreinfo unreproducible

but the you say you can reproduce it :)

> On Tue, Dec 15, 2015 at 11:22:43PM +, Sandro Tosi wrote:
>> Package: gnome-panel
>> Version: 3.18.1-1
>> Severity: important
>>
>> Hello,
>> I'm attaching some screenshots to show how the text and the background are 
>> the
>> same color (basically masking all teh text) in the app bar (if the 
>> application
>> does no have the focus or in background) and also in the upper bar, where
>> 'Applications', 'Places', the central time panel and the last menu on the 
>> right
>> all are dark-on-dark, but when selected the right dark-text/light-background 
>> is
>> used.
>>
>> That's severely impacting the usability of the desktop; I'm using 
>> gnome-fallback
>> with the default theme (adwaita).
>
> I get exactly the same behaviour as in your screenshots when I set the panel
> color manually to black.
>
> Can you please open the panel preferences (Alt + right click on the panel →
> Properties → Background) and make sure that it is set to use colors from 
> system
> theme, not custom colors?

that worked, but now I got a "light" panel (attached), while what I
like to have is a dark panel and a light-colored text

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

Bug#796345: transition: perl 5.22

[Niko Tyni]

On Wed, Dec 16, 2015 at 12:47:48AM +0100, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed

> Let's do this.

Thanks. I've just uploaded perl_5.22.1-1 to unstable.
-- 
Niko Tyni   nt...@debian.org

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Sandro Knauß]

Hey,

ah now i see the problem:
>extra/kipi-plugins/CMakeLists.txt:116 (find_package)

find_package(KF5 ${KF5_MIN_VERSION}
 OPTIONAL_COMPONENTS
 Archive  # for FlashExport
 ThreadWeaver # for Panorama
 CalendarCore # for Calendar
)

^^ here it tries to load CalendarCore with >"5.1.0"

jepp this is a bug on kipi-plugins side. It must changed to:
find_package(KF5CalendarCore 4.81.0 OPTIONAL)

or

find_package(KF5 4.81.0 OPTIONAL_COMPONENTS 
CalendarCore
)

my first guess was, that the find_package silently fails and the next line 
checks the kcalccore version in more depth.

regards,

sandro

PS: btw. I'm release manager of kdepim so also of kcalcore and i can tell you 
for sure, that there is no 5 version for kcalcore released now

Bug#808081: squeeze update of bind9?

[Raphael Hertzog]

Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of bind9:
https://security-tracker.debian.org/tracker/CVE-2015-8000

This issue has already been fixed in other stable releases
and I'm attaching the debdiff of the wheezy version as basis
to backport it to the squeeze version (it applies without conflicts).

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
http://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/
diff -u bind9-9.8.4.dfsg.P1/debian/changelog 
bind9-9.8.4.dfsg.P1/debian/changelog
--- bind9-9.8.4.dfsg.P1/debian/changelog
+++ bind9-9.8.4.dfsg.P1/debian/changelog
@@ -1,3 +1,13 @@
+bind9 (1:9.8.4.dfsg.P1-6+nmu2+deb7u8) wheezy-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Add patch to fix CVE-2015-8000.
+CVE-2015-8000: Insufficient testing when parsing a message allowed
+records with an incorrect class to be be accepted, triggering a REQUIRE
+failure when those records were subsequently cached.
+
+ -- Salvatore Bonaccorso   Mon, 14 Dec 2015 20:09:13 +0100
+
 bind9 (1:9.8.4.dfsg.P1-6+nmu2+deb7u7) wheezy-security; urgency=high
 
   * CVE-2015-5722: maliciously crafted DNSSEC key can cause named to crash.
diff -u bind9-9.8.4.dfsg.P1/lib/dns/resolver.c 
bind9-9.8.4.dfsg.P1/lib/dns/resolver.c
--- bind9-9.8.4.dfsg.P1/lib/dns/resolver.c
+++ bind9-9.8.4.dfsg.P1/lib/dns/resolver.c
@@ -6762,6 +6762,8 @@
goto done;
}
 
+dns_message_setclass(message, fctx->res->rdclass);
+
result = dns_message_parse(message, >buffer, 0);
if (result != ISC_R_SUCCESS) {
switch (result) {
@@ -6841,6 +6843,12 @@
}
 
 
+   if (message->rdclass != fctx->res->rdclass) {
+   resend = ISC_TRUE;
+   FCTXTRACE("bad class");
+   goto done;
+   }
+
/*
 * Log the incoming packet.
 */
only in patch2:
unchanged:
--- bind9-9.8.4.dfsg.P1.orig/lib/dns/message.c
+++ bind9-9.8.4.dfsg.P1/lib/dns/message.c
@@ -436,6 +436,8 @@
m->saved.base = NULL;
m->saved.length = 0;
m->free_saved = 0;
+   m->tkey = 0;
+   m->rdclass_set = 0;
m->querytsig = NULL;
 }
 
@@ -1084,13 +1086,19 @@
 * If this class is different than the one we already read,
 * this is an error.
 */
-   if (msg->state == DNS_SECTION_ANY) {
-   msg->state = DNS_SECTION_QUESTION;
+   if (msg->rdclass_set == 0) {
msg->rdclass = rdclass;
+   msg->rdclass_set = 1;
} else if (msg->rdclass != rdclass)
DO_FORMERR;
 
/*
+* Is this a TKEY query?
+*/
+   if (rdtype == dns_rdatatype_tkey)
+   msg->tkey = 1;
+
+   /*
 * Can't ask the same question twice.
 */
result = dns_message_find(name, rdclass, rdtype, 0, NULL);
@@ -1234,12 +1242,12 @@
 * If there was no question section, we may not yet have
 * established a class.  Do so now.
 */
-   if (msg->state == DNS_SECTION_ANY &&
+   if (msg->rdclass_set == 0 &&
rdtype != dns_rdatatype_opt &&  /* class is UDP SIZE */
rdtype != dns_rdatatype_tsig && /* class is ANY */
rdtype != dns_rdatatype_tkey) { /* class is undefined */
msg->rdclass = rdclass;
-   msg->state = DNS_SECTION_QUESTION;
+   msg->rdclass_set = 1;
}
 
/*
@@ -1249,7 +1257,7 @@
if (msg->opcode != dns_opcode_update
   

Bug#807810: if there is more than one forwarded bug address

[積丹尼 Dan Jacobson]

Wait, ah ha!: mention on the man page:
 If there is more than one forwarded address, use e.g.,
 bts forwarded 123456 "http://example.net/bugs/666 http://example.org/bugs/777;

> "NB" == Nicholas Bamber  writes:

NB> But this syntax does not actually forward the bug report. It documents
NB> where the bug report has been forwarded to. Why would we need more
NB> than one of those?

Bug#807074: fbreader: includes files with unclear DFSG-freeness and/or copyright status

[Francesco Poli]

On Tue, 15 Dec 2015 21:00:00 +0100 Eugene V. Lyubimkin wrote:

> On 14.12.2015 22:56, Francesco Poli wrote:
[...]
> > Hence, they basically say that some OASIS files (that they distribute
> > under DFSG-free terms) are derived, in part, from some ISO files which
> > do *not* grant any permission to modify.
> > 
> > Without any additional explanation, this sounds like a copyright
> > violation.
> 
> Here our interpretations diverge then. Indeed it's always allowed to
> suspect, but I'd much prefer that a RC bug is filed after those
> suspects are confirmed.

Well, but it's not just that I *suspect* that the OASIS files are
derived from some ISO files which do not grant any permission to
modify. It's written in the OASIS files themselves that this is the
case!

Hence, in the absence of an explanation of how this was legally
allowed, it really seems that something is wrong. Hence the bug
report...

> 
> >> If they say 'yes', how one is
> >> supposed to verify that they really do?
> > 
> > A simple "yes" answer would not suffice: they need to provide a
> > convincing explanation...
> 
> Out of curiosity, what can that be?

I have already mentioned some examples of possible explanations.
If one such explanation holds, then everything is fine.

Please note that I assume good faith on the OASIS side: probably they
have an explanation (but they forgot to clearly document it) or they
violated the ISO copyright by mistake...
Other scenarios are possible, of course, but I think they are less
likely to be the case.

> 
> > Dropping the OASIS files from package fbreader is the last resort
> > solution, assuming that those files are not strictly needed for the
> > package to provide significant functionality.
> 
> If a violation is present, this will be my first resort, otherwise
> fbreader will disappear from testing very quickly.
> Between absense of fbreader and worse DocBook format support in
> fbreader, I choose second.

If you mean that dropping the troublesome files from the package will
be your first *temporary* course of action, while attempting to find a
better solution, then I totally agree with you.
What I meant is that I would consider the *permanent* removal of the
files as a last resort solution, if all else fails. I hope you agree
with me.

[...]
> > Please note that, as I have previously said, one FTP Assistant
> > confirmed that files under the ISO license are not fit for Debian main:
> > https://lists.debian.org/debian-legal/2015/12/msg0.html
> 
> I don't read that as something I can directly apply for things
> under OASIS copyright. Of course I might be wrong, that's
> why I invited Debian archive masters to the loop. No reason
> for us to argue any longer, let's just wait for what they
> think.
[...]

OK, let's wait for a response from the FTP Masters, but please
investigate the legal status of the OASIS files in the meanwhile.


Thanks for your time and patience.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpAuDAleq02u.pgp
Description: PGP signature

Bug#807686: Do not modify the debian control files during package build

[Markus Koschany]

Control: tags -1 confirmed

Am 16.12.2015 um 16:26 schrieb Mattias Ellert:
[...]
> Hi!
> 
> When I converted my Debian Java packages from mvn-debian, I used dh.
> All of them are affected by this issue:
> 
> canl-java
> jglobus
> voms-api-java
> voms-clients-java

Hi,

thanks for the additional information. First of all I agree with you
that maven-debian-helper (mdh) should not modify files in the debian
directory or debian/rules clean should restore everything.

I have never experienced this issue myself because I use cowbuilder and
git-buildpackage for all my packages and I never had to use a workaround
for mdh. I have tested voms-api-java and removed the override for
dh_auto_install and debian/mh_resolve_dependencies. The package builds
successfully with git-buildpackage and debuild -us -uc. So the
workaround is not strictly needed because the resulting package contains
only the original files in debian/* and the build process works as
intended.

Please note that you should add a ${maven:Depends} substvar to your
binary packages in debian/control, otherwise mh_resolve_dependencies is
indeed useless.

I think we should solve the issue that maven-debian-helper modifies and
creates files in debian/ and secondly we should review whether we need
mh_resolve_dependencies during the dh_auto_install step.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#807236: psi4: Update build dependencies for GSL 2.x

[Sebastiaan Couwenberg]

On 06-12-15 16:24, Bas Couwenberg wrote:
> Please note that chemps2 (#807189) needs to be updated for GSL 2,
> before psi4 can be rebuilt with GSL 2.

With the upload of chemps2 (1.6-2) to unstable earlier today, the
blocker for this issue is gone.

Please update psi4 by applying the changes attached to this issue [0] as
soon as possible to remove this issue as a blocker for the gsl
transition (#804246).

[0]
https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=psi4_1%3A0.3-3.1.debdiff;msg=5;att=1;bug=807236

Kind Regards,

Bas

Bug#808162: NetworkManager does not allow remote management

[Marius Vollmer]

Package: network-manager
Version: 1.0.8-2

Hi,

the NetworkManager polkit policy in Debian does not allow changing or
adding connections from a remote session, such as a ssh or Cockpit
login.

The default upstream policy explicitly allows this.  See

https://bugzilla.redhat.com/show_bug.cgi?id=1145646

for some discussion.

In the bug report above, the action that needed adjustement was
"org.freedesktop.NetworkManager.network-control".  In Debian,
"org.freedesktop.NetworkManager.settings.modify.system" would need to be
allowed for "any".

Bug#790260: maude: FTBFS on i386 with glibc 2.21 and gcc-5

[Sven Joachim]

Control: severity -1 serious
Control: tags -1 + stretch sid

On 2015-06-27 13:10 -0700, Daniel Schepler wrote:

> Source: maude
> Version: 2.6-6
> Severity: normal
>
> From my i386 pbuilder build log, using a setup preferring glibc and
> gcc-defaults from experimental:
>
> ...
> Making check in tests
> make[2]: Entering directory '/tmp/buildd/maude-2.6/tests'
> Making check in BuiltIn
> make[3]: Entering directory '/tmp/buildd/maude-2.6/tests/BuiltIn'
> make  check-TESTS
> make[4]: Entering directory '/tmp/buildd/maude-2.6/tests/BuiltIn'
>
> At this point, the build hangs and must be interrupted manually.

The same happened for the 2.6-6+1 binNMU on the buildds[1], except on
those which still had libc6 2.19-22 in the chroot, hence I'm bumping the
severity.

Cheers,
   Sven


1.https://buildd.debian.org/status/package.php?p=maude

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

Hi Michael,

On Mon, 14 Dec 2015 21:59:27 -0600
Michael Shuler  wrote:

> Thanks for your thoughts. A separate package is an interesting interim
> idea, but in looking at what redhat has done, I think a more complete
> transition to trust type buckets is preferred, along with including a
> code-signing cert bucket. I think it's the extra package and updating
> deps for a short-term solution that I'm not fond of. That would need
> another update of deps and proper solution in the long term.

Thanks for considering my suggestions.  While I agree that using
separate trust buckets is the best solution, I'm concerned that the
time it takes to triage and patch other packages will unnecessarily
prolong the risk to users who don't even use S/MIME. So I suggest
making the short-term solution a stepping stone for the long-term
solution, so that work doesn't have to be undone later.

Specifically, I propose changing the ca-certificates source package to
generate three binary packages:

1. ca-certificates-server

2. ca-certificates-email

3. ca-certificates - a metapackage that depends on
ca-certificates-server, and (at most) suggests ca-certificates-email

For now, ca-certificates-server and ca-certificates-email will install
roots to the same location.  Once separate root stores are supported,
it will be a simple change to these packages to install to separate
locations instead.

Other packages could continue to depend on just ca-certificates because
it will pull in ca-certificates-server automatically. Over time,
packages could be modified to have a more fine-grained dependency on
ca-certificates-server and/or ca-certificates-email, but there's no
urgency to this and there would be no need to switch dependencies back
later.  In fact, until separate stores are supported, *no* package
should depend on ca-certificates-email, not even MUAs that support
S/MIME. Just because a MUA supports S/MIME doesn't mean that users use
it. The majority of users of such MUAs only need root certificates for
secure SMTP/IMAP/POP, not S/MIME, and they should be able to avoid the
email-only roots until they're properly segregated.

As for the code signing trust store, note that Mozilla is
discontinuing their code signing root program[1], so Debian would need
to either operate its own root program or find another root program to
use for code signing.  Do you know if there is any demand for
code-signing roots in Debian?

I should also mention that Mozilla's email trust store is on life
support, and is at risk of being discontinued if no one steps up to help
maintain it[2].  Splitting it into a separate package in Debian could
be a good way to get the word out to people who rely on it that they
should consider contributing upstream to prevent its discontinuation.

Regards,
Andrew


[1] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02409.html

[2] 
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02413.html

Bug#784357: memcached multi instance startup/shutdown broken

[Jonathan Champ]

Ran into this again today. Hope there's been some progress?

Bug#808177: isenkram: Should support appstream as a data source

[Petter Reinholdtsen]

Package: isenkram
Version: 0.19
Severity: wishlist

The isenkram system should support appstream as a data source, using the
modalias value.  See
https://github.com/ximion/appstream/blob/master/src/as-provided.h#L70 >
for information about the value, and
https://appstream.debian.org/html/sid/main/metainfo/pymissile.html > for
an example in the archive.

-- 
Happy hacking
Petter Reinholdtsen

Bug#805629: RM: (lazarus|lcl)-*-1.4.0 -- ROM; NVIU: old version preventing migration

[Paul Gevers]

Ping,

On Fri, 20 Nov 2015 13:33:21 +0100 Paul Gevers  wrote:
> Next to lazarus-1.4.0 there are also lazarus-src-1.4.0 and lazarus-doc-1.4.0
> that apparently should be manually removed for the lazarus 1.4.4 suite to
> migrate to testing. It looks like the arch=any packages will be autodecrufted,
> but removing them as well may not hurt.
> 
> So in [all]:
> lazarus-doc-1.4.0, lazarus-src-1.4.0
> in [any]:
> lazarus-ide-1.4.0, lazarus-ide-gtk2-1.4.0, lazarus-ide-qt4-1.4.0, lcl-1.4.0,
> lcl-gtk2-1.4.0, lcl-nogui-1.4.0, lcl-qt4-1.4.0, lcl-units-1.4.0,
> lcl-utils-1.4.0

Nearly a month has passed and lazarus is just waiting for some decrufting.

Please?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#808179: gluegen2: FTBFS on non-Linux arches

[Steven Chamberlain]

Package: gluegen2
Version: 2.3.2-3
Severity: wishlist
Tags: patch

Hi!

gluegen2 FTBFS on non-Linux arches because it (awkwardly) needs
definitions for every build architecture.

We can support kfreebsd (and potentially hurd when it gets openjdk)
quite easily though, just by treating them the same as Linux arches.
A patch is attached for this.  Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From: Steven Chamberlain 
Date: Wed, 16 Dec 2015 20:13:01 +
Subject: treat GNU/kFreeBSD or Hurd just as Linux

--- a/make/gluegen-cpptasks-base.xml
+++ b/make/gluegen-cpptasks-base.xml
@@ -292,7 +292,12 @@
   
 
 
-  
+  
+
+
+
+
+  
 
 
   

Bug#684721: snmpd: Lots of errors in syslog : error on subcontainer 'ia_addr' insert (-1)

[Pik Master]

Hi, I created a patch, to get rid of this error:

http://sourceforge.net/p/net-snmp/patches/1322/

Pik

Bug#808055: [pkg-php-pear] Bug#808055: php-pinba: FTBFS: PHP Fatal error: Call to a member function getFilelist() on null in /usr/share/php/PEAR/Command/Install.php on line 747

[Mathieu Parent]

>
> Dear Maintainer,

hello Chris,

> php-pinba fails to build from source in unstable/amd64:

This is same as #805222. More info there (but no fix yet).

Regards
-- 
Mathieu Parent

Bug#807139: scrot: Provide with a way to prevent screenshots from being overwriten

[Sophoklis Goumas]

On 6 December 2015 at 00:37, Sophoklis Goumas  wrote:
> ...
>

Just a quick update on a workaround on this, one can set PrtScr to this:
scrot -q -z 'scrot_%Y%m%d_%H%M%S.png' --backup=simple --suffix=.scrot
-e 'mv $f ~/Desktop'

This will create another image suffixed with: .scrot making in obvious
how it got created, in the case there were more than one screenshots
taken at a given second.

Sophoklis

Bug#808178: opendkim complains about directory permissions that the sendmail package creates

[David Caldwell]

Package: opendkim
Version: 2.10.3-3+b1
Severity: normal

Dear Maintainer,

The sendmail package makes /etc/mail owned by `smmta`. Opendkim complains
about this:

Dec 16 11:20:04 [mymachine] opendkim[3373]: [mydomain]: key data is not secure: 
/etc/mail is writeable and owned by uid 112 which is not the executing uid 
(100) or the superuser

I'm currently "fixing" this by chowning /etc/mail to root.

But everytime the sendmail package upgrades it resets it back to smmta and
all my mail starts getting deferred again.

Since Debian is setting this to smmta, can we get a patch to opendkim so it
understands this is correct? It's frustrating to have 2 packages that butt
heads like this.

-David


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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 opendkim depends on:
ii  adduser  3.113+nmu3
ii  dns-root-data2015052300+h+1
ii  init-system-helpers  1.24
ii  libbsd0  0.7.0-2
ii  libc62.19-22
ii  libdb5.3 5.3.28-11
ii  libldap-2.4-22.4.42+dfsg-2
ii  liblua5.1-0  5.1.5-8
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libmilter1.0.1   8.15.2-3
ii  libopendbx1  1.4.6-9+b1
ii  libopendkim102.10.3-3+b1
ii  librbl1  2.10.3-3+b1
ii  libssl1.0.2  1.0.2d-3
ii  libunbound2  1.5.6-1
ii  libvbr2  2.10.3-3+b1
ii  lsb-base 9.20150917

opendkim recommends no packages.

Versions of packages opendkim suggests:
pn  opendkim-tools  
pn  unbound 

-- Configuration Files:
/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: 
u'/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed [not included]

-- no debconf information

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Eric Valette]

On 16/12/2015 20:15, Sandro Knauß wrote:


But digikam can't relay on a version for libkcalcore > 5 because the ci 
build.kde.org would show red for that.


It should not but it does.



I checked the source code (kipi plugins) and see the following CMakeLists.txt:
PRINT_OPTIONAL_LIBRARY_STATUS("libkcalcore" "https://projects.kde.org/projects/kde/pim/kcalcore;   
   "(version >= 4.81.0)" "Kipi-plugins will be compiled without libkcalcore 
support." KF5CalendarCore_FOUND)

what is correct.



I reinsatlled original version of the file with originam version number 
and rerun the bootstrap.linux Makefile and got this message:


Starting CMake configuration for: kipi-plugins
-- Found KF5: success (found suitable version "5.16.0", minimum required 
is "5.1.0") found components:  Config WindowSystem XmlGui I18n KIO 
Service IconThemes
CMake Warning at /usr/share/ECM/find-modules/FindKF5.cmake:74 
(find_package):

  Could not find a configuration file for package "KF5CalendarCore" that is
  compatible with requested version "5.1.0".

  The following configuration files were considered but not accepted:


/usr/lib/x86_64-linux-gnu/cmake/KF5CalendarCore/KF5CalendarCoreConfig.cmake, 
version: 4.82.0


Call Stack (most recent call first):
  extra/kipi-plugins/CMakeLists.txt:116 (find_package)


-- Could NOT find KF5CalendarCore , checked the following files:

/usr/lib/x86_64-linux-gnu/cmake/KF5CalendarCore/KF5CalendarCoreConfig.cmake 
(version 4.82.0)


I haven't yet found the line that generates that.



Hope that helps clearifing this.


It does but does not solve the compilation problem without hacking the 
version number.


-- eric

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Eric Valette]

I haven't yet found the line that generates that.


find_package(KF5 ${KF5_MIN_VERSION}
 OPTIONAL_COMPONENTS
 Archive  # for FlashExport
 ThreadWeaver # for Panorama
 CalendarCore # for Calendar   <==
)

--eric

Bug#695336: ITP: printrun -- Graphical host package to control 3d printers such as RepRap's.

[Richard Ulrich]

Hi Alvaro,

my RepRap is still in the drawer waiting for better times. 
It would be wonderful if you could finish the packaging, and make it
available in debian.

Rgds
Richard 

Am Montag, den 14.12.2015, 20:23 +0100 schrieb Rock Storm:
> Hi everyone,
> 
> I know it has been a very long time since the last "useful" message on
> this bug but, since it seems still open... I've recently found out
> about printrun and its lack of packaging and I would like to contribute
> to fit it in Debian.
> 
> Apart from Scott and Richard's, has anyone done any more work? Need any
> help? Starting from theirs I've been working on it a little starting
> from Richard and Scott's work and I'm storing it also on GitHub:
> 
> https://github.com/rockstorm101/printrun-for-debian
> 
> I'm currently working on adapting it to the 3dprinter team's way of
> working as was suggested by Felix.
> 
> Regards,
> Alvaro
> 

-- 
Meine Kontaktdetails sind immer aktuell in der NameCoin blockchain mit
der Kennung: id/ulrichard 
Teile davon sieht man mit folgendem Link:
https://nameid.org/?name=ulrichard
Bitte schicken Sie mir wenn möglich PGP/GPG verschlüsselte Nachrichten.


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

Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."

[lukash]

Package: libc6
Version: 2.19-22
Severity: normal
Tags: upstream

Dear Maintainer,

run with gdb:
$ gdb qtcreator
(gdb) run
Starting program: ~/Qt5.5.1/Tools/QtCreator/bin/qtcreator
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec5cb700 (LWP 1282)]
[New Thread 0x7fffd831b700 (LWP 1285)]

Program received signal SIGSEGV, Segmentation fault.
0x77de72c6 in ?? () from /lib64/ld-linux-x86-64.so.2



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/1 CPU core)
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 libc6 depends on:
ii  libgcc1  1:5.2.1-23

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.58
pn  glibc-doc  
ii  locales2.19-22

-- debconf information excluded

Bug#808181: libc6: Upgrade can make the linker unusable

[Dima Kogan]

Package: libc6
Severity: normal

Hi. I had

  libc6= 2.19-22
  binutils = 2.25-4

and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
sid). As a result, even the most basic build-time linking would fail.
For instance, with a trivial hello-world program:

  $ gcc-5 -o tst tst.c

  /usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized 
relocation (0x2a) in section `.init'
  /usr/bin/ld: final link failed: Bad value
  collect2: error: ld returned 1 exit status

This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
fix it. After some fiddling I realized that upgrading to binutils =
2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
latest libc6 and the latest binutils packages things work.

Can the broken combination be prevented with some Conflicts: tags?
Currently this is a trap for the unwary.

Bug#808170: pulseaudio: Since pulseadio 5 speaker output is on headphones channel And randomly resets settings.

[Felipe Sateler]

Control: tags -1 moreinfo

Hi

On 16 December 2015 at 15:25, Mark Caglienzi  wrote:
> Package: pulseaudio
> Version: 7.1-2
> Severity: important
>
> Dear Maintainer(s),
> I have an HP Pavilion DV6-7009el with this soundcard:
>
> IDT 92HD91BXX
>
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
> High Definition Audio Controller (rev 04)
> Subsystem: Hewlett-Packard Company Device 1818
> Flags: bus master, fast devsel, latency 0, IRQ 30
> Memory at d461 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: snd_hda_intel
>
> I am forced to continue to use Pulseaudio 4, because newer versions (also the 
> 7
> one) have this problem (which I found a nearly working (but annoying) 
> workaround to):
>
> * At boot, no audio

Does moving streams around with pavucontrol fix anything at this point?

> * I have to restart pulseaudio and launch alsamixer, choose the soundcard, max
> out the headphone volume and unmute it (It is always muted and at 0%)
>
> and NOW I have audio coming out my main laptop speakers (yes, it seems that
> from Pulseaudio 5 the mixer level for main speakers is the headphone one).
>
> Now if I plug headphones then the audio comes out only in the headphones and
> not from the main speakers (good), but when I unplug them -> settings reset
> (which seems to be good
> because if I unplug my headphones I want their channel to mute, *but* this bug
> gives me no audio on speakers, afterwards).
>
> And sometimes when an application uses audio, the settings revert to mute and
> 0% headphone channel level -> no audio (so I have to re-do the drill)
> For example VLC does not do this, pidgin sometimes does it and sometimes
> freezes itself. QBittorrent playing audio through mpg123 triggers the settings
> reset once again.


Could you attach a verbose log[1] while showing the problem? Also,
please attach the files generated by the pulseaudio bug script (why
weren't they attached?).


[1] http://wiki.ubuntu.com/PulseAudio/Log

-- 

Saludos,
Felipe Sateler

Bug#808176: RFP: python-neovim -- Library for scripting Neovim processes through its msgpack-rpc API

[Víctor Cuadrado Juan]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-neovim
  Version : 0.1.0
  Upstream Author : Thiago de Arruda  et al
* URL : https://github.com/neovim/python-client
* License : Apache 2.0
  Programming Lang: Python
  Description : Library for scripting Neovim processes through its msgpack-
rpc API

This package enables using python plugins and bindings
on Neovim, which is in process of being packaged in Debian[1].

The python package can be seen here:
https://pypi.python.org/pypi/neovim


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




-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWccShAAoJECI/Fcparw54Yy8IALhKYmhVkrwGWQhv/Yvo1gqG
hmy+QVsckRU09pWZQO33/nh2Y7rxvVTsWAkA1nAx+5lkFZN/psIn+NeCetwk4vs8
fnl3yedJhmBe1UQzPo7oxetSy5MBpnXtgmm0+esEx0VfCtLW/y3gbUWcEbl31X3o
1iGisO7vaVhtPLk8K6BuSJt+R1PppRZlI77AhP3fsjBPYeE1kiN7fvuWGbRCm2m7
fM+ZFt4Pw91auNvSnZAaCt2IhNFi5KW7x5ppogKjrDv+38R9QwXiWlVgJeXoPs4q
96eEhPa7kNBBKs9GSXRjlORHlN3hKbZRy87I/RS8vjMW/D9zTi/SolYtMKogfzg=
=x/8b
-END PGP SIGNATURE-

-- 
Víctor Cuadrado juan
--
E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Sandro Knauß]

Hey,

no it is not a bad version number, because it is planned to push kcalcore to 
Frameworks, but because it isn't ready for frameworks it is shipped with KDE 
Applications alongside with kdepim. Thats why the version number isn't synced 
with KDE Applications.

Regards,

sandro

Bug#808089: osm-gps-map is NEW

[Ross Gammon]

Hi,

Osm-gps-map has now been uploaded and due to the change of package name,
is waiting in the NEW queue:
https://ftp-master.debian.org/new/osm-gps-map_1.1.0-1.html

If this stands a chance of mucking up any other pending transition,
please let me know.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Eric Valette]

On 16/12/2015 17:58, Adrien Grellier wrote:

Hi,

It seems that the lib version is 4.82, as we can see in the filename or in the
CmakeLists.txt :
https://sources.debian.net/src/kcalcore/4:15.08.2-1/CMakeLists.txt/

In order to build digikam, I am afraid we will have to wait for a newer
version of libkf5calendarcore.


I'm quite surprised because digikam expects 15.08.2 which is the package 
version name. 4:15.08.2-1 => 15.08.2 no?



--eric

Bug#808167: RFS: adjtimex/1.29-7

[Roger Shimizu]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: adjtimex
* Version : 1.29-7
* Upstream Author : Steven S. Dick , James R. Van
Zandt 
* URL : http://metalab.unc.edu/pub/Linux/system/admin/time
* License : GPL-2
* Section : admin

It builds those binary packages:

  adjtimex   - kernel time variables configuration utility

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

  http://mentors.debian.net/package/adjtimex

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

dget -x 
http://mentors.debian.net/debian/pool/main/a/adjtimex/adjtimex_1.29-7.dsc

Changes since the last upload:
   * remove the wrong debian/dirs line in changelog of previous version 1.29-6
   * debian/patches:
   - Replace patch 03 with the one by Bjarni I. Gislason, which also
 minimizes the time of lock over "/dev/rtc" (Closes: #724929).
   - Fix potential uninitialized memory accessing
 (thanks peppe , Closes: #688933).
   - Avoid a few gcc warnings
   * debian/copyright: Add copyright for newly added patch
   * debian/adjtimexconfig:
   - Move tmp file during executing from /etc to /tmp.
   - Code clean up.
   * debian/templates + debian/config + debian/po + debian/NEWS:
   - Remove the debconf whether to start adjtimex on startup, which now
 depends on the existence of /etc/default/adjtimex file. By default,
 there's no /etc/default/adjtimex, which is generated by running:
 adjtimexconfig.
   - adjtimexconfig is still a choice in defconf, but change to false by
 default because it takes 70 seconds to excute on install/upgrade.
   * debian/postinst:
   - Refrain from running adjtimexconfig on configure, which is triggered by
 each install/upgrade
   - Refrain from starting adjtimex service on configure (Closes: #785208).
   - Code clean up.
   * debian/postrm:
   - Code clean up.
   * debian/adjtimex.init + debian/adjtimex.service: Start adjtimex service
   on startup only if config file /etc/default/adjtimex is ready.
   * debian/adjtimexconfig.8: Update man page

For the debconf change (remove adjtimex/run_daemon) and systemd
service change (add a condition path), it's already discussed in
systemd ML [0].

Thanks and look forward to the upload!

Cheers,
Roger Shimizu

[0]: 
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-December/009932.html

Bug#808175: jffi: FTBFS on non-Linux arches

[Steven Chamberlain]

Package: jffi
Version: 1.2.7-8
Severity: wishlist
Tags: patch

Hi!

jffi FTBFS on arches other than Linux, for a couple of reasons, both
fixed in the attached patches.

nonlinux_endian_h.patch:

Include the system's  for BYTE_ORDER definitions, not just on
Linux but on other platforms too.

nonlinux_platforms.patch:

debian/rules expects an output file called ../dist/jffi-*-Linux.jar,
its name basically determined by jffi-$(uname -m)-$(uname -s).jar
That is set by build.xml, not by jni/GNUmakefile.

On kfreebsd, $(uname -s) contains a forwardslash and this is not good
in filenames.  Since the naming is inconsequential anyway, just call it
jffi-*-Linux.jar even on kfreebsd on hurd.

Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From: Steven Chamberlain 
Date: Wed, 16 Dec 2015 18:56:35 +
Subject: just use platform=Linux for GNU/kFreeBSD and Hurd

--- a/build.xml
+++ b/build.xml
@@ -93,6 +93,13 @@
 
   
 
+
+
+  
+
+
+  
+
 
 
   
From: Steven Chamberlain 
Date: Wed, 16 Dec 2015 14:49:13 +
Subject: include endian.h on other platforms than Linux

--- a/jni/jffi/endian.h
+++ b/jni/jffi/endian.h
@@ -36,7 +36,7 @@
 #include 
 #include 
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__FreeBSD_kernel__) || defined(__GNU__)
 #  include_next 
 #endif
 

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Sandro Knauß]

Hi,

> I'm quite surprised because digikam expects 15.08.2 which is the package
> version name. 4:15.08.2-1 => 15.08.2 no?

Debian take the versionnumer from the bundles in where the libs exist - in our 
case it is KDE Applications and this is release every four months (15.08, 
15.12,...)
But everything can have its own version.
And the version of libkcalcore is 4.8X at the moment.

Also other applications do have different versions like marble and also got a 
bug https://bugs.debian.org/759422

But digikam can't relay on a version for libkcalcore > 5 because the ci 
build.kde.org would show red for that. 

I checked the source code (kipi plugins) and see the following CMakeLists.txt:
PRINT_OPTIONAL_LIBRARY_STATUS("libkcalcore" 
"https://projects.kde.org/projects/kde/pim/kcalcore;  "(version >= 
4.81.0)" "Kipi-plugins will be compiled without libkcalcore 
support." KF5CalendarCore_FOUND)

what is correct.

The bug is README.
libkcalcore >= 5.0.0

also Adrien pointed out in IRC that we got cmake happy with the 4.82 version. 
So it looks like only the README is incorrect about the version number.

Hope that helps clearifing this.

Regards,

sandro

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

Bug#808166: mobyle: deprecation of python-support

[Mattia Rizzolo]

Package: src:mobyle
Version: 1.5.3+dfsg-2
Severity: serious
Tags: patch sid stretch
User: debian-pyt...@lists.debian.org
Usertags: pysupport-deprecation

Dear Maintainer,

your package either depends on the python-support package.

python-support has been deprecated for some time (since 2011), and we're
currently in the process of removing it in favour of dh_python2.

Unfortunately your package went unnoticed till now, where we're on an
advanced state of the transition, with very few blocker, so I'm sorry
for the severity and the short notice of this bug report.

Attached there is a patch that is really enough to fix this, and I'd be
happy to do a minimal NMU of it.

Thanks!


-- 
regards,
Mattia Rizzolo

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

 changelog |8 
 control   |8 
 2 files changed, 12 insertions(+), 4 deletions(-)

diff -Nru mobyle-1.5.3+dfsg/debian/changelog mobyle-1.5.3+dfsg/debian/changelog
--- mobyle-1.5.3+dfsg/debian/changelog  2014-11-30 11:53:54.0 +
+++ mobyle-1.5.3+dfsg/debian/changelog  2015-12-16 17:45:57.0 +
@@ -1,3 +1,11 @@
+mobyle (1.5.3+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove dependency on python-support, and parametrize the python dependency
+with ${python:Depends}, Build-Dep on dh-python.
+
+ -- Mattia Rizzolo   Wed, 16 Dec 2015 17:40:19 +
+
 mobyle (1.5.3+dfsg-2) unstable; urgency=medium
 
   * d/control: set jing as Recommends, jing is not mandatory but only
diff -Nru mobyle-1.5.3+dfsg/debian/control mobyle-1.5.3+dfsg/debian/control
--- mobyle-1.5.3+dfsg/debian/control2014-11-30 11:53:47.0 +
+++ mobyle-1.5.3+dfsg/debian/control2015-12-16 17:45:44.0 +
@@ -8,15 +8,16 @@
  python-simplejson (>= 1.7.1),
  python-imaging (>= 1.1.5),
  python-lxml (>= 2.2.4),
- dh-apache2, apache2-dev
+ dh-apache2, apache2-dev, dh-python
 Standards-Version: 3.9.5
 Homepage: https://projets.pasteur.fr/projects/show/mobyle
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/mobyle/mobyle/trunk/
 Vcs-Svn: 
svn://anonsvn.debian.org/debian-med/trunk/packages/mobyle/mobyle/trunk/
+X-Python-Version: >= 2.5
 
 Package: mobyle
 Architecture: all
-Depends: ${misc:Depends}, python (>= 2.5), apache2 (>= 2.4) | httpd-cgi,
+Depends: ${misc:Depends}, ${python:Depends}, apache2 (>= 2.4) | httpd-cgi,
  libjs-scriptaculous, libjs-jquery, libjs-prototype,
  mobyle-utils,
  python-biopython,
@@ -26,7 +27,6 @@
  python-simplejson (>= 1.7.1),
  python-simpletal (>=4.1),
  python-simpletal (<< 5.0~),
- python-support (>= 0.90),
  squizz (>=0.99b+dfsg),
  ttf-bitstream-vera
 Suggests: python-openid (>= 2.2.4), python-dnspython (>= 1.5.0)
@@ -42,7 +42,7 @@
 
 Package: mobyle-utils
 Architecture: any
-Depends: ${misc:Depends},${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, ${python:Depends}
 Description: binary tools used by Mobyle
  Binary tools used by the Mobyle web portal to manage 
  jobs.


signature.asc
Description: PGP signature

Bug#807361: Must be a bug in digikam build system then.

[Eric Valette]

Will discuss with digikam author..

--eric

Bug#803292: wmaker is marked for autoremoval from testing

[Andreas Metzler]

On 2015-12-16 "Rodolfo García Peñas (kix)"  wrote:
> Andreas Metzler  escribió:

>> Rodolfo, do you want me to try to fix this with a NMU?

>> BTW I have seen that there is some packaging for 0.95.7 in upstream
>> GIT, is there a special treason why this has not appeared in Debian
>> yet?
>> 
>> cu Andreas

> Hi Andreas,

> I am very busy and I have no time to create the new package. Feel free to
> create a new NMU package, thanks a lot.

Thanks for quick heads-up, will do.

> If you want, change the maintainer to the wmaker team.

> About the 0.95.7, the upstream changes some things. The autoconf changes
> some files in the .orig.tar.gz files, so probably the debian/rules file
> should be changed or we need to create some debian/patches to solve this
> problem.

If I have time to spare I will have a look at it.

Best wishes

Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#808172: ITP: gitlab-workhorse -- unloads Git HTTP traffic from the GitLab Rails app (Unicorn)

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

package: wnpp
severity: wishlist
owner: Pirate Praveen 

https://gitlab.com/gitlab-org/gitlab-workhorse/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWca/2AAoJEM4fnGdFEsIq444P/04UdJWV/5TTFzh3KNRzLNjQ
kSSU8npkf6MTBzMiY/BTpi76A03XskafnyzaFR4KgxfDfq51Fw33qmuFgWPHimc7
A5U3a9zo8ISG73D8KvUnwT4eVdXmO9fYB/p949kUyGbkKzGWK+ChArOcssAu7mmn
hQDw8YB44MpV2Y8U5ZTQBnrkUa1w5wNmV3YVu8SeeIP9464ykEoCaRMp0vI22BXw
f1FUezQymQfDqWeVcrQvTQC979nppQqNHJhIOINEciKeq4edy93V9Ny6a4IDniQH
fzd/QFDQ7vhb4FhpD1fCUZ1CZgFDkeowK9TPshweoXHGG36HAxsWsFHEOi9beVPw
4+CTgVzkRPvA3BW45A7opCkDBbR3CLvUa91QNuGk/EtNokAzagQlTjx6op/fRgzO
f1222fJ+yjQBDk+NliMm7n+AAqiYQAX3akopd+HqwyDVWulzqvRobB0c44Zw/fJY
OafaBk0PAFRIsT8FRInO6jbfiEJq3KbCSaJQ3StXm4wJH093GJ4rQl5WcvO+wr1T
OvUrhlY+XBuD+g0lsKDiV6kWkVJ7/NtNHFboyCg/t5eo9wZwZMpqm0t6bN+MV/eX
mgkVBQfwwwWGnKEhS/bSzTXbZzE2FDE2vHK1DphJii163m1MtKABrrDGiPjHFKnk
nceddn5G2Q1LAHG8Tgha
=IqMb
-END PGP SIGNATURE-

Bug#808161: RM: gally -- RoQA; NPOASR; RC buggy; unmaintained; dead upstream; low popcon

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: ga...@packages.debian.org

Furthermore the binary from this package depends on python-support,
which is going away.

Thank you.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#808171: ITP: ruby-fog-xenserver -- Module for the 'fog' gem to support XENSERVER

[sudheesh shetty]

Package: fog-xenserverSeverity: wishlistOwner: Sudheesh Shetty
*Package Name : ruby-fog-xenserver Version :
0.2.2 Upstream Author : Paulo Henrique, Lopes Ribeiro*URL :
https://github.com/fog/fog-xenserver
*License : MIT*Description :
 This library can be used as a module for `fog` or as standalone
provider to use the XENSERVER in applications.

Bug#808162: [Pkg-utopia-maintainers] Bug#808162: NetworkManager does not allow remote management

[Michael Biebl]

Hi Marius!

Am 16.12.2015 um 18:18 schrieb Marius Vollmer:
> the NetworkManager polkit policy in Debian does not allow changing or
> adding connections from a remote session, such as a ssh or Cockpit
> login.
> 
> The default upstream policy explicitly allows this.  See
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1145646
> 
> for some discussion.
> 
> In the bug report above, the action that needed adjustement was
> "org.freedesktop.NetworkManager.network-control".  In Debian,
> "org.freedesktop.NetworkManager.settings.modify.system" would need to be
> allowed for "any".

I don't think we should allow
org.freedesktop.NetworkManager.settings.modify.system for everyone.

Why is auth_admin(_keep) not sufficient here?

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



signature.asc
Description: OpenPGP digital signature

Bug#808169: nast: FTBFS: Patch configure_updates_version_0.2.0-5.2 does not remove cleanly (refresh it or enforce with -f)

[Sven Joachim]

Source: nast
Version: 0.2.0-6
Severity: serious
Tags: stretch sid

The nast 0.2.0-6+1 binNMU failed on all architectures:

,
| Restoring ncurses/n_nast.h
| 
| Removing patch fix-hurd-build
| Restoring configure
| 
| Patch configure_updates_version_0.2.0-5.2 does not remove cleanly (refresh it 
or enforce with -f)
| /usr/share/quilt/quilt.make:23: recipe for target 'unpatch' failed
| make: *** [unpatch] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
`

This is due to these trailing lines in the offending patch:

,
| diff --git a/debian/changelog b/debian/changelog
| index b6a0be5..9a8fb45 100644
`

IIUC sbuild creates an extra entry debian/changelog entry for the binNMU
in the build directory, thus debian/changelog differs from the version
in the source package, causing the failure to unapply the (empty) hunk of
the patch.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-rc5-kms
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#808173: spu-tools: FTBFS: undefined reference to `get_ctx_sort_field'

[Sven Joachim]

Source: spu-tools
Version: 2.3.0.136-1
Severity: serious
Tags: stretch sid

The 2.3.0.136-1+b1 binNMU of spu-tools failed on both powerpc and ppc64:

,
| gcc -g -Wall -lncurses ctx-info.o spu-info.o proc-info.o general-info.o 
spu-top.o -o spu-top
| spu-top.o: In function `config_sort':
| /«PKGBUILDDIR»/src/spu-top.c:191: undefined reference to `get_ctx_sort_field'
| /«PKGBUILDDIR»/src/spu-top.c:192: undefined reference to `get_spu_sort_field'
| /«PKGBUILDDIR»/src/spu-top.c:193: undefined reference to `get_proc_sort_field'
| /«PKGBUILDDIR»/src/spu-top.c:210: undefined reference to `set_ctx_sort_field'
| /«PKGBUILDDIR»/src/spu-top.c:211: undefined reference to `set_spu_sort_field'
| /«PKGBUILDDIR»/src/spu-top.c:211: undefined reference to `set_proc_sort_field'
| collect2: error: ld returned 1 exit status
`

I haven't looked at this in detail, but it is probably due to changed
default inline semantics in gcc-5 (-std=gnu11 vs -std=gnu90).

Note that the package is orphaned[1], unless some powerpc user steps up
to fix the FTBFS bug I will probably turn [1] into an ROQA request since
spu-tools' popcon is _very_ low.


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739232

Bug#807578: /usr/bin/afl-clang-fast: strict dependency on clang version not declared

[Daniel Stender]

Thank you for reporting this.

I'm busy right now but this is going to be fixed soon. In the holidays.

Yes, that's a point. I'm going Dgit it.

DS

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

Bug#808174: jemalloc FTCBFS for {hur,kfreebs}d-i386 m68k sparc{,64}: mistakes build architecture for host architecture

[Helmut Grohne]

Source: jemalloc
Version: 3.6.0-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear jemalloc maintainer,

Even after fixing #807532, jemalloc still doesn't cross well for all
architectures. The reason for this is that the architecture-specific
quirks are misdetected.

debian/rules says e.g.:
| ifneq (,$(findstring $(DEB_BUILD_ARCH),sparc sparc64))
|   DEB_CPPFLAGS_MAINT_APPEND += -DLG_QUANTUM=4
| endif

What this means is that when I am building on a sparc box (for whatever
architecture), then add the cppflag. Conversely, when building for sparc
on an amd64, it doesn't add the flag and the build fails.

The intention behind all of these checks is to match the architecture
that is being built for, which is called host architecture and not build
architecture.

The fix is simple:

sed -i s/DEB_BUILD_/DEB_HOST_/g debian/rules

Helmut

Bug#807061: [Pkg-gambas-devel] Bug#807061: Bug#807061: gambas 3.8.0 needed! very deprecated gambas 3.6 in sid/jeesie

[José Luis Redrejo Rodríguez]

Hi Gianfranco, thanks for your help.
I am afraid I won't have time to work in the package until next Christmas
holidays. I will do it after December 25th, as I hope to have some free
time those days.
Any fix you can add in the meantime is welcome. If you can't I will do it
then.


Thanks
José L.

2015-12-16 16:10 GMT+01:00 Gianfranco Costamagna <
costamagnagianfra...@yahoo.it>:

> Hi Ian,
>
> I did update to 3.8.4 a few seconds ago, built and tested on a clean sid
> environment.
>
> I had to tweak the control file for the gsl library transition (changes
> pushed on git),
> closed this bug in changelog, and I also had to remove the qt4 stuff (I
> ran dpkg -i on all the
> built .deb files and it obviously failed because of the conflict)
>
> I also changed some duplicated build dependency, triggering some lintian
> warning.
>
> Since we have some RC bugs, and many many fixes in experimental (and the
> package isn't in testing right now)
> how do you feel about uploading on unstable?
>
> I can perform the upload if needed, just ask me.
>
> We have a really bad package right now in unstable, and we should fix it
> in my opinion.
>
>
> http://debomatic-amd64.debian.net/distribution#unstable/gambas3/3.8.4-1/buildlog
> a clean build is also ongoing there.
>
> (this will also fix the current lintian error against a bad PHP license)
>
> I can't promise the package will have a smooth upgrade path, because
> adequate doesn't perform well with it, also piuparts
> (at least the errors seems false positive).
>
> (but we can fix this later if needed)
>
> (I'll probably upload in deferred/15 to give maintainers time to react)
>
>
> cheers,
>
>
> G.
>
>
> Il Venerdì 4 Dicembre 2015 22:33, Ian Haywood  ha
> scritto:
> On Sat, Dec 5, 2015 at 6:05 AM, PICCORO McKAY Lenz
>
>  wrote:
> > Package: gambas3
> > Version: 3.6.2-1
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > please upgrade gambas to 3.8 in sid, due new components and
> > compatibility with documentation
> there is a working 3.8 version now in alioth git repo under the
> 'experimental' branch.
>
> ___
> Pkg-gambas-devel mailing list
> pkg-gambas-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gambas-devel

Bug#808163: googlefontdirectory-tools: deprecation of python-support

[Mattia Rizzolo]

Package: googlefontdirectory-tools
Version: 20120309.1-1
Severity: serious
Tags: patch sid stretch
User: debian-pyt...@lists.debian.org
Usertags: pysupport-deprecation

Dear Maintainer,

your package either depends on the python-support package.

python-support has been deprecated for some time (since 2011), and we're
currently in the process of removing it in favour of dh_python2.

Unfortunately your package went unnoticed till now, where we're on an
advanced state of the transition, with very few blocker, so I'm sorry
for the severity and the short notice of this bug report.

Attached there is a patch that is really enough to fix this, and I'd be
happy to do a minimal NMU of it.

Thanks!


-- 
regards,
Mattia Rizzolo

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

 changelog |7 +++
 control   |7 +++
 rules |2 +-
 3 files changed, 11 insertions(+), 5 deletions(-)

diff -Nru googlefontdirectory-tools-20120309.1/debian/changelog 
googlefontdirectory-tools-20120309.1/debian/changelog
--- googlefontdirectory-tools-20120309.1/debian/changelog   2012-03-14 
18:03:36.0 +
+++ googlefontdirectory-tools-20120309.1/debian/changelog   2015-12-16 
17:13:45.0 +
@@ -1,3 +1,10 @@
+googlefontdirectory-tools (20120309.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using dh-python instead of python-support.
+
+ -- Mattia Rizzolo   Wed, 16 Dec 2015 17:13:36 +
+
 googlefontdirectory-tools (20120309.1-1) unstable; urgency=low
 
   * New upstream release
diff -Nru googlefontdirectory-tools-20120309.1/debian/control 
googlefontdirectory-tools-20120309.1/debian/control
--- googlefontdirectory-tools-20120309.1/debian/control 2012-03-14 
16:30:30.0 +
+++ googlefontdirectory-tools-20120309.1/debian/control 2015-12-16 
17:13:19.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Fonts Task Force 
 Uploaders: Martin Erik Werner 
-Build-Depends: debhelper (>= 8)
+Build-Depends: debhelper (>= 8), python, dh-python
 Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/googlefontdirectory/
 Vcs-Git: git://git.debian.org/pkg-fonts/googlefontdirectory-tools.git
@@ -15,10 +15,9 @@
 Depends: fontforge-extras,
  fontforge-nox | fontforge,
  fonttools,
- python,
  python-fontforge,
- python-support (>= 0.90),
- ${misc:Depends}
+ ${misc:Depends},
+ ${python:Depends}
 Description: various tools for generating, analysing and manipulating font 
files
  This package contains a collection of tools used by the Google Font Directory
  to work with fonts.
diff -Nru googlefontdirectory-tools-20120309.1/debian/rules 
googlefontdirectory-tools-20120309.1/debian/rules
--- googlefontdirectory-tools-20120309.1/debian/rules   2012-03-14 
17:02:34.0 +
+++ googlefontdirectory-tools-20120309.1/debian/rules   2015-12-16 
17:13:33.0 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-   dh $@
+   dh $@ --with python2
 
 override_dh_install:
# Windows registry file and FontLab script is superfluous


signature.asc
Description: PGP signature

Bug#721298: boinc-client: Idle Detection Not Working Computer Always In Use

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy howdy,

I have a pull request with upstream now:

https://github.com/BOINC/boinc/pull/1453

And I've attached a patch against upstream's master as of this morning
(HEAD 1ca5f51cc7c993799f27d99bfa871d57567a30e5).

I'm not an autotools whiz, so I don't know if the changes I made to
configure.ac --mostly pulled from the commit that originally deleted
them, but I added a small flag when building the client so that the
original commit's checks are actually run-- are ideal, or if the
changes made are suitable for an automatic detection of new
dependencies. I'm starting to learn about package management a la
git-buildpackage, but I've got a ways to go.

Cheers,
Preston

P.S. - It looks like there's another bug from January 2015 that's
essentially a dupe of this one. Hopefully both can be closed soon :D

On 12/16/2015 01:16 AM, Gianfranco Costamagna wrote:
> Hi if you can give me a patch for the source code and submit a pull
> request upstream (github), I can find with git log the configure.ac
> patches, add the Debian dependencies again and reupload on
> unstable. Thanks G.
> 
> Sent from Yahoo Mail on Android
> 
> On Wed, 16 Dec, 2015 at 0:34, Preston
> Maness wrote:   -BEGIN PGP SIGNED
> MESSAGE- Hash: SHA512
> 
> An update:
> 
> Re-incorporating the XSS idle-detection code works as expected. I 
> scrapped the DPMS code and only kept the XSS code. Inclusion of
> 
> #include 
> 
> in "client/hostinfo_unix.cpp" ultimately pulls in a conflicting 
> definition of "Always" between X-related code and boinc's 
> "lib/prefs.h", fixed by renaming boinc's declaration. After this,
> the boinc-client and boincmgr compile and idle detection works as
> expected (keyboard and mouse inputs are appropriately detected, and
> computation is suspended).
> 
> Working on cleaning up the changes, hopefully getting upstream to 
> reinstate the XSS code, and determining how best to get the fix
> into the Debian packages. From what I can tell, an additional
> dependency on "libxss1" would be necessary.
> 
> Cheers, Preston
> 
> On 12/14/2015 07:28 AM, Preston Maness wrote:
>> Whelp, it looks like the X-based idle detection --with the 
>> XScreenSaver API?-- was removed in this commit:
>> 
>> ==
>> 
>> bfae1032e5c1ac73f2d8d92f93d8383a6cee
>> 
>> https://github.com/BOINC/boinc/commit/bfae1032e5c1ac73f2d8d92f93d
8
>
>> 
38
>> 
>> 
> 3a6cee
>> 
>> ==
>> 
>> The commit message indicates that /dev/input/* devices are the 
>> intended way to determine idle time on Linux now. However, it 
>> seems that X-based inputs don't update the /dev/input/* devices.
>> Or at least, anything the X server is doing isn't updating the
>> atime on those files, which is what is being utilized to
>> determine if the system is idle or not. Working in a terminal
>> updates the atime on the relevant files --correctly triggering
>> BOINC to suspend computation-- but just typing this email, or
>> wiggling the mouse around the desktop area, doesn't.
>> 
>> Granted, this code was present earlier, so I don't know if simply
>>  re-introducing it will solve anything. But that's my first plan
>> of attack. I've also looked into other varying methods of idle 
>> detection. The XSS API is the most common, but there is a more 
>> convoluted (asynchronous?) Xsync option that might also be
>> possible too. I don't know too much about X, but I'll be giving a
>> few different possibilities a go in the coming days.
>> 
>> Cheers, Preston
>> 
>> On 12/11/2015 09:44 AM, Preston Maness wrote:
>>> Howdy howdy,
>> 
>>> I think I deserve a slow clap for such a slow 
>>> response/addresssing of a bug. Indeed my response is so slow
>>> that I've since changed email address and GPG keys.
>> 
>>> Needless to say, when running BOINC 7.6.12 from testing, some 
>>> progress seems to have been made on idle detection. If I open a
>>>  terminal and begin working in it, *sometimes*, the idle
>>> detection kicks in. I can't tell whether it's working as
>>> intended or not. Regardless, keeping boinc running non-stop
>>> doesn't pose any issues thanks to the scheduling. I can happily
>>> use my machine for just about anything and not even notice that
>>> BOINC is running.
>> 
>>> I'm presently unemployed, so really, I have nothing but time
>>> and no real excuses not to give this bug another go and see if
>>> I can just determine once and for all if things are fixed/how
>>> to fix them :P
>> 
>>> It looks like the BOINC project has moved from their own git 
>>> infrastructure onto github:
>> 
>>> https://boinc.berkeley.edu/trac/wiki/SourceCodeGit
>> 
>>> https://github.com/BOINC/boinc
>> 
>>> Looking at the git log for hostinfo_unix.cpp (a la "git log 
>>> client/hostinfo_unix.cpp" from the project root), it looks like
>>>  there was a commit that included changes from Gianfranco:
>> 
>>> ==
>> 
>>> commit 0811886cbb1d282376e2dfd017ab39e34cd7d8ea Author: 

Bug#808091: osm-gps-map in NEW

[Ross Gammon]

Hi,

Osm-gps-map has now been uploaded and due to the change of package name,
is waiting in the NEW queue:
https://ftp-master.debian.org/new/osm-gps-map_1.1.0-1.html

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#808170: pulseaudio: Since pulseadio 5 speaker output is on headphones channel And randomly resets settings.

[Mark Caglienzi]

Package: pulseaudio
Version: 7.1-2
Severity: important

Dear Maintainer(s),
I have an HP Pavilion DV6-7009el with this soundcard:

IDT 92HD91BXX

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
Subsystem: Hewlett-Packard Company Device 1818
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at d461 (64-bit, non-prefetchable) [size=16K]
Capabilities: 
Kernel driver in use: snd_hda_intel

I am forced to continue to use Pulseaudio 4, because newer versions (also the 7
one) have this problem (which I found a nearly working (but annoying) 
workaround to):

* At boot, no audio
* I have to restart pulseaudio and launch alsamixer, choose the soundcard, max
out the headphone volume and unmute it (It is always muted and at 0%)

and NOW I have audio coming out my main laptop speakers (yes, it seems that
from Pulseaudio 5 the mixer level for main speakers is the headphone one).

Now if I plug headphones then the audio comes out only in the headphones and
not from the main speakers (good), but when I unplug them -> settings reset
(which seems to be good
because if I unplug my headphones I want their channel to mute, *but* this bug
gives me no audio on speakers, afterwards).

And sometimes when an application uses audio, the settings revert to mute and
0% headphone channel level -> no audio (so I have to re-do the drill)
For example VLC does not do this, pidgin sometimes does it and sometimes
freezes itself. QBittorrent playing audio through mpg123 triggers the settings
reset once again.


Kind regards,
Mark



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.0.29-1
ii  libasound2-plugins1.0.29-1
ii  libc6 2.19-22
ii  libcap2   1:2.24-12
ii  libdbus-1-3   1.10.4-1
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:5.2.1-23
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.2-1.11
ii  liborc-0.4-0  1:0.4.24-1
ii  libpulse0 7.1-2
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-10
ii  libsoxr0  0.1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.2.1-23
ii  libsystemd0   228-2
ii  libtdb1   1.3.8-1
ii  libudev1  228-2
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.3-1
ii  libx11-xcb1   2:1.6.3-1
ii  libxcb1   1.10-3+b1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  9.20150917
ii  pulseaudio-utils  7.1-2
ii  udev  228-2

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  7.1-2
ii  rtkit  0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter

-- no debconf information

-- 
. ''`.  | GPG Public Key  : 0xCD542422 - Download it from http://is.gd/fOa7Vm
: :'  : | GPG Fingerprint : 0823 A40D F31B 67A8 5621 AD32 E293 A2EB CD54 2422
`. `'`  | Powered by Debian GNU/Linux, http://www.debian.org
  `-| Try not. Do, or do not. There is no try. - Master Yoda, TESB.


signature.asc
Description: PGP signature

Bug#807237: thepeg: Update build dependencies for GSL 2.x

[Sebastiaan Couwenberg]

On 06-12-15 16:30, Bas Couwenberg wrote:
> Please note that rivet (#807224) needs to be updated for GSL 2,
> before thepeg can be rebuilt with GSL 2.
> 
> Having thepeg rebuilt with GSL 2 will unblock the rebuild for herwig++.

With the upload of rivet (1.8.3-1.3) to unstable two days ago, it no
longer blocks the update of thepeg for GSL 2.

Please update thepeg for GSL 2 to remove this blocker for the rebuild of
herwig++ (#805844) and the gsl transition (#804246).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#808160: ganglia-monitor-python: lots of modules missing (but available on github)

[Sandro Tosi]

Package: ganglia-monitor-python
Severity: important

Hello,
https://github.com/ganglia/gmond_python_modules contains a great amount of
modules, but most of them are no included in ganglia-monitor-python .

Please include those modules in the debian package.

Regards,
Sandro

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

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

Bug#808164: debian-maintainers: Add Ondřej Nový <n...@ondrej.org> as a Debian Maintainer

[Ondrej Novy]

Package: debian-maintainers
Severity: normal

Data:
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1

  mQINBFX25mMBEAC9NHGWvdZGzFJ85VLglbBRgqoaFMznC6Dz329M8Y+pVvPE/YY4
  rhX6FGxT3lOLY7mSpRf3PpRBrGf1Iz6IpM/ZBs2fFfL1uXqtJ++VkOG5ZRpTzVoy
  FloDndqxv6VpYjE2ljb0kxdyOkMPIRQHxRelQwHJyKZI01oG5vXr0Th8/1giPSTw
  J7m0h04yiweREuUr5Q1kBr1+Q1MgmErngVm1bKO/aJoWMW/aPA3Dp7kh5rGst7gp
  /wX7veH3K5KTaqM4NinGgCNhHJfaf4ANBjN4+Ot/cYehbPUDmdrI3gcz95DSS0N0
  R5YgpzFlyHxJ3FGyCrtbNro88Qxn5/JErevx3GDsvhsGBWrywF4VnFvoG8R5O7wZ
  Gpd44MpuYngouH2n4O7oDq2n/0hIi2BZsVBO8MRxEBJPZEOwkRIBD86NXjZrA6LB
  2dQeg/uTeNdPAkxhhxrA/nDgYILNVDIIMq91DpjQBPWp9OO+mHhcM0eeSJWfONdK
  1cT18kfVv0r7fOGtFJvJ46EQvlHMORYVHsFZhtOsHbbybSVQeqqf86YtO1wDw2pE
  jRdz369V3bMd76WsCx1g8p0PursJO5l2c7Mha8NzSRbM3yeKuP61L8JKHx1prp6o
  25UOMszRJaQoYheyduhc49KfnKLj8i9593KzpIfvMJpoSCBV+OV6AwowfQARAQAB
  tCtPbmTFmWVqIE5vdsO9IDxvbmRyZWoubm92eUBmaXJtYS5zZXpuYW0uY3o+iQI9
  BBMBCgAnBQJV9uahAhsDBQkHhh+ABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ
  EDVzElWdHgZLJWsP/R2GyljpWrB313ityh0/VWj04CJsLw0SSpfma6sQ0I61h6jP
  MySrIz8j+VqZmyG6Fd0l9rmTYp0/XtK6T5bTskUmr/8CMOQsEQhO4EI/k0qeo4jn
  6aIMz8osuuPXw88yCN2BNwtCZRDwxOfrc50Z+vU2cwLsF9csx0aUF0B1DF+sOUXo
  foOtEpbvgTfIeqH+F5BdKP4PRYM4GTYGPPvZ+bBaUlUsJhoBXl/E3th004zPwXXs
  3cXSYPdCHrJHPFxBKXYOpgI5RUPHTBvEsU6zOPcaplvphg9fYrcJ1+WMxyDK8WkX
  vUSHYx0AakK1wdxbIC2VPHwp7vbYixA7QLfk1PDqISWWOgUs6pKY2vwZIpYoTev/
  +eXBZ1KybM5FraYN9oSfzYtDvbMWWkG/7pzwcG30tdTkP8uhPKftFz4s0MGzGX3P
  1pXnbiVjTe26iZ57AgyzHxmGY1aAL+wU+220P5E92+RoeH0HVrBdHhGlhGEV9d1c
  QxqdvV9dgSpIONgJh9RqGGRWnIMuvT7TCQjDKaGLGZQ+/bhrMe4UREk6r1PvnlvF
  Lwbnjv06iRbnejs1sAv/+SHmH+ZDqAIpe48VEQBEA3uWKvOYnVW/nVN31yp9ebih
  mr3l2mjpjOiwbhvqobyeDNqN5T+CS+XQe3/XfMPWaiDDyIAqOZ3KJPPR4E5ViQEc
  BBABCAAGBQJWL3f7AAoJEKrS+5dcLflfsSsIAIV2xk0ugAWces0LkpPy50bRrmYQ
  1gwtnwHY9CMnfwybdBQLez5DWMt5wWujy7n+NlWt1brza4bIrjkqUkwhZei29HAM
  XbaV6zO/dyYobwvrWtW6ZZH7V9/X91DNdYFxW/iN1cd0tnay3ewNCAJCKC8/Qn+M
  Y7OjdVXS2qQsmc1MQ9wnOB19TVCy6PDUhLeiSMT0FvoA386Weq7O2Zn8cHoiYExE
  zlPB+IGRZzZKmuLQ292DL1FDR8DXjvoOb6W04ApugiTk9QgfpR5AMnVBHhUBDCyf
  8yTspWxnv1A3suesbw1HTH1VPiS9UYfc+IJ7QS1kGW5n2W72oC5JAeDAZ6OJAhwE
  EAEIAAYFAlY3M+IACgkQ1BatFaxrQ/4Y8w//cAcvYWL09J6Tn9/+Ynd/f0xjqNUW
  QMARMxtt93CPIP02qt2hDS7fARUlD59lp/igPidJRJf5fRTqmq1rQKr53NgLt3ie
  abaxvVpnwTaOPkJWTdEGibvyacaTx5HqexBAbVQFUTJ53tAkX28q+DDxsHDIovTH
  i2CWAz9gEACXseh6aMER6pCIgC+aBGEMTclrbY9y4Z38g+j7vIx+B+E6nEw1W/CK
  RcbfLloO4iG6hN+yn0dkL9dptDGuPxAugT8cM8p3bbWlHH7Va15QqLmtAvyoUCGq
  aCjk1Mk0ZrdimInAxI5cDVMGh3mvfCih7egyEVaWh/9qXAKZ4ZZvUcVEfh9TrDSi
  myd8MjJwLbKk+GLZHTSczZXvQObUjxagUwilmLjbzAxB2kVfZUMrMQpmISdjk9jD
  QkfPm2E1XxngwWGsw7KBsBamezOyUGW/mOsA2GVEkf7a+wvHGMQrJKHLPQ3QnlQn
  MURh8WcOLANcJPQp7A6wbtybbYdsDGV6ahRnZHfVjYaaVkqCl0TI/k2wjqxcs71c
  IzxjznlzjUfx+X3GrvwOson/4W0EDvob8mJPXsrtzPJYcSn2j5Kl01kH6HimboKt
  /2uiO7S5fO68Smje68W8PMBhgkBrDDNX16tnyfIa7flu3HXvSQCLDtQTVHcQ1tLa
  5U/hK3gBHEW/lK+0H09uZMWZZWogTm92w70gPG5vdnlAb25kcmVqLm9yZz6JAkAE
  EwEKACoCGwMFCQeGH4AFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAlX25qoCGQEA
  CgkQNXMSVZ0eBksvOw//S74/nw1SV4yFKXotiop7gcY+6dxvHcnnflDHVm1w6wai
  7JnEaKvooLYL/CargKDH5NU22w4lepOTD4Gzs+ApuhhqYNM++cHBmMzrv2cS+yuJ
  v6Ahec/seRmOH25MhgsAlLIWdrpQYja6RJACSXdJVBy/wvL+PsYM2vvOEkQCBnEv
  TNsKhAnjYKfciU6HqSwXhAjVH7tOCJJq4suaesjfw2pbdHbg7/pVi+H5PQ2LITpv
  Bwz2rLpU7Zl2x1MMzONkeb5xvBhVovv4Z7O97QQJbTxkro3xzEDg1HLphXLrauz+
  mt5IOgxQKumf4vj9P6Q/qKReKdOEB7StrRXSyjbvY4WBDIYZDsha+jXLk95PH8C7
  wivC9hB0WTttZWAQtrmOiwYFnZDBcSDONJHB6SEZNnWFnNt5GjZrsApt2B1ngEZK
  QWEblPHw9JyzBt8p0BP7hQWRkdHLkmjjdn7weOU+Vg61g9rIzOIGqHEMFSFD5tFx
  Z+ae5t/KKlBlMDh9h/yDxWP1VVFm/vfv5d2FPV46cKjJnjDPj+3E4f5HAwq0Rj9z
  fKwaOpzCCZvyXXnkk9ZU8knN3SAay1285f0Pmd12TIwrDe2ORSccb+hx2ufyiL0P
  4yeaMzk1N/oDdNycfPBRJCn+E2AzD9dumClEs8/m2jhZK7KRC4p3NZ5hAFHMDR2J
  ARwEEAEIAAYFAlYvd9sACgkQqtL7l1wt+V+zqgf/S9mQ0ThQC50IveYSzfES/L+w
  tvMn+/4XyRWgBfWf2gjKlWg4B3JFzK8TqOowx6kTVeA28qojqgEHhVMwXYXZ5+w2
  NpzfUszzqmi+BDFd4faCfQApPx6pdJlfjVAVSTTi/RtLqgfAWy6Fh01gqkrkHCJt
  886RBxSZQvdpWznicFTpVcmnWK9bunboNNYG4BDOK8Vxld+Z8gx/Ak7kaAT9o2/N
  QQKgVYxP4O/xAmrTsqeC3RO0ZHSHj7Q2JkUYLR3dalR/OGnMiJbvwEl8b6ld0g4w
  jEzb+NAu9ZxECJLxM3cwzIjfc61gTKXum3zG75qs8WgddWdbij6M363DzBusf4kC
  HAQQAQgABgUCVjcz4gAKCRDUFq0VrGtD/speD/9S1PFnv+CVFTl90/5LM0KgHPbt
  u5RU8CijPXfgG0sVuHu6UHmX7alv8OlQPs7nHZH6tUuJDKaT9wYNQsSbp4qQhB+i
  Wl7oSNBKBmKIjetM/mYgL5RFmdYM2+u+vr9c/iw1dyrq+xuUVBLpzHIQUN+Rdmzs
  f+MWkGRaMH4eithCuSGHgYhCnbouhHLCYejtCkyN3Fe7IbQhvBCO29SIvk4NRdwO
  nFUHJiHJBP7cCFZGSZ03dOAnJ7PX/jizYvL6RSnYeXFmj0m8z4t9q8lP4LYHfwIS
  SPynMZUuNFmMqUrekXoKcf21DbQ52ku8Lwt31vrrRD9lFKefIxdt/furupTJzvV6
  0VjNGMm2kkqmDlE90dx88R5KhEzdHKWC0CjMRrXFHuU2jSQifMhrLsb9gmQ79q15
  rw2ITIcGZ5K3549hFgJ4maYlZXyZOfcw8qLhb0b00ia6h1iWrBXu4lksRycyeYFP
  AgZBgtK4L+oGyAYnzXQVwnuyHfCatShY9cA43TkDi0uKRm8vc9XCbzPXqw7ScDjY
  H/O1SZViIxOXmee9pKWZ7WipD4D4y24utBLKO0qvHrora8Z+dmw8dCvsSYTdv6Af
  5Txgzo+xQBKeYJjTAOR/FNiArKnRhk+CZ5pCxKD2HWtX7q4P0T0c7/qN7k8jLtFX
  UCRHotnAFh6ktbldR7kCDQRV9uZjARAAqSfpgoyJefQfvRg/deF1BNZKc/c6Vc2E
  

Bug#808168: O: simplejson -- simple, fast, extensible JSON encoder/decoder for Python

[Federico Ceratto]

Package: wnpp
Severity: normal

Hello,
I intend to orphan the simplejson package. It's needed by TurboGears and I'm
not using such framework anymore.


The package description is:
 simplejson is a simple, fast, complete, correct and extensible JSON
  encoder and decoder.
 .
 The encoder may be subclassed to provide serialization in any kind of
 situation, without any special support by the objects to be serialized
 (somewhat like pickle).
 .
 The decoder can handle incoming JSON strings of any specified encoding
 (UTF-8 by default).
 .
 simplejson is the externally maintained development version of the json
 library included with Python 2.6 and Python 3.0, but maintains backwards
 compatibility with Python 2.5.

Bug#807392: libsendmail-milter-perl: FTBFS: Segmentation fault (core dumped)

[gregor herrmann]

On Tue, 08 Dec 2015 15:12:41 +0100, gregor herrmann wrote:

> > libsendmail-milter-perl fails to build from source in unstable/amd64:
[..]
> This builds fine for me (cowbuilder sid amd64):

Can anyone else reproduce or not reproduce this issue?
 
Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#808165: jsxgraph: deprecation of python-support

[Mattia Rizzolo]

Package: jsxgraph
Version: 0.98~dfsg1-3
Severity: serious
Tags: patch sid stretch
User: debian-pyt...@lists.debian.org
Usertags: pysupport-deprecation

Dear Maintainer,

your package either depends on the python-support package.

python-support has been deprecated for some time (since 2011), and we're
currently in the process of removing it in favour of dh_python2.

Unfortunately your package went unnoticed till now, where we're on an
advanced state of the transition, with very few blocker, so I'm sorry
for the severity and the short notice of this bug report.

Attached there is a patch that is really enough to fix this, and I'd be
happy to do a minimal NMU of it.

Thanks!


-- 
regards,
Mattia Rizzolo

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

 changelog |7 +++
 control   |5 ++---
 rules |2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff -Nru jsxgraph-0.98~dfsg1/debian/changelog 
jsxgraph-0.98~dfsg1/debian/changelog
--- jsxgraph-0.98~dfsg1/debian/changelog2014-01-13 17:56:20.0 
+
+++ jsxgraph-0.98~dfsg1/debian/changelog2015-12-16 17:27:23.0 
+
@@ -1,3 +1,10 @@
+jsxgraph (0.98~dfsg1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build using dh-python instead of python-support.
+
+ -- Mattia Rizzolo   Wed, 16 Dec 2015 17:27:12 +
+
 jsxgraph (0.98~dfsg1-3) unstable; urgency=low
 
   * added build-dependencies node-uglify and zip, thanks to 
diff -Nru jsxgraph-0.98~dfsg1/debian/control jsxgraph-0.98~dfsg1/debian/control
--- jsxgraph-0.98~dfsg1/debian/control  2014-01-13 17:56:28.0 +
+++ jsxgraph-0.98~dfsg1/debian/control  2015-12-16 17:26:21.0 +
@@ -4,14 +4,13 @@
 Maintainer: Georges Khaznadar 
 Build-Depends: debhelper (>= 7.0.50~), quilt
 Build-Depends-Indep: jsdoc-toolkit (>=2.4.0+dfsg-3), yui-compressor,
- node-almond, node-requirejs, node-uglify, zip
+ node-almond, node-requirejs, node-uglify, zip, python, dh-python
 Standards-Version: 3.9.5
 Homepage: http://jsxgraph.uni-bayreuth.de/cms/index.php
 
 Package: jsxgraph
 Architecture: all
-Depends: ${misc:Depends}, libjs-prototype, libjs-jquery,
- python-support (>= 0.90), python
+Depends: ${misc:Depends}, ${python:Depends}, libjs-prototype, libjs-jquery
 Suggests: jsxgraph-examples
 Description: Interactive Geometry with JavaScript
  JSXGraph is a cross-browser library to display interactive geometry in a
diff -Nru jsxgraph-0.98~dfsg1/debian/rules jsxgraph-0.98~dfsg1/debian/rules
--- jsxgraph-0.98~dfsg1/debian/rules2013-11-01 15:39:52.0 +
+++ jsxgraph-0.98~dfsg1/debian/rules2015-12-16 17:26:38.0 +
@@ -10,7 +10,7 @@
 #export DH_VERBOSE=1
 
 %:
-   dh $@ 
+   dh $@ --with python2
 
 get_latest_source:
debian/get-latest-source


signature.asc
Description: PGP signature

Bug#800496: evolution-ews: Unable to store Host URI / OAB URI

[Iain Lane]

Control: severity -1 important
Control: tags -1 + unreproducible

On Mon, Dec 14, 2015 at 10:34:36PM +0100, أبو المنتصر لدين اللّه wrote:
> Hi All,
> 
> On Sun, 15 Nov 2015 06:15:48 +0100 Michael Biebl  wrote:
> > On Wed, 30 Sep 2015 09:13:36 +0200 Yusuf Iskenderoglu
> >  wrote:
> > > Package: evolution-ews
> > > Version: 3.16.3-1
> > > Severity: grave
> > > Justification: renders package unusable
> > > 
> > > Dear Maintainer,
> > > 
> > > Currently, evolution cannot access EWS anymore and prevents me from using
> > > company mail.
> > > 
> > 
> > Hi, could you please try the latest version 3.18.0 from unstable and
> > report back with your findings.
> I was updating today my system and was surprised to see evolution-ews gowing 
> out
> of the repository if testing. I was using this plugin without any issue for 
> last
> few years.
> 
> Trying to look for the reason it was removed, I found this bug and consider 
> that
> it is unfair to prevent all testing users from this package because an old
> version is buggy. So I would propose that we tag this bug not in 3.18.0-1 and
> all above or lower this bug severity.

Right, can someone see if they can reproduce it? Otherwise I'm lowering
the severity here and e-ews will go back in.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Adrien Grellier]

Hi,

It seems that the lib version is 4.82, as we can see in the filename or in the 
CmakeLists.txt :
https://sources.debian.net/src/kcalcore/4:15.08.2-1/CMakeLists.txt/

In order to build digikam, I am afraid we will have to wait for a newer 
version of libkf5calendarcore.

Regards,

Adrien

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

Bug#808188: RM: ruby-vte -- NBS; no longer built by ruby-gnome2

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

ruby-gnome2 used to build these packages, but no longer does:

   ruby-vte ruby-vte-dbg ruby-vte3 ruby-vte3-dbg

For some reason those are not autoremoved, but I couldn't figure out
the reason.

Please remove those ruby-vte* packages from unstable at your earliest
convenience. I'd like them to go away to prepare removal of ruby2.1
from unstable.

Thanks,
Christian

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#808081: squeeze update of bind9?

[Michael Gilbert]

On Wed, Dec 16, 2015 at 3:22 PM, Raphael Hertzog wrote:
> Hello dear maintainer(s),
>
> the Debian LTS team would like to fix the security issues which are
> currently open in the Squeeze version of bind9:
> https://security-tracker.debian.org/tracker/CVE-2015-8000

As mentioned before, please go ahead with bind LTS updates without delay.

Best wishes,
Mike

Bug#808186: cinnamon: 100% CPU usage, no windows appear - after recent update in sid

[Norbert Preining]

gt; 1:4.2.9-5
[UPGRADE] fcitx-frontend-qt4:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-module-dbus:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-module-kimpanel:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-module-lua:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-module-quickphrase-editor:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-module-x11:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-modules:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-tools:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] fcitx-ui-classic:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] geoip-database:amd64 20151111-1 -> 20151216-1
[UPGRADE] geoip-database-extra:amd64 2015-1 -> 20151216-1
[UPGRADE] gir1.2-gdkpixbuf-2.0:amd64 2.32.2-1 -> 2.32.3-1
[UPGRADE] gir1.2-gst-plugins-base-1.0:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gir1.2-gstreamer-1.0:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gir1.2-nautilus-3.0:amd64 3.18.2-1 -> 3.18.3-1
[UPGRADE] grub-common:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] grub-efi:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] grub-efi-amd64:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] grub-efi-amd64-bin:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] grub-pc-bin:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] grub2-common:amd64 2.02~beta2-32 -> 2.02~beta2-33
[UPGRADE] gstreamer1.0-alsa:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-plugins-base:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-plugins-base:i386 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-plugins-base-apps:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-plugins-good:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-pulseaudio:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-tools:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] gstreamer1.0-x:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] iceweasel:amd64 38.4.0esr-1 -> 38.5.0esr-1
[UPGRADE] kbd:amd64 1.15.5-2 -> 2.0.3-1
[UPGRADE] libbusiness-isbn-data-perl:amd64 20140910.002-2 -> 20140910.003-1
[UPGRADE] libcroco3:amd64 0.6.9-1 -> 0.6.10-1
[UPGRADE] libcupsfilters-dev:amd64 1.3.0-1 -> 1.4.0-1
[UPGRADE] libcupsfilters1:amd64 1.3.0-1 -> 1.4.0-1
[UPGRADE] libfcitx-config4:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] libfcitx-core0:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] libfcitx-gclient0:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] libfcitx-qt0:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] libfcitx-utils0:amd64 1:4.2.9-4 -> 1:4.2.9-5
[UPGRADE] libfontembed1:amd64 1.3.0-1 -> 1.4.0-1
[UPGRADE] libgdal-dev:amd64 1.11.3+dfsg-2+b1 -> 1.11.3+dfsg-2+b2
[UPGRADE] libgdal1i:amd64 1.11.3+dfsg-2+b1 -> 1.11.3+dfsg-2+b2
[UPGRADE] libgdata-common:amd64 0.17.3-1 -> 0.17.4-1
[UPGRADE] libgdk-pixbuf2.0-0:amd64 2.32.2-1 -> 2.32.3-1
[UPGRADE] libgdk-pixbuf2.0-common:amd64 2.32.2-1 -> 2.32.3-1
[UPGRADE] libgdk-pixbuf2.0-dev:amd64 2.32.2-1 -> 2.32.3-1
[UPGRADE] libglibmm-2.4-1v5:amd64 2.46.2-1 -> 2.46.3-1
[UPGRADE] libgpg-error-dev:amd64 1.20-1 -> 1.21-1
[UPGRADE] libgpg-error0:amd64 1.20-1 -> 1.21-1
[UPGRADE] libgpg-error0:i386 1.20-1 -> 1.21-1
[UPGRADE] libgstreamer-plugins-base1.0-0:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] libgstreamer-plugins-base1.0-0:i386 1.6.1-1 -> 1.6.2-1
[UPGRADE] libgstreamer-plugins-base1.0-dev:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] libgstreamer1.0-0:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] libgstreamer1.0-0:i386 1.6.1-1 -> 1.6.2-1
[UPGRADE] libgstreamer1.0-dev:amd64 1.6.1-1 -> 1.6.2-1
[UPGRADE] liblept4:amd64 1.72-3 -> 1.72-3+b1
[UPGRADE] libmpfr-dev:amd64 3.1.3-1 -> 3.1.3-2
[UPGRADE] libmpfr4:amd64 3.1.3-1 -> 3.1.3-2
[UPGRADE] libnautilus-extension-dev:amd64 3.18.2-1 -> 3.18.3-1
[UPGRADE] libnautilus-extension1a:amd64 3.18.2-1 -> 3.18.3-1
[UPGRADE] libnghttp2-14:amd64 1.5.0-1 -> 1.5.0-2
[UPGRADE] libreoffice:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-avmedia-backend-gstreamer:amd64 1:5.0.4~rc1-1 -> 
1:5.0.4~rc2-2
[UPGRADE] libreoffice-base:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-base-core:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-base-drivers:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-calc:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-common:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-core:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-draw:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-help-en-us:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-impress:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-java-common:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-math:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-mysql-connector:amd64 1.0.2+LibO5.0.4~rc2-1 -> 
1.0.2+LibO5.0.4~rc2-2
[UPGRADE] libreoffice-pdfimport:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-report-builder-bin:amd64 1:5.0.4~rc1-1 -> 1:5.0.4~rc2-2
[UPGRADE] libreoffice-style-galaxy:amd64 1:5.0.4~rc1-1 -> 1:5.

Bug#808046: Bug not fixed

[grigor]

After upgrading chromium to 47.0.2526.80-3, I get the same error as in
47.0.2526.80-2:

[1:1:1217/004545:FATAL:chrome_main_delegate.cc(752)] Check failed:
!loaded_locale.empty(). Locale could not be found for
#0 0x5616eb7e52ae 
#1 0x5616eb7faab0 
#2 0x5616eb31a316 
#3 0x5616eb7b82ea 
#4 0x5616eb7b75da 
#5 0x5616eb319918 ChromeMain
#6 0x7f9ac3b69870 __libc_start_main
#7 0x5616eb3197b9 _start

Installing / deinstalling chromium-l10n (version 47.0.2526.80-3) does not
make any difference. Neither does deleting the chromium .config and .cache
directories.

System: pure stretch/sid, amd64.

If you need any other info, I will be glad to provide it.

Thank you for the attention,

Grigor

Bug#808182: general: realtek Hight definition audio not found

[lukash]

Package: general
Severity: normal

Dear Maintainer,

empty field in "Configure the Audio Volume > Input/output devices"



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/1 CPU core)
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#796551: CVE-2009-5147

[Christian Hofstaedtler]

Control: retitle -1 CVE-2015-7551

https://www.ruby-lang.org/en/news/2015/12/16/unsafe-tainted-string-usage-in-fiddle-and-dl-cve-2015-7551/

I don't think we want to fix this in the 2.2 branch, when we're
going to replace 2.2 with 2.3 ...

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: PGP signature

Bug#808189: html2wml: Depends on virtual package "perl5" which will is gone with perl/5.22

[Axel Beckert]

Package: html2wml
Version: 0.4.11-1
Severity: serious
Control: tags -1 + patch

Dear Werner,

the Perl 5.22 transition just started (see
https://lists.debian.org/debian-devel-announce/2015/12/msg5.html)
and we seem to have missed that html2wml depends on the deprecated
virtual package "perl5" like some other packages did.

The virtual package "perl5" is provided by the 5.20 perl package as
present in Debian Unstable until just now, but is no more be provided by
the 5.22 perl package which was just uploaded.

The following patch fixes this issue:

diff -u html2wml-0.4.11/debian/control html2wml-0.4.11/debian/control
--- html2wml-0.4.11/debian/control
+++ html2wml-0.4.11/debian/control
@@ -7,7 +7,7 @@
 
 Package: html2wml
 Architecture: all
-Depends: perl5, libhtml-parser-perl, liburi-perl, libwww-perl, 
libtext-template-perl
+Depends: perl, libhtml-parser-perl, liburi-perl, libwww-perl, 
libtext-template-perl
 Recommends: libxml-parser-perl, tidy, httpd | httpd-cgi
 Suggests: wap-wml-tools, iceweasel, wapua
 Description: converts HTML pages to WML (WAP) or i-mode pages

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (111, 'buildd-unstable'), 
(111, 'buildd-experimental'), (110, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores)
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 html2wml depends on:
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
ii  liburi-perl1.69-1
ii  libwww-perl6.15-1
ii  perl [perl5]   5.20.2-6

Versions of packages html2wml recommends:
pn  httpd | httpd-cgi   
ii  libxml-parser-perl  2.44-1
ii  tidy20091223cvs-1.5

Versions of packages html2wml suggests:
ii  iceweasel  38.5.0esr-1
ii  wap-wml-tools  0.0.4-7
ii  wapua  0.06.1-3

-- no debconf information

Bug#808186: cinnamon: 100% CPU usage, no windows appear - after recent update in sid

[Norbert Preining]

On Thu, 17 Dec 2015, Norbert Preining wrote:
> after having installed a set up updates of sid recently, suddendly
> I cannot log into cinnamon anymore. Logging in works, but then the
> CPU is 100% occupied by cinnamon, and the screen remains unchanged
> forever.

I have removed all folders regarding cinnamon (.local/share/cinnamon,
.cinnamon, .config/whatever) and after some more concoctions 
(renaming Desktop) I finally get a running cinnamon again.

No idea what had happened, but it was 100% reproducible, after warm
and cold boot as well as several login/log-out iterations.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#764301: Please provide a backport for Wheezy

[Jeff Breidenbach]

Time to admit it, I'm never  going to do this. Not opposed to someone else
making an attempt. Note that the next webp release is going to break ABI
compatibility.

Bug#808180: libc6: does not start qtcreator v3.5 and v3.6 "Segmentation fault."

[Samuel Thibault]

Hello,

lukash, on Wed 16 Dec 2015 23:49:47 +0300, wrote:
> (gdb) run
> Starting program: ~/Qt5.5.1/Tools/QtCreator/bin/qtcreator
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffec5cb700 (LWP 1282)]
> [New Thread 0x7fffd831b700 (LWP 1285)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77de72c6 in ?? () from /lib64/ld-linux-x86-64.so.2

Could you install libc6-dbg so we get much better feedback from gdb?

Thanks,
Samuel

Bug#805825: Please add some hints for hdf5

[Emilio Pozuelo Monfort]

On 08/12/15 17:12, Andreas Tille wrote:
> it would be great if you could add the hints for hdf5 to enable
> migration of netcdf and libsis-jhdf5-java to testing.

The strict dependencies in hdf5 libs prevent smooth transitions:

libhdf5-cpp-10 depends on libhdf5-10 (= 1.8.15-patch1+docs-5)
libhdf5-cpp-11 depends on libhdf5-10 (= 1.8.16+docs-1)

That means libhdf5-cpp-10 and libhdf5-cpp-11 can't coexist in testing, which
means no smooth update.

Now, I requested a decruft of the old libs from unstable, so the lot would
migrate if all the rdeps migrated as well at the same time. However, blasr
doesn't migrate because it has a new version which isn't built in a few arches.
I have opened a bug about that, and will remove it from testing in a few days if
there are no news, then hdf5 et al should go in.

@Gilles: loosing the libhdf5-cpp-11 dependency on libhdf5-10 would be nice to
avoid this in the future.

Cheers,
Emilio

Bug#807061: [Pkg-gambas-devel] Bug#807061: Bug#807061: gambas 3.8.0 needed! very deprecated gambas 3.6 in sid/jeesie

[Ian Haywood]

On Thu, Dec 17, 2015 at 6:04 AM, José Luis Redrejo Rodríguez
 wrote:
> Hi Gianfranco, thanks for your help.

> 2015-12-16 16:10 GMT+01:00 Gianfranco Costamagna
> :
>>
>> Hi Ian,
>>
>> I did update to 3.8.4 a few seconds ago, built and tested on a clean sid
>> environment.
>>
>> I had to tweak the control file for the gsl library transition (changes
>> pushed on git),
>> closed this bug in changelog, and I also had to remove the qt4 stuff (I
>> ran dpkg -i on all the
>> built .deb files and it obviously failed because of the conflict)
>>
>> I also changed some duplicated build dependency, triggering some lintian
>> warning.
The alternative is to patch the gambas runtime so it prefers qt5, this
allows qt4 and qt5 to co-exist.
However I'm not sure this matters: in Gambas there are absolutely no
API differences between qt4/qt5,
all you have to do is change the settings to use gb.gui.qt, which
people will have to do anyway to access WebView

We should keep the Conflicts however, so that when people upgrade
their old version of gambas3-gb-qt4
is deleted, otherwise total havoc will ensue.

>> Since we have some RC bugs, and many many fixes in experimental (and the
>> package isn't in testing right now)
>> how do you feel about uploading on unstable?
I think so, we can wait to see if anyone complains about the lack of qt4 ;-)

As an aside: what ever happened to the debian/patches directory and
the patches that were in there?

Ian

Bug#791300: tesseract: library transition may be needed when GCC 5 is the default

[Jeff Breidenbach]

Tesseact does need a soname bump as per bug #794489 irrespective
of GCC 5.

I haven't done it, partly due to lack of time, and partly because one of
the comments in that bug was demotivating.

Bug#786165: gbirthday: deprecation of python-support

[Jérôme]

Rolf, Mattia.

I just released v0.6.9 which includes the patch from Mattia.

Note you can drop the recommandation on evolution-data-server and
python-evolution since v0.6.8.

-- 
Jérôme

Bug#796344: CVE-2009-5147

[Christian Hofstaedtler]

Control: retitle -1 CVE-2015-7551
Control: found -1 2.1.5-2+deb8u2

https://www.ruby-lang.org/en/news/2015/12/16/unsafe-tainted-string-usage-in-fiddle-and-dl-cve-2015-7551/

Bug#808183: icedove: FTPFS on hurd-i386 and enable successive builds

[Svante Signell]

Source: icedove
Version: 38.4.0-1
Severity: important
Tags: patch
Usertags: hurd
User: debian-h...@lists.debian.org

Hi,

Currently icedove FTBFS on GNU/Hurd due to memory problems when linking large
libraries. The attached patch fixes this problem by giving the --no-keep-memory
flag to the linker as for alpha and ia64.

Additionally, since dh_clean does not enable building a second time after a
build failure, add an override target for sh_auto_clean:
override_dh_auto_clean:
make -f client.mk distclean--- a/debian/rules.orig	2015-11-27 18:55:34.0 +0100
+++ b/debian/rules	2015-12-16 14:58:00.0 +0100
@@ -35,6 +35,9 @@
 ifneq ($(DEB_BUILD_ARCH),alpha)
 	LDFLAGS += -Wl,--no-keep-memory
 endif
+ifneq ($(DEB_BUILD_ARCH),hurd-i386)
+	LDFLAGS += -Wl,--no-keep-memory
+endif
 # Also add execution time and memory usage stats in the logs
 LDFLAGS += -Wl,--stats
 
@@ -82,6 +85,9 @@
 	# building the stuff
 	make -f client.mk build
 
+override_dh_auto_clean:
+	make -f client.mk distclean
+
 override_dh_auto_install:
 	make -f client.mk install DESTDIR=$(CURDIR)/debian/tmp
 

Bug#808184: openal-soft: could build sndio support again

[Peter Piwowarski]

Source: openal-soft
Severity: wishlist
Tags: patch

Now that the "real" sndio implementation is packaged in Debian, openal
could build support for it again.

Playback works fine in my testing, but requires that sndio be specifically
enabled in alsoft.conf/.alsoftrc. I'm not sure if this should be documented
somewhere, or made more intuitive with a source patch.

diff --git a/debian/control b/debian/control
index e7a1f40..2247edc 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders: Bruno "Fuddl" Kleinert ,
Bret Curtis 
 Build-Depends: debhelper (>= 9),
libasound2-dev [linux-any],
-   cmake, portaudio19-dev, libpulse-dev,
+   cmake, portaudio19-dev, libpulse-dev, libsndio-dev
 Standards-Version: 3.9.6
 Section: libs
 Vcs-Git: git://anonscm.debian.org/pkg-games/openal-soft.git
diff --git a/debian/rules b/debian/rules
index bf0ff68..56fef4e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ DLOPENED_RECOMMENDS_LIBS = -lpulse
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 DLOPENED_RECOMMENDS_LIBS += -lasound
 endif
-DLOPENED_SUGGESTS_LIBS = -lportaudio
+DLOPENED_SUGGESTS_LIBS = -lportaudio -lsndio
 
 .PHONY: build
 %:

Bug#654938: [Aptitude-devel] Bug#654938: aptitude gets uncaught exception by keypress in search box

[Manuel A. Fernandez Montecelo]

2015-12-12 15:42 Götz Hoffart:

On Sat, 12 Dec 2015 15:17:10 + "Manuel A. Fernandez Montecelo" 
 wrote:

Control: tags -1 + unreproducible moreinfo help

Hi Goetz,

2012-01-06 23:02 Goetz Hoffart:
>Package: aptitude
>Version: 0.6.3-3.2+squeeze1
>Severity: normal
>
>
>When using 'aptitude' within an SSH session initiated within "iTerm.app"
>(Mac OS X program) and I press /^u ("/", "^", "u"), it crashes:
>
>Uncaught exception: Unable to read from stdin: Success
>
>If I press "/", "^", "Space", "u" instead all works fine. This crash only
>happens with iTerm, not with the standard Terminal.app.
>
>But keypresses of what kind ever shouldn't lead to an uncaught exception,
>IMO.

Thanks for the report.

Can you (or any other user with the same combination of tools) still
reproduce this with recent versions?


Yes. Still happens/crashed with the now newest OS X (10.11.2), newest iTerm 
(2.1.4) and both of aptitude of Debian 6.0.10 LTS _and_ aptitude of Debian 7.9. 
I can reproduce this, like described. No ‚screen‘ or ‚tmux‘ involved, but it 
crashes also within screen.


I wonder if it's something specific about that program, or locales.


If I can help with further details, please instruct me.


Hmm, thanks.  So can you please:

- install aptitude-dbg, libcwidget*-dbg, valgrind

- run inside valgrind (the same aptitude command, with "valgrind" in the
 beginning of the line)

- repeat the actions to crash

- paste the output of valgrind in this bug report


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#789986: pam: CVE-2015-3238: DoS/user enumeration due to blocking pipe in pam_unix module

[Tianon Gravi]

On Thu, 25 Jun 2015 22:33:21 +0200 Salvatore Bonaccorso
 wrote:
> CVE-2015-3238[0]:
> DoS/user enumeration due to blocking pipe in pam_unix module

Just a friendly ping; any movement towards fixing or at least
investigating this vuln?  This package is part of minbase, so IMO it
looks a little strange to have even something as low as a CVSS 5.8
still pending a maintainer response (even just a "naw, this isn't a
problem and won't be fixed").  Is it a matter of crafting a patch with
the upstream fix?  (I'm willing to try my hand at doing so if it'd be
helpful.)

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

Bug#796344: CVE-2009-5147

[Christian Hofstaedtler]

In 2.1 branch, the fix is in this commit:

https://github.com/ruby/ruby/commit/339e11a7f178312d937b7c95dd3115ce7236597a

Bug#808185: blasr: outdated binaries on several architectures

[Emilio Pozuelo Monfort]

Package: blasr
Version: 0~20151014+git8e668be-1
Severity: serious

Your package no longer builds on armhf, mips, mipsel, powerpc and s390x,
where it built in the past. That prevents testing migration.

The problem is that libblasr-dev, now built from pbseqlib, is not
available on those arches:

https://buildd.debian.org/status/package.php?p=pbseqlib=sid

So either that needs to be sorted out somehow, or the blasr binaries
need to be removed from those architectures.

Cheers,
Emilio

Bug#808181: libc6: Upgrade can make the linker unusable

[Aurelien Jarno]

On 2015-12-16 13:15, Dima Kogan wrote:
> Package: libc6
> Severity: normal
> 
> Hi. I had
> 
>   libc6= 2.19-22
>   binutils = 2.25-4
> 
> and all was well. Then I upgraded to libc6 = 2.21-4 (currently latest in
> sid). As a result, even the most basic build-time linking would fail.
> For instance, with a trivial hello-world program:
> 
>   $ gcc-5 -o tst tst.c
> 
>   /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: 
> unrecognized relocation (0x2a) in section `.init'
>   /usr/bin/ld: final link failed: Bad value
>   collect2: error: ld returned 1 exit status
> 
> This would happen with gcc-5 and with gcc-4.9. Downgrading libc6 would
> fix it. After some fiddling I realized that upgrading to binutils =
> 2.25.90.20151209-1 (currently latest in sid) fixes it. I.e. with the
> latest libc6 and the latest binutils packages things work.

The problem is not introduced by the glibc, but just by the fact that
it has been built with a recent binutils version which adds new
relocation types on i386 and amd64. This means that ALL static libraries
are affected by this problem.

> Can the broken combination be prevented with some Conflicts: tags?
> Currently this is a trap for the unwary.

I therefore don't think we need to fix that at the glibc level. Either
we just ignore the problem saying we don't support partial upgrades or
we try to find a global way to fix the dependencies for all libraries.

Aurelien

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

Bug#808187: lastpass-cli: new upstream version packaged

[Guy Hughes]

Package: lastpass-cli
Version: 0.7.0
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Troy,

Upstream tagged 0.7.0 in November and I have packaged it for debian
using gbp. [1] The tags are signed. And I have added a watch file.
Lintian reports clear. 

I'd be happy to support any effort to get this new version accepted into
the Debian archive.

Regards,

Guy Hughes

[1]: https://github.com/guyhughes/lastpass-cli-debian
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWcejdAAoJEP5VHtX/6ko8rxMP/29xMBpK7TnXDoV2XDZEoNlf
kWSjwb1uzpn4EkJd5h7z9+6wP3IlEbnay/2MhtXduMJ+QkIr99xKk3wdmz/X/VUd
mc2wpStDMnZeaQrik1RhAlxfic9ILi1XPplfdzApBAn375HosVlzWW4Yx7BrcQFM
AEFpyExPhWvFvRGoTkGhjnMqGIZe71oEDRv3eob3bQZu+NzwgcovTGWgyQcJSmIz
nG6JwPs6HR39vwUb99U1JTEOT1bFyATVp5H7dngiOEOZTxHf+91hQrkcY5Mf+N3g
/QkEyTSIG4HDGwhLtIssLJLqzGX/y07PURaPSEf5gFUdLDYm6oGLg0HRuW24IvAI
kZIUQMKmYW+RyYqk+xEFVJvKkzPO+UkFhWYdk6r8zZTCbTqpwTXLlusQWYIUoOzN
HlgToXl74GTlCunn3N9aaMPs3OzTmp49QwKwpmi2iXhzFQkn8+r50jg6QawVEQBC
HhMTuqMoPvaT4CVZX/n44Wmqdomw1kkoiqEltj3Z3L9PE/lSPj8gCE4oSoKzy9j8
Se4hW33P8xEQaYWHVJsC4sfKcPcn/eGLIdgSTY61CoGg2RsLp3moBBxhoxBMUkAs
T8E52DEmSUKE/S5wXl7Z5K6wMzR8rwPLDmazv0f9HSEGMPKtoxkZVtJXpDq1GKCH
jUzMnG7il5La3I/CA8Hn
=+cY1
-END PGP SIGNATURE-

Bug#808152: ITP: pixelmed-codec -- some imaging codices for pixelmed DICOM image and ECG viewer

[Adam D. Barratt]

On Wed, 2015-12-16 at 16:18 +0100, Andreas Tille wrote:
>   Description : some imaging codices for pixelmed DICOM image and ECG 
> viewer

"Codices" is the plural of "codex"; you're looking for "codecs".

Regards,

Adam

Bug#807604: Not a VLC bug but a radeon one.

[Lisandro Damián Nicanor Pérez Meyer]

reassign 807604 xserver-xorg-video-radeon
thanks

The bug was not in VLC itself, so I'm reassign it.

X maintainers: the bug is the radeon driver crashing when VLC
is pointed to a specific stream, present in the original bug report.

Please do not heasitate to ask for more details as you see suitable.
I'll ad more info in a couple of minutes.

[ 1976.421686] [drm:cypress_dpm_set_power_state [radeon]] *ERROR* 
rv770_restrict_performance_levels_before_switch failed
[ 1986.592063] radeon :01:00.0: ring 5 stalled for more than 1msec
[ 1986.592079] radeon :01:00.0: GPU lockup (current fence id 
0x0002 last fence id 0x0008 on ring 5)
[ 1987.092053] radeon :01:00.0: ring 0 stalled for more than 10124msec
[ 1987.092069] radeon :01:00.0: GPU lockup (current fence id 
0x0003173b last fence id 0x00031744 on ring 0)
[ 1987.092080] radeon :01:00.0: ring 5 stalled for more than 10500msec
[ 1987.092086] radeon :01:00.0: GPU lockup (current fence id 
0x0002 last fence id 0x0008 on ring 5)
[ 1987.380171] [drm:rv770_stop_dpm [radeon]] *ERROR* Could not force DPM to low.
[ 1987.387114] radeon :01:00.0: couldn't schedule ib
[ 1987.387114] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD 
(-22)! 
[ 1987.389279] radeon :01:00.0: Saved 311 dwords of commands on ring 0.
[ 1987.389294] radeon :01:00.0: GPU softreset: 0x0088
[ 1987.389297] radeon :01:00.0:   GRBM_STATUS   = 0xA0003828
[ 1987.389299] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0007
[ 1987.389302] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[ 1987.389304] radeon :01:00.0:   SRBM_STATUS   = 0x20084AC0
[ 1987.389307] radeon :01:00.0:   SRBM_STATUS2  = 0x
[ 1987.389309] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 1987.389312] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x0001
[ 1987.389314] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x0002
[ 1987.389317] radeon :01:00.0:   R_008680_CP_STAT  = 0x80010243
[ 1987.389320] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 1987.406730] radeon :01:00.0: GRBM_SOFT_RESET=0x4001
[ 1987.406784] radeon :01:00.0: SRBM_SOFT_RESET=0x8100
[ 1987.407930] radeon :01:00.0:   GRBM_STATUS   = 0x3828
[ 1987.407933] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0007
[ 1987.407935] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0007
[ 1987.407938] radeon :01:00.0:   SRBM_STATUS   = 0x200800C0
[ 1987.407940] radeon :01:00.0:   SRBM_STATUS2  = 0x
[ 1987.407943] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 1987.407945] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[ 1987.407948] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[ 1987.407951] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[ 1987.407953] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 1987.407968] radeon :01:00.0: GPU reset succeeded, trying to resume
[ 1987.428909] [drm] PCIE GART of 1024M enabled (table at 0x0025E000).
[ 1987.428986] radeon :01:00.0: WB enabled
[ 1987.428990] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x2c00 and cpu addr 0x8800bb3c9c00
[ 1987.428992] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x2c0c and cpu addr 0x8800bb3c9c0c
[ 1987.429964] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x0005c418 and cpu addr 0xc9c1c418
[ 1987.445975] [drm] ring test on 0 succeeded in 1 usecs
[ 1987.445981] [drm] ring test on 3 succeeded in 2 usecs
[ 1987.641630] [drm] ring test on 5 succeeded in 1 usecs
[ 1987.641641] [drm] UVD initialized successfully.


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


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

Bug#796798: perl: FTBFS on kfreebsd-*: t/op/stat.t failure

[Steven Chamberlain]

Control: tags -1 + patch

Hi,

Sorry I didn't reply on this thread sooner.

Niko Tyni wrote:
> > On Mon, Aug 24, 2015 at 07:15:19PM +0300, Niko Tyni wrote:
> > >   t/op/stat . FAILED 
> > > at test 9
> 
> > > I see the buildds are now running kernel 10.1-0 while the earlier
> > > builds were on 9.0-2.
> > > 
> > > @buildd admins: any ideas? Are there known issues with ctime in
> > > /tmp on the buildds?

It could have been a configuration change on the buildds (maybe
softupdates are enabled now?) or otherwise a kernel code change in ufs,
nullfs (used for bind mounts) or vfs (file I/O more generally).

Looking at it more closely, the testcase is essentially:

  echo stuff > foo  # we expect mtime == ctime
  sleep 2
  ln foo bar# this should update ctime of foo
  stat foo  # we expect mtime != ctime

If I merely stat() the file before the sleep - that fixes it - this is
actually a heisenbug!

The problem is with mtime.  It seems to be not calculated immediately,
but deferred until the next stat, after the hard link is created, such
that mtime=ctime and so the test fails.  A stat() right before the
sleep, or a much longer sleep (~30s), causes mtime to be calculated
earlier and so fixes it.

It's obviously a kernel behaviour, its unclear if it's a bug (it may be
an expected quirk of softupdates), and in any case definitely not a Perl
bug.  Might we please add a stat() to work around it, as attached;  that
would allow the test to still run, and still return a meaningful result
rather than skipping/ignoring the test on kfreebsd.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From: Steven Chamberlain 
Date: Thu, 17 Dec 2015 02:15:58 +
Subject: Work around Debian Bug#796798

kFreeBSD 10 (possibly only with softupdates enabled) may defer
calculating the mtime for more than 2 seconds.  Work around this
with a stat() call to calculate the mtime immediately.

--- a/t/op/stat.t
+++ b/t/op/stat.t
@@ -96,6 +96,7 @@
 print FOO "Now is the time for all good men to come to.\n";
 close(FOO);
 
+stat($tmpfile);	# Work around Debian Bug#796798
 sleep 2;
 
 my $has_link = 1;


signature.asc
Description: Digital signature

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

[Paul Wise]

On Sat, Dec 12, 2015 at 10:40 PM, Stefan Ahlers wrote:

> How can I handle the lintian error message "source-is-missing"?
> I'm unable to find the source code of this JavaScript files in the internet.

data/js/cryptojs**.js are already in the archive as libjs-cryptojs.

data/www/js/html5shim.js isn't packaged yet, it needs to be packaged
from here, unfortunately the build-dependencies for it aren't yet
packaged.

https://github.com/afarkas/html5shiv

> Do I have to cleanup the source code and remove all windows/mac related files?

It isn't nessecary to remove files related to other platforms unless
they are not DFSG-free (don't have source code, non-free licenses
etc).

> Because of the complexity of the software and the package, I decide to ask 
> for a revision now.

I don't intend to sponsor it, but here is my incomplete review:

If I were interested in sponsoring it, these things would block my upload:

I'm assuming the GMail, itunes, echonest, beats, soundcloud, spotify
and maybe playdar logos are not under a free license.

I would suggest removing the whole thirdparty/ directory (using
Files-Excluded in debian/copyright and repacksuffix in debian/watch)
and packaging each dependency separately. Same goes for the other
embedded copies in these files, some of them are already packaged,
others are not. This would be best done upstream but generally
upstreams are hostile to removing embedded code copies so it might not
be wise to ask about this.

data/www/js/html5shim.js
data/www/css/font-awesome.css
data/www/css/bootstrap.css
data/www/css/animate.css
data/js/cryptojs/
data/js/cryptojs-core.js
data/fonts/

https://wiki.debian.org/UscanEnhancements
https://wiki.debian.org/EmbeddedCodeCopies

These things would be nice to fix:

debian/repack.* can be replaced with Files-Excluded in
debian/copyright and repacksuffix in debian/watch.

https://wiki.debian.org/UscanEnhancements

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

It would be nice to build the PNG files in data/icons from the SVG
file at build time.

Automated checks:

lintian

P: tomahawk-player source: source-contains-prebuilt-javascript-object
data/js/cryptojs-core.js line length is 761 characters (>512)
E: tomahawk-player source: source-is-missing data/js/cryptojs-core.js

P: tomahawk-player source: source-contains-prebuilt-windows-binary
admin/win/nsi/nsis_processes/bin/Processes.dll
P: tomahawk-player source:
source-contains-autogenerated-visual-c++-file
admin/win/nsi/nsis_processes/src/processes.rc
P: tomahawk-player source:
source-contains-autogenerated-visual-c++-file
admin/win/nsi/nsis_processes/src/resource.h
P: tomahawk-player source: source-contains-prebuilt-windows-binary
admin/win/nsi/nsis_uac/Release/A/UAC.dll
P: tomahawk-player source: source-contains-prebuilt-windows-binary
admin/win/nsi/nsis_uac/Release/U/UAC.dll
P: tomahawk-player source: debian-watch-may-check-gpg-signature

check-all-the-things

# bashate produces style warnings only, can be ignored
$ find -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate
--ignore E002,E003 {} +
E011: Then keyword is not on same line as if or elif keyword: 'if [ -z "$1" ]'
 - ./admin/mac/create-dmg.sh : L16
E011: Then keyword is not on same line as if or elif keyword: 'if [ -z "$2" ]'
 - ./admin/mac/build-release-osx.sh : L21
E011: Then keyword is not on same line as if or elif keyword: 'if
[ -f ~/sign_step.sh ];'
 - ./admin/mac/build-release-osx.sh : L50
E011: Then keyword is not on same line as if or elif keyword: 'if [ -e
"$schema" -a -n "$name" ]'
 - ./src/libtomahawk/database/gen_schema.h.sh : L9
4 bashate error(s) found

# Check with upstream where the Inkscape SVG source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg'
-o -iname '*.jpeg' \) -exec grep -iF inkscape {} +
Binary file ./src/libtomahawk/accounts/configstorage/telepathy/kde.png matches

$ find -type f -iname '*.sh' -exec checkbashisms {} +
could not find any possible bashisms in bash script ./admin/gen_resources.sh
could not find any possible bashisms in bash script ./admin/win/update-vlc.sh
could not find any possible bashisms in bash script
./src/libtomahawk/database/gen_schema.h.sh

$ cme check dpkg
...
Warning in 'copyright Format' value
'http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=markup=174':
Format does not match the recommended URL for DEP-5

$ codespell --quiet-level=3
./admin/win/nsi/nsis_uac/RunAs.cpp:268: dont  ==> don't
./admin/win/nsi/nsis_uac/UAC_Uninstaller.nsi:46: aswell  ==> as well
./admin/win/nsi/nsis_processes/readme.txt:109: powerfull  ==> powerful
./admin/win/nsi/nsis_processes/src/processes.txt:109: powerfull  ==> powerful
...
./data/js/tomahawk.js:305: occured  ==> occurred
./CMakeModules/FindLibAttica.cmake:42: everytime  ==> every time
./thirdparty/qt-certificate-addon/src/certificate/certificaterequestbuilder.cpp:116:
reqest  ==> request
./thirdparty/libportfwd/src/portfwd.cpp:151: adress  ==> address

Bug#808197: diffoscope: readelf --debug-dump can be brutal

[Mike Hommey]

Source: diffoscope
Version: 43
Severity: wishlist

Dear Maintainer,

When comparing the debug symbol files for Firefox, which are rather massive,
the output for readelf --debug-dump is 1.7GB compressed. Diff can't handle
with that much data without OOM'ing.

However, if each debug section was compared individually, that give more
chance for diffoscope to work. (--debug-dump takes values allowing to treat
each debug section independently)


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

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

Bug#808003: [Reproducible-builds] Bug#808003: diffoscope: Comparing directories shouldn't care about file order

[Mike Hommey]

On Tue, Dec 15, 2015 at 11:07:24AM +0100, Holger Levsen wrote:
> Hi Mike,
> 
> thanks for the bug report!
> 
> On Dienstag, 15. Dezember 2015, Mike Hommey wrote:
> >* What was the outcome of this action?
> > The output contained differences in the output for find due to
> > filesystem-dependent behavior wrt file ordering in readdir(3).
> > 
> >* What outcome did you expect instead?
> > The sorted list should be compared instead.
> 
> I think it would be fine if there was an option to force such a behaviour, 
> but 
> I think the default should be not to do that. diffoscope should show (all) 
> differences, not hide some, to make some others more visibe… at least not by 
> default.
> 
> IOW: if your "container" (the filesystem) is underministic, diffoscope should 
> not try to hide this (by default).

The tricky thing is that it's not necessarily desirable that all
containers be treated equal during one run.

To give an actual example, I'm comparing Firefox builds that I get out
of Mozilla automation. They come in the form of a tar.bz2. Unpacked or
not, I don't actually care about the file order in them. However, I *do*
care about the file order in omni.ja and *.xpi files that are inside of
it.

So a global option that treats all containers equal would not work
for my use-case.

That being said, I would care less about the `find {} -printf %P` diff
if there were other indicators that files are missing in one of the
containers. Currently, that information is essentially hidden by the
fact that the containers are not ordered the same.

Mike

Bug#808199: diffoscope: Weird line numbering in diff output

[Mike Hommey]

Source: diffoscope
Version: 43
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Comparing
https://queue.taskcluster.net/v1/task/FEXzanIjQKW_dBmv3ZmBJQ/runs/0/artifacts/public/build/target.tar.bz2
with
https://queue.taskcluster.net/v1/task/HqZ2DuHYRJ6kR2_P8Rc7Ig/runs/0/artifacts/public/build/target.tar.bz2

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

`diffoscope --html out.html target.tar.bz2 target.tar.bz2.1`

   * What was the outcome of this action?

The HTML output line numbering on the diff is weird. Specifically, it looks
like (simplified):

1 firefox/1 firefox/
2 firefox/libnssdbm3.chk  2 firefox/browser/
3 firefox/libfreebl3.chk  3 firefox/browser/omni.ja
4 firefox/libnssdbm3.so   4 firefox/browser/extensions/
5 firefox/crashreporter   5 
firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
6 firefox/libnss3.so  6
7 firefox/firefox-bin 7
...   ...

Lines 1 to 5 are yellow, 6 and 7 red.

The weird thing about the numbering is that there are numbers on the right hand
side for lines that were removed. Interestingly, there is no number for line
72, which is also a removed line.

The same problem shows up for added lines.

   * What outcome did you expect instead?

No numbers for added/removed lines in the part where there were no lines
originally



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

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

Bug#808199: diffoscope: Weird line numbering in diff output

[Mike Hommey]

On Thu, Dec 17, 2015 at 03:03:21PM +0900, Mike Hommey wrote:
> However, there's another issue, that the diff is actually incomplete:
> the right hand side stops 3 lines too early.
> 
> (The patch is not actually changing anything here, I just figured
> once the numbers looked normal, but didn't match)

This comes from the cutoff from --max-diff-block-lines (defaulting to
50), that doesn't add a [ n lines added ] line.

Mike

Bug#808152: ITP: pixelmed-codec -- some imaging codices for pixelmed DICOM image and ECG viewer

[Andreas Tille]

On Wed, Dec 16, 2015 at 10:46:44PM +, Adam D. Barratt wrote:
> On Wed, 2015-12-16 at 16:18 +0100, Andreas Tille wrote:
> >   Description : some imaging codices for pixelmed DICOM image and ECG 
> > viewer
> 
> "Codices" is the plural of "codex"; you're looking for "codecs".

Thanks, changed in SVN

  Andreas. 

-- 
http://fam-tille.de

Bug#808093: gnome-panel: text color is the same of background

[Sandro Tosi]

using gnome-tweak-tool to set the global dark theme helped (see
attachment) but now it's grey, while I'd rather it to be black, do you
know how to change that value (and maybe also how to make the text in
bold)? trying to find information about themes in gnome-fallback is so
hard, as most of the articles are about gnome-shell :/

and funnily enough, the login-after-lock-screen env has a nice black
bar, with test in white and bold (but cant take a screenshot for
obvious reason), that's what I want :)

Thanks for your help!

On Wed, Dec 16, 2015 at 8:38 PM, Sandro Tosi  wrote:
> On Wed, Dec 16, 2015 at 12:01 PM, Dmitry Shachnev  wrote:
>> Control: tags -1 moreinfo unreproducible
>
> but the you say you can reproduce it :)
>
>> On Tue, Dec 15, 2015 at 11:22:43PM +, Sandro Tosi wrote:
>>> Package: gnome-panel
>>> Version: 3.18.1-1
>>> Severity: important
>>>
>>> Hello,
>>> I'm attaching some screenshots to show how the text and the background are 
>>> the
>>> same color (basically masking all teh text) in the app bar (if the 
>>> application
>>> does no have the focus or in background) and also in the upper bar, where
>>> 'Applications', 'Places', the central time panel and the last menu on the 
>>> right
>>> all are dark-on-dark, but when selected the right 
>>> dark-text/light-background is
>>> used.
>>>
>>> That's severely impacting the usability of the desktop; I'm using 
>>> gnome-fallback
>>> with the default theme (adwaita).
>>
>> I get exactly the same behaviour as in your screenshots when I set the panel
>> color manually to black.
>>
>> Can you please open the panel preferences (Alt + right click on the panel →
>> Properties → Background) and make sure that it is set to use colors from 
>> system
>> theme, not custom colors?
>
> that worked, but now I got a "light" panel (attached), while what I
> like to have is a dark panel and a light-colored text
>
> --
> Sandro "morph" Tosi
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi



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

Bug#782024: cryptsetup: [patch] fix remote unlock of encrypted root when plymouth is installed

[Richard Hansen]

This is the script I use to remotely unlock an encrypted root filesystem
on my Ubuntu machines:

https://github.com/rhansen/unlock-cryptroot

It should work on Debian, though I have not tested it.

It does not require any modifications to the target system's initramfs,
and works even if plymouth is installed.

-Richard

Bug#808198: markdown-calibre: ImportError: No module named markdown.__main__

[Felix Dietrich]

Package: calibre
Version: 2.45.0+dfsg-1
Severity: important
Tags: patch


Invocating markdown-calibre fails with an ImportError:

  Traceback (most recent call last):
File "/usr/bin/markdown-calibre", line 19, in 
  from calibre.ebooks.markdown.__main__ import run
  ImportError: No module named markdown.__main__

this happens because the command fixing the import statements for
calibre.ebooks.markdown in debian/rules:

  find debian/tmp/ -name '*.py' | xargs sed -i 
's/calibre.ebooks.markdown/markdown/g'

only affects files having a .py extension which the executable
/usr/bin/markdown-calibre does not have so that markdown-calibre
continues to be included in the package with the wrong import statement.

In case markdown-calibre should continue to be part of the calibre
package (it does not appear to do more than /usr/bin/markdown_py from
the python-markdown package) I created an updated
use_system_markdown.patch file that I appended.

Alternatively one could adjust the aforementioned find command in
debian/rules to also list the markdown-calibre file:

  find debian/tmp -name "*.py" -or -name "markdown-calibre" | ...


I do not know which is to be preferred and am wondering: is there a
reason to motify the imports both via a patch file and by using sed in
debian/rules?


Another option might be to remove the calibre-markdown executable – if
it in fact does the same thing as markdown_py from python-markdown –
from the package as I did not find invocations of markdown-calibre in
the source using grep (grep -r markdown-calibre .).


--
Felix Dietrich


Author: Dmitry Shachnev 
Description: use system python-markdown
Forwarded: not-needed
Last-Update: 2013-04-04

Index: calibre-2.45.0+dfsg/src/calibre/library/comments.py
===
--- calibre-2.45.0+dfsg.orig/src/calibre/library/comments.py
+++ calibre-2.45.0+dfsg/src/calibre/library/comments.py
@@ -150,7 +150,7 @@ def sanitize_html(html):
 return serializer.render(stream)
 
 def sanitize_comments_html(html):
-from calibre.ebooks.markdown import Markdown
+from markdown import Markdown
 text = html2text(html)
 md = Markdown()
 html = md.convert(text)
Index: calibre-2.45.0+dfsg/src/calibre/linux.py
===
--- calibre-2.45.0+dfsg.orig/src/calibre/linux.py
+++ calibre-2.45.0+dfsg/src/calibre/linux.py
@@ -20,7 +20,7 @@ entry_points = {
  'ebook-meta = calibre.ebooks.metadata.cli:main',
  'ebook-convert  = calibre.ebooks.conversion.cli:main',
  'ebook-polish   = calibre.ebooks.oeb.polish.main:main',
- 'markdown-calibre   = calibre.ebooks.markdown.__main__:run',
+ 'markdown-calibre   = markdown.__main__:run',
  'web2disk   = calibre.web.fetch.simple:main',
  'calibre-server = calibre.library.server.main:main',
  'lrf2lrs= calibre.ebooks.lrf.lrfparser:main',

Bug#808199: diffoscope: Weird line numbering in diff output

[Mike Hommey]

Attached here is two files that can be compared directly, exposing the
same problem. That's essentially the output of tar --full-time -tvf on
both tarballs from the original bug report.

The following patch fixes the numbering issue:

diff --git a/diffoscope/presenters/html.py b/diffoscope/presenters/html.py
index f425889..315a639 100644
--- a/diffoscope/presenters/html.py
+++ b/diffoscope/presenters/html.py
@@ -346,7 +346,7 @@ def output_line(print_func, s1, s2):
 
 print_func(u'' % type_name)
 try:
-if s1 is not None:
+if s1:
 print_func(u'%d ' % line1)
 print_func(u'')
 print_func(convert(s1, ponct=1, tag='del'))
@@ -355,7 +355,7 @@ def output_line(print_func, s1, s2):
 s1 = ""
 print_func(u'')
 
-if s2 is not None:
+if s2:
 print_func(u'%d ' % line2)
 print_func(u'')
 print_func(convert(s2, ponct=1, tag='ins'))
@@ -369,12 +369,12 @@ def output_line(print_func, s1, s2):
 m = orig1 and re.match(r"^\[ (\d+) lines removed \]$", orig1)
 if m:
 line1 += int(m.group(1))
-elif orig1 is not None:
+elif orig1:
 line1 += 1
 m = orig2 and re.match(r"^\[ (\d+) lines removed \]$", orig2)
 if m:
 line2 += int(m.group(1))
-elif orig2 is not None:
+elif orig2:
 line2 += 1
 
 

However, there's another issue, that the diff is actually incomplete:
the right hand side stops 3 lines too early.

(The patch is not actually changing anything here, I just figured
once the numbers looked normal, but didn't match)

Mike
drwxr-xr-x 0/0   0 2015-12-16 18:43:24 firefox/
-rw-r--r-- 0/0 899 2015-12-16 18:43:17 firefox/libnssdbm3.chk
-rw-r--r-- 0/0 899 2015-12-16 18:43:17 firefox/libfreebl3.chk
-rwxr-xr-x 0/0  141782 2015-12-16 18:43:17 firefox/libnssdbm3.so
-rwxr-xr-x 0/0   98107 2015-12-16 18:43:17 firefox/crashreporter
-rwxr-xr-x 0/0 1152003 2015-12-16 18:43:17 firefox/libnss3.so
-rwxr-xr-x 0/0  170163 2015-12-16 18:43:17 firefox/firefox-bin
-rw-r--r-- 0/01936 2015-12-16 18:43:24 firefox/precomplete
-rw-r--r-- 0/04003 2015-09-11 09:29:56 firefox/crashreporter.ini
-rwxr-xr-x 0/0  288136 2015-12-16 18:43:13 firefox/libnspr4.so
-rw-r--r-- 0/0 691 2015-12-16 18:17:17 firefox/application.ini
-rwxr-xr-x 0/0  178734 2015-12-16 18:43:17 firefox/libnssutil3.so
-rwxr-xr-x 0/0  415676 2015-12-16 18:43:17 firefox/plugin-container
-rw-r--r-- 0/0 140 2015-12-16 18:37:34 firefox/dependentlibs.list
-rw-r--r-- 0/0 132 2015-12-16 18:38:17 firefox/update-settings.ini
-rw-r--r-- 0/0 825 2015-09-11 09:29:59 firefox/Throbber-small.gif
-rwxr-xr-x 0/08915 2015-09-11 09:29:34 firefox/run-mozilla.sh
-rwxr-xr-x 0/0   17250 2015-12-16 18:43:13 firefox/libplds4.so
drwxr-xr-x 0/0   0 2015-12-16 18:43:13 firefox/dictionaries/
-rw-r--r-- 0/03074 2015-09-11 09:30:02 
firefox/dictionaries/en-US.aff
-rw-r--r-- 0/0  599769 2015-12-04 07:02:07 
firefox/dictionaries/en-US.dic
-rwxr-xr-x 0/0  200987 2015-12-16 18:43:17 firefox/webapprt-stub
-rwxr-xr-x 0/099927433 2015-12-16 18:43:16 firefox/libxul.so
-rwxr-xr-x 0/0   85802 2015-12-16 18:43:17 firefox/liblgpllibs.so
-rwxr-xr-x 0/0  604259 2015-12-16 18:43:17 firefox/libnssckbi.so
-rwxr-xr-x 0/0   22824 2015-12-16 18:43:13 firefox/libplc4.so
-rw-r--r-- 0/0 9814288 2015-12-16 18:43:09 firefox/omni.ja
-rwxr-xr-x 0/0  693226 2015-12-16 18:43:17 firefox/libmozsqlite3.so
-rw-r--r-- 0/0 707 2015-12-16 18:43:17 firefox/removed-files
-rwxr-xr-x 0/0  141334 2015-12-16 18:43:17 firefox/updater
-rw-r--r-- 0/0 899 2015-12-16 18:43:17 firefox/libsoftokn3.chk
drwxr-xr-x 0/0   0 2015-12-16 18:43:00 firefox/defaults/
drwxr-xr-x 0/0   0 2015-12-16 18:43:17 firefox/defaults/pref/
-rw-r--r-- 0/0 245 2015-12-16 18:38:37 
firefox/defaults/pref/channel-prefs.js
-rwxr-xr-x 0/0  504460 2015-12-16 18:43:17 firefox/libfreebl3.so
drwxr-xr-x 0/0   0 2015-12-16 18:43:17 firefox/webapprt/
-rw-r--r-- 0/0   75463 2015-12-16 18:43:17 firefox/webapprt/omni.ja
-rw-r--r-- 0/0 495 2015-12-16 18:38:30 firefox/webapprt/webapprt.ini
-rwxr-xr-x 0/0   13582 2015-12-16 18:43:17 firefox/libmozgtk.so
-rw-r--r-- 0/0 681 2015-12-16 18:38:34 firefox/updater.ini
-rwxr-xr-x 0/0  170155 2015-12-16 18:43:17 firefox/firefox
-rw-r--r-- 0/0 145 2015-12-16 18:38:27 firefox/platform.ini
-rwxr-xr-x 0/0  263135 2015-12-16 18:43:17 firefox/libsoftokn3.so
-rwxr-xr-x 0/0  257055 2015-12-16 18:43:17 firefox/libssl3.so
drwxr-xr-x 0/0   0 2015-12-16 18:43:00 firefox/gmp-clearkey/
drwxr-xr-x 0/0   0 2015-12-16 18:43:17 

Bug#807604: Not a VLC bug but a radeon one.

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 16 December 2015 21:04:02 Lisandro Damián Nicanor Pérez Meyer 
wrote:
[snip]
> I'll ad more info in a couple of minutes.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Nov 17  2010 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct 27 20:43 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] [1002:68f9]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-8) ) #1 SMP Debian 4.2.6-3 (2015-12-06)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  19031 Jul 24 19:37 /var/log/Xorg.3.log
-rw-r--r-- 1 root root  19030 Jul 24 19:37 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 416334 Aug 20 18:45 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  51816 Dec 16 21:05 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[36.048]
X.Org X Server 1.17.3
Release Date: 2015-10-26
[36.048] X Protocol Version 11, Revision 0
[36.048] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[36.048] Current Operating System: Linux luna 4.2.0-1-amd64 #1 SMP Debian 
4.2.6-3 (2015-12-06) x86_64
[36.048] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64 
root=UUID=78cb5efd-5ed7-4d61-9beb-6cb55e9d0e53 ro drm.edid_strict=0 quiet
[36.048] Build Date: 27 October 2015  11:41:02PM
[36.048] xorg-server 2:1.17.3-2 (http://www.debian.org/support)
[36.048] Current version of pixman: 0.33.4
[36.048]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[36.048] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[36.049] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 16 20:59:49 
2015
[36.265] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[36.592] (==) No Layout section.  Using the first Screen section.
[36.592] (==) No screen section available. Using defaults.
[36.592] (**) |-->Screen "Default Screen Section" (0)
[36.592] (**) |   |-->Monitor ""
[36.706] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[36.706] (==) Automatically adding devices
[36.706] (==) Automatically enabling devices
[36.706] (==) Automatically adding GPU devices
[36.957] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[36.957]Entry deleted from font path.
[37.299] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[37.299] (==) ModulePath set to "/usr/lib/xorg/modules"
[37.299] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[37.299] (II) Loader magic: 0x55ff8791bde0
[37.299] (II) Module ABI versions:
[37.299]X.Org ANSI C Emulation: 0.4
[37.299]X.Org Video Driver: 19.0
[37.299]X.Org XInput driver : 21.0
[37.299]X.Org Server Extension : 9.0
[37.303] (EE) systemd-logind: failed to get session: PID 1017 does not 
belong to any known session
[37.304] (II) xfree86: Adding drm device (/dev/dri/card0)
[37.307] (--) PCI:*(0:1:0:0) 1002:68f9:1682:3030 rev 0, Mem @ 
0xd000/268435456, 0xfdcc/131072, I/O @ 0xde00/256, BIOS @ 
0x/131072
[37.353] (II) LoadModule: "glx"
[37.505] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[38.341] (II) Module glx: vendor="X.Org Foundation"
[38.342]compiled for 1.17.3, module version = 1.0.0
[38.342]ABI class: X.Org Server Extension, version 9.0
[38.342] (==) AIGLX enabled
[38.342] (==) Matched ati as autoconfigured driver 0
[38.342] (==) Matched ati as autoconfigured driver 1
[38.342] (==) Matched modesetting as autoconfigured driver 2
[38.342] (==) Matched fbdev as autoconfigured driver 3
[38.342] (==) Matched vesa as autoconfigured driver 4
[38.342] (==) Assigned the driver to the xf86ConfigLayout
[38.342] (II) LoadModule: "ati"
[38.528] (II) 

Bug#450886: Spurious HTTPS network resets spreading

[Andrew Valencia]

As of December 15th, 2015 Duck Duck Go now resets when I try to
connect from lynx.
One assumes there is some newer level of SSL strictness which is deploying
and not compatible with lynx.  I'll dig through the code and see if more debug
info can be enabled.

Bug#807943: game-data-packager: cannot make packages of large games

[Alam Arias]

On Mon, 14 Dec 2015 23:31:29 +
Simon McVittie  wrote:

> Was this done on the correct system? You mentioned 1.18.3 on your
> other bug report, and 1.17.25 is stable's version of dpkg, whereas
> the rest of your packages seem to be from testing/unstable.
> 
> S
> 
It seems I have dpkg pinned via apt-listbugs for bug #801156: dpkg: sometimes 
does not pass old version to postinst on upgrade

Bug#450886: [pkg-lynx-maint] Bug#450886: Spurious HTTPS network resets spreading

[Axel Beckert]

Hi Andrew,

Andrew Valencia wrote:
> As of December 15th, 2015 Duck Duck Go now resets when I try to
> connect from lynx.

Yes. http://duckduckgo.com/ no more seems to be able to handle
HTTP/1.0 requests. Which is what Lynx sends.

> One assumes there is some newer level of SSL strictness which is deploying
> and not compatible with lynx.

Nope. Seems on HTTP, too.

See the discussion on the upstream mailing list, e.g. here:
https://lists.nongnu.org/archive/html/lynx-dev/2015-12/msg7.html

Full thread view at
https://lists.nongnu.org/archive/html/lynx-dev/2015-12/threads.html

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#808193: tunesviewer: deprecation of python-support

[Mattia Rizzolo]

Package: src:tunesviewer
Version: 1.4.99.2-1
Severity: serious
Tags: patch sid stretch
User: debian-pyt...@lists.debian.org
Usertags: pysupport-deprecation

Dear Maintainer,

your package either depends on the python-support package.

python-support has been deprecated for some time (since 2011), and we're
currently in the process of removing it in favour of dh_python2.

Unfortunately your package went unnoticed till now, where we're on an
advanced state of the transition, with very few blockers, so I'm sorry
for the severity and the short notice of this bug report.

Attached there is a patch that is really enough to fix this, and I'd be
happy to do a minimal NMU of it.

Thanks!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#808192: ITP: libfm-qt -- library providing components to build desktop file managers

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: LXQt Packaging Team <pkg-lxqt-de...@lists.alioth.debian.org>

* Package name: libfm-qt
  Version     : 0~20151216
  Upstream Author : Hong Jen Yee (PCMan)
* URL : https://github.com/lxde/libfm-qt
* License : LGPL-2.1
  Programming Lang: C++
  Description : Library providing components to build desktop file managers

 libfm-qt is the Qt port of the libfm. It provides components to build a
 desktop file manager.

-- 
ChangZhuo Chen (陳昌倬) <czc...@debian.org>
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature

Bug#808185: [Debian-med-packaging] Bug#808185: blasr: outdated binaries on several architectures

[Afif Elghraoui]

Hello,

على الأربعاء 16 كانون الأول 2015 ‫14:15، كتب Emilio Pozuelo Monfort:
> Your package no longer builds on armhf, mips, mipsel, powerpc and s390x,
> where it built in the past. That prevents testing migration.
> 
> The problem is that libblasr-dev, now built from pbseqlib, is not
> available on those arches:
> 
> https://buildd.debian.org/status/package.php?p=pbseqlib=sid
> 
> So either that needs to be sorted out somehow, or the blasr binaries
> need to be removed from those architectures.
> 

Yes, I was already planning to file for removal of the package for those
architectures, but just hadn't got around to it yet. The testing
migration would have been delayed anyway because pbseqlib is not in
testing currently and there appears to be an ongoing hdf5 transition.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name