Bug#749026: [PKG-Openstack-devel] Bug#749026: keystone: CVE-2014-0204: nproper role assignments to users

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, May 23, 2014 at 02:39:20PM +0800, Thomas Goirand wrote:
> On 05/23/2014 01:16 PM, Salvatore Bonaccorso wrote:
> > Source: keystone
> > Severity: grave
> > Tags: security upstream
> > 
> > Hi Thomas,
> > 
> > the following vulnerability was published for keystone.
> > 
> > CVE-2014-0204[0]:
> > Keystone user and group id mismatch
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0204
> > https://security-tracker.debian.org/tracker/CVE-2014-0204
> > [1] https://bugs.launchpad.net/keystone/%2Bbug/1309228
> > 
> >>From advisory (code not checked) it looks wheezy version should not be
> > affected, but could you please adjust the affected versions in the BTS
> > as needed?
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore,
> 
> This was already uploaded in version 2014.1-3. I forgot to edit the
> debian/changelog for this (I uploaded mistakenly before I was finished
> with my work). However, there's an update for the patch which the
> package still doesn't have, so I will leave the bug open until I can
> find the time to push for an updated patch.

Indeed, thanks for correction! I have added also a note on the
security-tracker, that the patch needs a follow-up patch first (and we
can mark then as fixed with 2014.1-4 or whatever it will be).

Thanks for your work,

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#739719: goaccess package update

[GCS]

Hi Chris,

It seems you neglect the goaccess package quite a bit. There were
several upstream releases since your last upload almost a year ago.
Are you still interested or may I take over the package?

Regards,
Laszlo/GCS


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749030: liblwgeom-2.1.3 and liblwgeom-2.1.2: error when trying to install together

[Ralf Treinen]

Package: liblwgeom-2.1.2,liblwgeom-2.1.3
Version: liblwgeom-2.1.2/2.1.3+dfsg-1
Version: liblwgeom-2.1.3/2.1.3+dfsg-2
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2014-05-23
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libgeos-3.4.2.
(Reading database ... 10936 files and directories currently installed.)
Preparing to unpack .../libgeos-3.4.2_3.4.2-5_amd64.deb ...
Unpacking libgeos-3.4.2 (3.4.2-5) ...
Selecting previously unselected package libgeos-c1.
Preparing to unpack .../libgeos-c1_3.4.2-5_amd64.deb ...
Unpacking libgeos-c1 (3.4.2-5) ...
Selecting previously unselected package proj-data.
Preparing to unpack .../proj-data_4.8.0-5_amd64.deb ...
Unpacking proj-data (4.8.0-5) ...
Selecting previously unselected package libproj0.
Preparing to unpack .../libproj0_4.8.0-5_amd64.deb ...
Unpacking libproj0 (4.8.0-5) ...
Selecting previously unselected package libjson0:amd64.
Preparing to unpack .../libjson0_0.11-4_amd64.deb ...
Unpacking libjson0:amd64 (0.11-4) ...
Selecting previously unselected package liblwgeom-2.1.2.
Preparing to unpack .../liblwgeom-2.1.2_2.1.3+dfsg-1_amd64.deb ...
Unpacking liblwgeom-2.1.2 (2.1.3+dfsg-1) ...
Selecting previously unselected package liblwgeom-2.1.3.
Preparing to unpack .../liblwgeom-2.1.3_2.1.3+dfsg-2_amd64.deb ...
Unpacking liblwgeom-2.1.3 (2.1.3+dfsg-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/liblwgeom-2.1.3_2.1.3+dfsg-2_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/liblwgeom-2.1.3.so', which is also in package 
liblwgeom-2.1.2 2.1.3+dfsg-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/liblwgeom-2.1.3_2.1.3+dfsg-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/liblwgeom-2.1.3.so

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749031: transmission-gtk: Tray icon in mate-panel and gnome-shell has excessive spacing

[Valerio De Benedetto]

Package: transmission-gtk
Version: 2.52-3+nmu1
Severity: minor

This bug affects gnome-shell with the traytop extension (it moves the icons
from the notification area to the tray on the panel) and mate-panel.
Its behaviour is strange: if i change the icon theme, the spacing is fixed. I
attached a screenshot to show the situation



-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.14-0.bpo.1-686-pae (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages transmission-gtk depends on:
ii  libc62.13-38+deb7u1
ii  libcurl3-gnutls  7.26.0-1+wheezy9
ii  libevent-2.0-5   2.0.19-stable-3
ii  libgdk-pixbuf2.0-0   2.26.1-1
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgtk-3-0   3.4.2-7
ii  libminiupnpc51.5-2
ii  libnatpmp1   20110808-3
ii  libpango1.0-01.30.0-1
ii  libssl1.0.0  1.0.1e-2+deb7u9
ii  transmission-common  2.52-3+nmu1
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages transmission-gtk recommends:
ii  xdg-utils  1.1.0~rc1+git20111210-6

transmission-gtk suggests no packages.

Bug#675620: #675620 - gnome-session: every month Gnome forgets my language

[Arthur de Jong]

On Sat, 2014-05-17 at 01:52 +0100, althaser wrote:
> yes it would be nice if you can test it again and let us know.

It seems to happen every time I log in now. My user account information
comes from LDAP and gdm seems to be started before name services are
available.

The chooser list in gdm only shows the previously logged-in users if I
restart gdm before logging in (or for the second user that logs in after
a reboot). In that case my locale is reverted to C.

If I change my settings in the settings center, log out and log back in
again the language is restored for one session.

So I'm reverting my system locale again to en_GB.utf8.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Bug#636783: TC casting vote

[Svante Signell]

On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote:
> On 22/05/14 at 10:14 -0700, Steve Langasek wrote:
> > On Thu, May 22, 2014 at 03:56:26PM +0100, Ian Jackson wrote:
> > > We have had some discussion about this.  No-one seems to have objected
> > > to the suggestion that the DPL, rather than the TC chairman, should
> > > have a casting vote in TC decisions.
> > 
> > > I'm therefore intending to roll this up into my TC GR(s).
> > 
> > I don't recall seeing this discussion.  I don't agree that this is a good
> > structural change, for similar reasons to Tollef.
> 
> Same here.
> 
> Additionally:
> 1/ it would feel quite strange if the DPL suddenly had to dig
> deeply into a controversial issue at the end of the voting period,
> without taking part in the earlier technical discussion.
> 
> 2/ the DPL is not chosen using the same criteria as the TC members, and
> we may very well have a DPL that is not trusted by the project for
> his/her technical skills. So it would mean turning a technical decision
> into a political one.
> 
> 3/ a recent GR (the code of conduct one) showed that Developers were not
> big fans of the idea of deferring out-of-the-usual-scope decisions to
> the DPL.

The solution is simple: Have an odd number of members in the TC. Then no
casting vote is needed at all.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745891: Fix for dmb on armel

[Ondřej Surý]

Hi,

I have prepared fix to disable usage of dmb on armel. It's hidden in
urcu/arch.h and enabled by urcu/config.h (that get's defined on library
compile time and not on program compile time).

The fix has been commited to git and uploaded to DELAYED/2.

It's a hack in debian/rules that does disable dmb only on armel and not
on armhf. Feel free to improve the fix and reupload as -3.

But please let it migrate to testing before uploading new versions, so
the liburcu transition is no longer blocked by failing r-deps.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741410: [pkg-fgfs-crew] New FGo Release

[Markus Wanner]

Christopher,

I finally got around continuing on that work.

On 03/23/2014 01:32 AM, Christopher Baines wrote:
> I have now uploaded a package for the new release to the Debian Mentors
> site [1].

I created a git repo on alioth and uploaded there:
http://anonscm.debian.org/gitweb/?p=collab-maint/fgo.git

> This should correctly incorporate all of the patches in the BTS
> (thanks), and some other small changes. This release also changes the
> maintainer from myself, to the team, as this better matches the other
> FlightGear related packages.

Great work, thanks. I upgraded to 1.5.2.

@Scott: could you please review that and possibly sponsor the upload?

Regards

Markus Wanner




signature.asc
Description: OpenPGP digital signature

Bug#636783: TC casting vote

[Lucas Nussbaum]

On 23/05/14 at 09:42 +0200, Svante Signell wrote:
> On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote:
> > On 22/05/14 at 10:14 -0700, Steve Langasek wrote:
> > > On Thu, May 22, 2014 at 03:56:26PM +0100, Ian Jackson wrote:
> > > > We have had some discussion about this.  No-one seems to have objected
> > > > to the suggestion that the DPL, rather than the TC chairman, should
> > > > have a casting vote in TC decisions.
> > > 
> > > > I'm therefore intending to roll this up into my TC GR(s).
> > > 
> > > I don't recall seeing this discussion.  I don't agree that this is a good
> > > structural change, for similar reasons to Tollef.
> > 
> > Same here.
> > 
> > Additionally:
> > 1/ it would feel quite strange if the DPL suddenly had to dig
> > deeply into a controversial issue at the end of the voting period,
> > without taking part in the earlier technical discussion.
> > 
> > 2/ the DPL is not chosen using the same criteria as the TC members, and
> > we may very well have a DPL that is not trusted by the project for
> > his/her technical skills. So it would mean turning a technical decision
> > into a political one.
> > 
> > 3/ a recent GR (the code of conduct one) showed that Developers were not
> > big fans of the idea of deferring out-of-the-usual-scope decisions to
> > the DPL.
> 
> The solution is simple: Have an odd number of members in the TC. Then no
> casting vote is needed at all.

No, one can rank two options at the same level.

Lucas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749026: [PKG-Openstack-devel] Bug#749026: Bug#749026: keystone: CVE-2014-0204: nproper role assignments to users

[Thomas Goirand]

On 05/23/2014 03:00 PM, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> On Fri, May 23, 2014 at 02:39:20PM +0800, Thomas Goirand wrote:
>> On 05/23/2014 01:16 PM, Salvatore Bonaccorso wrote:
>>> Source: keystone
>>> Severity: grave
>>> Tags: security upstream
>>>
>>> Hi Thomas,
>>>
>>> the following vulnerability was published for keystone.
>>>
>>> CVE-2014-0204[0]:
>>> Keystone user and group id mismatch
>>>
>>> If you fix the vulnerability please also make sure to include the
>>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>>
>>> For further information see:
>>>
>>> [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0204
>>> https://security-tracker.debian.org/tracker/CVE-2014-0204
>>> [1] https://bugs.launchpad.net/keystone/%2Bbug/1309228
>>>
>>> >From advisory (code not checked) it looks wheezy version should not be
>>> affected, but could you please adjust the affected versions in the BTS
>>> as needed?
>>>
>>> Regards,
>>> Salvatore
>>
>> Hi Salvatore,
>>
>> This was already uploaded in version 2014.1-3. I forgot to edit the
>> debian/changelog for this (I uploaded mistakenly before I was finished
>> with my work). However, there's an update for the patch which the
>> package still doesn't have, so I will leave the bug open until I can
>> find the time to push for an updated patch.
> 
> Indeed, thanks for correction! I have added also a note on the
> security-tracker, that the patch needs a follow-up patch first (and we
> can mark then as fixed with 2014.1-4 or whatever it will be).
> 
> Thanks for your work,
> 
> Regards,
> Salvatore

Thanks.

FYI, Essex (eg: what's in Wheezy) isn't affected. Also, the current
backport to Icehouse (eg: 2014.1) is still under review:

https://review.openstack.org/#/c/94397/

I prefer to wait until the review process is finished. As I understand,
the regression is: a userid containing a ',' can't log in.

Do you think, like I do, that I should lower the severity of this bug
and let 2014.1-3 migrate to testing?

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 faile

[Jan Beulich]

>>> On 22.05.14 at 19:19,  wrote:
> "Jan Beulich"  writes:
> #Okay, this at least clarifies there is a (relatively big) RMRR. There is
> #a change to the handling of these among the ones that'll become
> #4.3.3 - mind giving
> #http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6c63041428cc348bcb2 
> 887afabd606bc4bd5523f
> #a try on top of your 4.3.2 (or trying the tip of the stable-4.3 branch)?
> #
> #> What else did I miss that could be useful info?
> #
> #At least the resolution of these addresses
> #
> #(XEN) traps.c:3061: GPF (): 82c4c0186a91 -> 82c4c0218daa
> #(XEN) traps.c:3061: GPF (): 82c4c0186a91 -> 82c4c0218daa
> #
> #into (symbol,offset) pairs, so we can at least make a first guess at
> #whether these are in any way related to your problem.
> 
> Booted into xen compiled with xen-syms.
> Hope this is right.  :)
> 
> root@xen-3:~# xl dmesg |grep trap |grep GPF
> (XEN) traps.c:3061: GPF (): 82c4c0186ae1 -> 82c4c0218e3a
> (XEN) traps.c:3061: GPF (): 82c4c0186ae1 -> 82c4c0218e3a
> root@xen-3:~# gdb xen-4.3.0/xen/xen-syms
> GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /root/xen-4.3.0/xen/xen-syms...done.
> (gdb) list *0x82c4c0186ae1
> 0x82c4c0186ae1 is in do_general_protection (traps.c:2597).
> 2592case MSR_EFER:
> 2593 rdmsr_normal:
> 2594/* Everyone can read the MSR space. */
> 2595/* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR 
> %p.\n",
> 2596_p(regs->ecx));*/
> 2597if ( rdmsr_safe(regs->ecx, msr_content) )
> 2598goto fail;
> 2599regs->eax = (uint32_t)msr_content;
> 2600regs->edx = (uint32_t)(msr_content >> 32);
> 2601break;

Thanks. We can then pretty much rule out a connection of these
with the issue at hand.

> I am a noob when working with source code. How do I bump my xen up to 4.3.3?

I guess this
http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
should help you.

Jan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749019: vnstati: vnstat Fails to create backup database .eth0

[Felix Geyer]

On 2014-05-23 03:57, Adam Brenner wrote:

Package: vnstati
Version: 1.11-2
Severity: important

Howdy,

Upon installing vnstat using the following command:

  $ apt-get install vnstati

the vnstat daemon is able to create its own database for each 
interface.

However, when trying to update its own database, it attempts to create
a backup database '.eth0' for example. It is unable to.

The error in syslog shows:

  vnstatd[12464]: Error: Unable create database backup 
"/var/lib/vnstat/.eth0".
  vnstatd[12464]: Error: Unable to write database, continuing with 
cached data.

  vnstatd[12464]: Database write possible again.

Running the following command has resolved the issue. I was able to
reproduce this issue on two machines running the same version of jess.

The fix for me was the following command

  $ touch /var/lib/vnstat/.eth0
  $ chown -R vnstat:vnstat /var/lib/vnstat/.eth0


I don't see a reason why vnstat would be able to create 
/var/lib/vnstat/eth0 but not .eth0.


When did the error occur? Right after the installation of vnstat?

What's the output of:
stat /var/lib/vnstat/ /var/lib/vnstat/*

Regards,
Felix


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#743122: Patch: add a build-dependency on dh-autoreconf

[Andrea Claudi]

Hello,
The FTBFS can be fixed adding a build-dependency on dh-autoreconf.

diff -Nru starplot-0.95.5/debian/changelog starplot-0.95.5/debian/changelog
--- starplot-0.95.5/debian/changelog2014-03-03 23:24:20.0 +0100
+++ starplot-0.95.5/debian/changelog2014-05-21 00:22:13.0 +0200
@@ -1,3 +1,11 @@
+starplot (0.95.5-8.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control: Add Build-Depends on dh-autoreconf
+This fixes the FTBFS  for the amd64 architecture (Closed: #743122)
+
+ -- Andrea Claudi   Wed, 21 May 2014 00:19:13 +0200
+
 starplot (0.95.5-8) unstable; urgency=medium

   * Update Maintainer's address 
diff -Nru starplot-0.95.5/debian/control starplot-0.95.5/debian/control
--- starplot-0.95.5/debian/control  2014-03-03 23:25:13.0 +0100
+++ starplot-0.95.5/debian/control  2014-05-21 00:25:05.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Francisco Manuel Garcia Claramonte 
 Uploaders: Javier Fernández-Sanguino Peña , Kevin B. McCarty 

-Build-Depends: debhelper (>> 9.0.0), libgtk2.0-dev, autotools-dev
+Build-Depends: debhelper (>> 9.0.0), libgtk2.0-dev, dh-autoreconf
 Standards-Version: 3.9.3
 Homepage: http://starplot.org

Regards,
Andrea Claudi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749032: python-kde4: crash in apport-kde

[Ritesh Raj Sarraf]

Package: python-kde4
Version: 4:4.12.2-2+b2
Severity: important

Apport KDE has been crashing for a while (more than a year) with python
kde. I hadn't bothered reporting as Apport is not a priority in Debian
and will always reside in experimental.

But if you have some time, please look into it. I had checked with the
apport developer too and he believes that the problem is with Debian's
python kde4 package. 

FYI, the problem does not occur on apport gtk.

While the crash trace is useless, I'm still attaching it.

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

Kernel: Linux 3.14-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

Versions of packages python-kde4 depends on:
ii  kde-runtime4:4.12.4-1
ii  kdepim-runtime 4:4.12.4-2
ii  libakonadi-kde44:4.12.4-1
ii  libakonadi-kmime4  4:4.12.4-1
ii  libc6  2.18-5
ii  libkcmutils4   4:4.13.1-1
ii  libkdecore54:4.13.1-1
ii  libkdeui5  4:4.13.1-1
ii  libkdnssd4 4:4.13.1-1
ii  libkemoticons4 4:4.13.1-1
ii  libkfile4  4:4.13.1-1
ii  libkhtml5  4:4.13.1-1
ii  libkidletime4  4:4.13.1-1
ii  libkio54:4.13.1-1
ii  libknewstuff2-44:4.13.1-1
ii  libknewstuff3-44:4.13.1-1
ii  libkparts4 4:4.13.1-1
ii  libkprintutils44:4.13.1-1
ii  libkpty4   4:4.13.1-1
ii  libktexteditor44:4.13.1-1
ii  libnepomuk44:4.13.1-1
ii  libnepomukquery4a  4:4.13.1-1
ii  libphonon4 4:4.7.1-1
ii  libplasma3 4:4.13.1-1
ii  libpython2.7   2.7.6-8
ii  libqt4-network 4:4.8.6+dfsg-1
ii  libqt4-svg 4:4.8.6+dfsg-1
ii  libqt4-xml 4:4.8.6+dfsg-1
ii  libqtcore4 4:4.8.6+dfsg-1
ii  libqtgui4  4:4.8.6+dfsg-1
ii  libsolid4  4:4.13.1-1
ii  libsoprano42.9.4+dfsg-1
ii  libstdc++6 4.9.0-3
ii  phonon 4:4.7.1-1
ii  python 2.7.6-1
ii  python-qt4 4.10.4+dfsg-2
ii  python-sip [sip-api-11.0]  4.15.5-2

python-kde4 recommends no packages.

python-kde4 suggests no packages.

-- no debconf information
Application: Apport KDE (python2), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#5  0x7f4deb4573a9 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#6  0x7f4deb45a4c8 in __GI_abort () at abort.c:89
#7  0x7f4de86f6c22 in qt_message_output(QtMsgType, char const*) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x7f4de11607a9 in ?? () from /usr/lib/libkdeui.so.5
#9  0x7f4de12389b8 in ?? () from /usr/lib/libkdeui.so.5
#10 0x7f4de1239392 in KApplication::KApplication(bool) () from 
/usr/lib/libkdeui.so.5
#11 0x7f4de1a38c5d in sipKApplication::sipKApplication(bool) () from 
/usr/lib/python2.7/dist-packages/PyKDE4/kdeui.so
#12 0x7f4de1a39132 in ?? () from 
/usr/lib/python2.7/dist-packages/PyKDE4/kdeui.so
#13 0x7f4de7cc201c in ?? () from /usr/lib/python2.7/dist-packages/sip.so
#14 0x0051d2bb in ?? ()
#15 0x00508dec in PyEval_EvalFrameEx ()
#16 0x00576f9c in PyEval_EvalCode ()
#17 0x00469884 in ?? ()
#18 0x00469c04 in PyRun_FileExFlags ()
#19 0x0046a809 in PyRun_SimpleFileExFlags ()
#20 0x0046b46e in Py_Main ()
#21 0x7f4deb443b45 in __libc_start_main (main=0x46b52c , argc=3, 
argv=0x7fffe5a6e418, init=, fini=, 
rtld_fini=, stack_end=0x7fffe5a6e408) at libc-start.c:287
#22 0x00579514 in _start ()

Bug#746754: linux-image-3.14-1-amd64: It is not possible to control the brightness anymore

[Aiko Barz]

On Sat, May 03, 2014 at 08:55:08PM +0100, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Sat, 2014-05-03 at 11:28 +0200, Aiko Barz wrote:
> > Package: src:linux
> > Version: 3.14.2-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> > $ aptitude dist-upgrade
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > $ reboot
> > 
> >* What was the outcome of this action?
> > 
> > The display had the maximum brightness and could not dimmed  by using the 
> > dim
> > buttons
> > 
> >* What outcome did you expect instead?
> > 
> > That things work like they did in 3.13.
> > 
> > * Workaround 1:
> > 
> > Boot linux-image-3.13-1-amd64
> > 
> > * Workaround 2:
> > 
> > $ echo 0 > /sys/class/backlight/intel_backlight/brightness
> > After doing this, everything works as expected.
> > Found hint at https://bugs.archlinux.org/task/39798
> 
> Please read  and report
> your results.

Didn't find the time for that. But I googled the issue once more and it
looks like that the issue will be fixed in 3.15.

"Backlight control broken on Dell XPS13 w/ kernel 3.14-rc7"
https://bugs.freedesktop.org/show_bug.cgi?id=76276

GregKH accepted a revert patch for 3.14 to fix the regression there too:
http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/38181

Kind regards,
Aiko

-- 
:wq ✉


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#743122: #743122 patch

[Andrea Claudi]

tags 743122 + patch
thanks

-- 
Andrea Claudi, PhD - Post-doc Research Fellow
Computer Engineering Department
Faculty of Engineering
Università Politecnica delle Marche
via Brecce Bianche, 60131 Ancona, Italy

Web: http://airtlab.dii.univpm.it
Phone: (+39) 071-2204372 | (+39) 071-2204473
Fax: (+39) 071-2204474


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749026: [PKG-Openstack-devel] Bug#749026: Bug#749026: keystone: CVE-2014-0204: nproper role assignments to users

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, May 23, 2014 at 03:50:47PM +0800, Thomas Goirand wrote:
[...]
> FYI, Essex (eg: what's in Wheezy) isn't affected. Also, the current
> backport to Icehouse (eg: 2014.1) is still under review:
> 
> https://review.openstack.org/#/c/94397/
> 
> I prefer to wait until the review process is finished. As I understand,
> the regression is: a userid containing a ',' can't log in.
> 
> Do you think, like I do, that I should lower the severity of this bug
> and let 2014.1-3 migrate to testing?

Yes, I think it is fine to lower the severity of this bug to important.

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749033: gnome: Can't integrate Facebook using online Accounts

[Augustus]

Package: gnome
Version: 1:3.4+7+deb7u1
Severity: important

Dear Maintainer,

   * What led up to the situation?
  I wanted to Integrate facebook chat on my latest Stable version of Debian 
"Wheezy"
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  I went to "Online Accounts" in "System Settings" page. I successfully 
integrated with google Accounts. Then I tried another add which was facebook.
   * What was the outcome of this action?
  A new window popped up and remained blank. Nothing showed up inside it. 
Hence I couldn't authenticate my facebook Account.
   * What outcome did you expect instead?
  I expected to see facebook oAuth Screen inside that New Window just like 
it came in Google Accounts

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome depends on:
ii  aisleriot1:3.4.1-1
ii  alacarte 3.5.3-1
ii  avahi-daemon 0.6.31-2
ii  cheese   3.4.2-2
ii  cups-pk-helper   0.2.3-3
ii  desktop-base 7.0.3
ii  evolution3.4.4-3
ii  evolution-plugins3.4.4-3
ii  file-roller  3.4.2-1
ii  gedit3.4.2-1
ii  gedit-plugins3.4.0-1
ii  gimp 2.8.2-2+deb7u1
ii  gnome-applets3.4.1-3
ii  gnome-color-manager  3.4.2-1
ii  gnome-core   1:3.4+7+deb7u1
ii  gnome-documents  0.4.2-2
ii  gnome-games  1:3.4.2-3
ii  gnome-media  3.4.0-1
ii  gnome-nettool3.2.0-1
ii  gnome-orca   3.4.2-2
ii  gnome-shell-extensions   3.4.0-2
ii  gnome-tweak-tool 3.4.0.1-2
ii  gstreamer0.10-ffmpeg 0.10.13-5
ii  gstreamer0.10-plugins-ugly   0.10.19-2+b2
ii  hamster-applet   2.91.3+git20120514.b9fec3e1-1
ii  inkscape 0.48.3.1-1.3
ii  libgtk2-perl 2:1.244-1
ii  libreoffice-calc 1:3.5.4+dfsg2-0+deb7u2
ii  libreoffice-gnome1:3.5.4+dfsg2-0+deb7u2
ii  libreoffice-impress  1:3.5.4+dfsg2-0+deb7u2
ii  libreoffice-writer   1:3.5.4+dfsg2-0+deb7u2
ii  nautilus-sendto  3.0.3-2+b1
ii  network-manager-gnome0.9.4.1-5
ii  rhythmbox2.97-2.1
ii  rhythmbox-plugin-cdrecorder  2.97-2.1
ii  rhythmbox-plugins2.97-2.1
ii  rygel-playbin0.14.3-2+deb7u1
ii  rygel-preferences0.14.3-2+deb7u1
ii  rygel-tracker0.14.3-2+deb7u1
ii  seahorse 3.4.1-2
ii  shotwell 0.12.3-2+deb7u1
ii  simple-scan  3.4.2-1
ii  sound-juicer 3.4.0-3
ii  telepathy-gabble 0.16.7-0+deb7u1
ii  telepathy-rakia  0.7.4-1
ii  telepathy-salut  0.8.1-1
ii  tomboy   1.10.0-2
ii  totem3.0.1-8
ii  totem-plugins3.0.1-8
ii  tracker-gui  0.14.1-3
ii  transmission-gtk 2.52-3+nmu1
ii  vinagre  3.4.2-2
ii  xdg-user-dirs-gtk0.9-1

Versions of packages gnome recommends:
ii  browser-plugin-gnash 0.8.11~git20120629-1+deb7u1
ii  gdebi0.8.7
ii  gnome-games-extra-data   3.2.0-4
ii  nautilus-sendto-empathy  3.4.2.3-2+deb7u1
ii  telepathy-idle   0.1.11-2+deb7u1

Versions of packages gnome suggests:
pn  dia-gnome  
pn  gnome-boxes
pn  gnucash
pn  iceweasel-l10n-all 
ii  libreoffice-evolution  1:3.5.4+dfsg2-0+deb7u2
pn  planner
pn  xul-ext-adblock-plus   
pn  xul-ext-gnome-keyring  

Versions of packages gnome-core depends on:
ii  at-spi2-core2.5.3-2
ii  baobab  3.4.1-1
ii  brasero 3.4.1-4
ii  caribou 0.4.4-1
ii  caribou-antler  0.4.4-1
ii  dconf-gsettings-backend 0.12.1-3
ii  dconf-tools 0.12.1-3
ii  empathy 3.4.2.3-2+deb7u1
ii  eog 3.4.2-1+build1
ii  evince  3.4.0-3.1
ii  evolution-data-server   3.4.4-3
ii  fonts-cantarell 0.0.9-1
ii  gcalctool   6.4.2.1-3
ii  gconf2  3.2.5-1+build1
ii  gdm33.4.1-8
ii  gkbd-capplet3.4.0.2-1
ii  glib-networking 2.32.3-1
ii  gnome-backgrounds   3.4.2-1
ii  gnome-bluetooth 3.4.2-1
ii  gnome-contacts  3.4.1-1+b1
ii  gnome-control-center1:3.4.3.1-2
ii  gnome-dictionary3.4.0-2
ii  gnome-disk-utility  3.0.2-3
ii  gnome-font-vi

Bug#746736: kdenlive notification sounds maximize the pulseaudio volume

[Patrick Matthäi]

Hi,

upstream stated:

"I was looking at the bug 746736 on jessie + kdenlive from sid... it 
seems KDE's mixer setting on notification volume has no effect, only 
going to system settings/notifications allows toreally tune 
notifications volume. But then kdenlive respects it as any other program 
(it doesn't handle this kind ofthings by itself but relies on KDE 
infrastructure to do it)!"


Am 22.05.2014 19:17, schrieb Bo Lan:

Package: kdenlive
Version: 0.9.8-1
Followup-For: Bug #746736


Hi,
could you please retest your issue with kdenlive 0.9.8-1 from unstable?

Dear Patrick Matthäi,

After retesting the version of 0.9.8-1 from unstable. I still get the same
problem.

This time, I try to dist-upgrade my entire system to unstable. There is nothing
better, the system audio volume (pulseaudio) is still maximized by kdenlive's
notification sounds.

Thank you for your work.

Sincerely,
Bo



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

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kdenlive depends on:
ii  kde-runtime   4:4.12.4-1
ii  kdenlive-data 0.9.8-1
ii  libav-tools   6:9.13-1
ii  libc6 2.18-5
ii  libgcc1   1:4.9.0-3
ii  libgl1-mesa-glx [libgl1]  10.1.2-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libkdecore5   4:4.12.4-1
ii  libkdeui5 4:4.12.4-1
ii  libkio5   4:4.12.4-1
ii  libknewstuff3-4   4:4.12.4-1
ii  libknotifyconfig4 4:4.12.4-1
ii  libkrossui4   4:4.12.4-1
ii  libmlt++3 0.9.0+dfsg1-1
ii  libmlt6   0.9.0+dfsg1-1
ii  libnepomuk4   4:4.12.4-1
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.6+dfsg-1
ii  libqt4-network4:4.8.6+dfsg-1
ii  libqt4-opengl 4:4.8.6+dfsg-1
ii  libqt4-script 4:4.8.6+dfsg-1
ii  libqt4-svg4:4.8.6+dfsg-1
ii  libqt4-xml4:4.8.6+dfsg-1
ii  libqtcore44:4.8.6+dfsg-1
ii  libqtgui4 4:4.8.6+dfsg-1
ii  libsolid4 4:4.12.4-1
ii  libsoprano4   2.9.4+dfsg-1
ii  libstdc++64.9.0-3
ii  libx11-6  2:1.6.2-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1
ii  libxext6  2:1.3.2-1
ii  melt  0.9.0+dfsg1-1

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-1.2
ii  dvgrab   3.5-2
ii  frei0r-plugins   1.1.22git20091109-1.4
ii  genisoimage  9:1.1.11-2
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.15+1-7

Versions of packages kdenlive suggests:
pn  khelpcenter4  

-- no debconf information


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#636783: TC casting vote

[Svante Signell]

On Fri, 2014-05-23 at 09:52 +0200, Lucas Nussbaum wrote:
> On 23/05/14 at 09:42 +0200, Svante Signell wrote:
> > On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote:
> > > 
> > The solution is simple: Have an odd number of members in the TC. Then no
> > casting vote is needed at all.
> 
> No, one can rank two options at the same level.

Then add to the rules that doing that is forbidden. Or count the number
of TC members voting on the two problematic options and choose the one
having most votes. (the only remaining problem the would be that all TC
members rank two options equal: this probability would be very small)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749034: svnclientadapter: subversion dependency not strict enough

[Julian Taylor]

package: svnclientadapter
Version: 1.10.3-1
Severity: important

src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java
contains an exact check on the subversion version:
if (version.getMajor() == 1 && version.getMinor() == 8)
and raises an error when it does not match during setup.

the package does not have an equivalent dependency, it only depends on
>= 1.8 of libjava-svn

as the package stops working if subversion bumps its version the package
have the same strict version requirement so it is not overlooked in
transitions.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748955: libgwenhywfar-data: Contains as ca-bundle

[Micha Lenk]

Hi Kurt,

On 22.05.2014 18:45, Kurt Roeckx wrote:

Your package contains a ca-bundle with the certificates from the
mozilla root program.  You could please switch to those provided
by the ca-certificates package?


Thanks for reporting this issue. Right now I have no idea how to achieve 
that best. Do you have any documentation or examples available about how 
to integrate the data from the ca-certificates package in other 
packages? Are there any best practices on using that package?


Thanks a lot in advance,
Micha


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#693508: How to get hamster-applet running again

[Micha Lenk]

Hi,

I just ran into the same issue with the hamster applet not starting 
anymore. I am running Debian wheezy with some backports installed (see 
system information below). When I run it from the shell I always got the 
following output:


$ hamster-time-tracker
Traceback (most recent call last):
  File "/usr/bin/hamster-time-tracker", line 602, in 
app = ProjectHamster()
  File "/usr/bin/hamster-time-tracker", line 110, in __init__
self.init_workspace_tracking()
  File "/usr/bin/hamster-time-tracker", line 209, in 
init_workspace_tracking

if not wnck: # can't track if we don't have the trackable
NameError: global name 'wnck' is not defined

Following the advice in message #12 from Debian Bug #693508 did not help 
me at all. I even removed the mentioned file 
~/.gconf/apps/hamster-applet/%gconf.xml entirely, but even this didn't help.


What did help though was to run gconf-editor and set the Gconf key 
/apps/hamster-applet/workspace_tracking to an empty list. After that 
hamster started again. Apparently Gconf on my system stores the settings 
somewhere else...


I hope this information is useful to other users affected by this issue.


Happy hacking,
Micha



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages hamster-applet depends on:
ii  gconf23.2.5-1+build1
ii  python2.7.3-4+deb7u1
ii  python-cairo  1.8.8-1+b2
ii  python-dbus   1.1.1-1
ii  python-gconf  2.28.1+dfsg-1
ii  python-gnome2 2.28.1+dfsg-1
ii  python-gobject-2  2.28.6-10
ii  python-gtk2   2.24.0-3+b1
ii  python-wnck   2.32.0+dfsg-2+b1
ii  python-xdg0.19-5
ii  python2.7 2.7.3-6+deb7u2

Versions of packages hamster-applet recommends:
ii  gnome-icon-theme  3.4.0-2
ii  python-notify 0.1.1-3

Versions of packages hamster-applet suggests:
pn  python-evolution  

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748955: libgwenhywfar-data: Contains as ca-bundle

[Kurt Roeckx]

On Fri, May 23, 2014 at 11:02:21AM +0200, Micha Lenk wrote:
> Hi Kurt,
> 
> On 22.05.2014 18:45, Kurt Roeckx wrote:
> >Your package contains a ca-bundle with the certificates from the
> >mozilla root program.  You could please switch to those provided
> >by the ca-certificates package?
> 
> Thanks for reporting this issue. Right now I have no idea how to achieve
> that best. Do you have any documentation or examples available about how to
> integrate the data from the ca-certificates package in other packages? Are
> there any best practices on using that package?

The package contains an /etc/ssl/certs/ca-certificates.crt.  The
solutions I see:
- You use that file instead, maybe via a config option
- You replace your file with a symlink
- You have a config option to use the directory instead.


Kurt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749035: systemtap: diff for NMU version 2.3-3

[Dimitri John Ledkov]

Package: systemtap
Version: 2.3-2
Severity: normal
Tags: patch

Dear maintainer,

I've prepared an Ubuntu update for systemtap (versioned as 2.3-3) and
forwarding the change to you. After converting systemtap-sdt-dev to
become Arch:all, it now also needs M-A:foreign stanza to unbreak
cross-building package, with build-deps depending on
systemtap-sdt-dev. (e.g. build-dep on foo Arch:any M-A:same, which
depends on systemtap-sdt-dev, at cross-building results in trying to
install Arch:any, e.g. systemtap-sdt-dev:armhf)

Regards,

Dimitri.

diff -Nru systemtap-2.3/debian/changelog systemtap-2.3/debian/changelog
--- systemtap-2.3/debian/changelog  2014-04-05 14:13:18.0 +0100
+++ systemtap-2.3/debian/changelog  2014-05-23 10:15:05.0 +0100
@@ -1,3 +1,11 @@
+systemtap (2.3-3) UNRELEASED; urgency=medium
+
+  * Now that systemtap-sdt-dev is arch:all, it also needs to be
+Multi-Arch:foreign to unbreak cross-builds (otherwise M-A:same ->
+A:all dep, tries to pull A:any).
+
+ -- Dimitri John Ledkov   Fri, 23 May 2014 10:13:16 +0100
+
 systemtap (2.3-2) unstable; urgency=low
 
   * Don't Suggest linux-* since that won't guarantee right version anyway
diff -Nru systemtap-2.3/debian/control systemtap-2.3/debian/control
--- systemtap-2.3/debian/control2014-04-05 14:13:18.0 +0100
+++ systemtap-2.3/debian/control2014-05-23 10:13:14.0 +0100
@@ -103,6 +103,7 @@
 
 Package: systemtap-sdt-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, python:any
 Description: statically defined probes development files
  This package contains header file and executable (dtrace) that


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685112: freefoam: FTBFS - build output directories not created

[Jurica Stanojkovic]

Control: block 685112 by 735248

Hello,

I can confirm that cmake issue (735248) is blocking freefoam.

After removing multiarch-python-include-dirs.diff patch from cmake,
package freefoam builds further on mips and mipsel (with changed cmake).

Regards!
Jurica

Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 faile

[Ian Campbell]

On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote:
> > I am a noob when working with source code. How do I bump my xen up to 4.3.3?
> 
> I guess this
> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
> should help you.

Since this only needs a new hypervisor binary and not a full set of
tools etc to reproduce I think it can be simplified to replacing the
previous "apt-get source" with
git clone -b staging-4.3 git://xenbits.xen.org/xen.git 
cd xen

Then "make -C xen", install the xen.gz and boot it as you did
previously.

Ian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 faile

[Jan Beulich]

>>> On 23.05.14 at 11:21,  wrote:
> On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote:
>> > I am a noob when working with source code. How do I bump my xen up to 
> 4.3.3?
>> 
>> I guess this
>> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source 
>> should help you.
> 
> Since this only needs a new hypervisor binary and not a full set of
> tools etc to reproduce I think it can be simplified to replacing the
> previous "apt-get source" with
>   git clone -b staging-4.3 git://xenbits.xen.org/xen.git 
>   cd xen
> 
> Then "make -C xen", install the xen.gz and boot it as you did
> previously.

Right, I should have remembered to mention that. The above
seems slightly incorrect in that you need to either "cd xen" or pass
"-C xen" to make.

Jan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#622960: ITA: freemind -- Java Program for creating and viewing Mindmaps

[Mark Clarke]

retitle 622960 ITA: freemind -- Java Program for creating and viewing Mindmaps
noowner 622960 !


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749036: dash: while loop does not execute properly? (no warnings or errors)

[Enzo Trew]

Package: dash
Version: 0.5.7-3
Severity: normal

wheezy-Linux-amd64-GNOME

I have attached a test script.

If using dash, the file (iptables-log-match) is not created if the
search string is added to kern.log *after the script is executed*. But
if using bash it works properly!

I execute the script like this:

su root

***password***

./test.sh &

Enzo


test.sh
Description: Bourne shell script

Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 faile

[Ian Campbell]

On Fri, 2014-05-23 at 10:35 +0100, Jan Beulich wrote:
> >>> On 23.05.14 at 11:21,  wrote:
> > On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote:
> >> > I am a noob when working with source code. How do I bump my xen up to 
> > 4.3.3?
> >> 
> >> I guess this
> >> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source 
> >> should help you.
> > 
> > Since this only needs a new hypervisor binary and not a full set of
> > tools etc to reproduce I think it can be simplified to replacing the
> > previous "apt-get source" with
> > git clone -b staging-4.3 git://xenbits.xen.org/xen.git 
> > cd xen
> > 
> > Then "make -C xen", install the xen.gz and boot it as you did
> > previously.
> 
> Right, I should have remembered to mention that. The above
> seems slightly incorrect in that you need to either "cd xen" or pass
> "-C xen" to make.

The "cd xen" is to move into the cloned tree, the "-C xen" to to only
build the hypervisor subtree of that directory, so both are needed.

(IOW you could also make -C xen/xen)

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 faile

[Jan Beulich]

>>> On 23.05.14 at 12:08,  wrote:
> On Fri, 2014-05-23 at 10:35 +0100, Jan Beulich wrote:
>> >>> On 23.05.14 at 11:21,  wrote:
>> > On Fri, 2014-05-23 at 08:52 +0100, Jan Beulich wrote:
>> >> > I am a noob when working with source code. How do I bump my xen up to 
>> > 4.3.3?
>> >> 
>> >> I guess this
>> >> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source 
>> >> should help you.
>> > 
>> > Since this only needs a new hypervisor binary and not a full set of
>> > tools etc to reproduce I think it can be simplified to replacing the
>> > previous "apt-get source" with
>> >git clone -b staging-4.3 git://xenbits.xen.org/xen.git 
>> >cd xen
>> > 
>> > Then "make -C xen", install the xen.gz and boot it as you did
>> > previously.
>> 
>> Right, I should have remembered to mention that. The above
>> seems slightly incorrect in that you need to either "cd xen" or pass
>> "-C xen" to make.
> 
> The "cd xen" is to move into the cloned tree, the "-C xen" to to only
> build the hypervisor subtree of that directory, so both are needed.

Urgh - having hidden most of the "git clone"s I run in scripts, I
keep forgetting that this clones into a subdirectory. Sorry for
the noise.

Jan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749037: icedove: Regression of bug#730450: Same problem with Debian 7.5 stable, icedove=24.5.0-1~deb7u1 and lightning 2.6.5

[Tormen]

Package: icedove
Version: 24.5.0-1~deb7u1
Severity: important

Hi,

I failed "reopening" the archived Debian bug #730450:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730450

Which I tried because I am sure (hoping I did not miss anything) that
it's the exact same problem that occurs to me for a version that the BTS
version tree shows green.

I had first written the below when there was only lightning 2.6.4) but
somehow missed that the mail bounced because the bug was archived :(

I just retried with a fresh icedove profile and lightning 2.6.5 and I
got the same problem, when icedove restarts to activate lightning:

[calBackendLoader] Using libical backend at
/home/me/.icedove/2zjv6cxu.test/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical.manifest
icedove: relocation error:
/home/me/.icedove/2zjv6cxu.test/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/Linux_x86_64-gcc3/libcalbasecomps.so:
symbol _ZN2js13CheckedUnwrapEP8JSObjectb, version xul24 not defined in
file libxul.so with link time reference


And this is what I got, after icedove restarts with lightning 2.6.4
freshly installed:

icedove: relocation error:
/home/me/.icedove/profile.mine/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/Linux_x86_64-gcc3/libcalbasecomps.so:
symbol _ZN2js13CheckedUnwrapEP8JSObjectb, version xul24 not defined in
file libxul.so with link time reference

And only when I remove the folder:

/home/me/.icedove/profile.mine/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}

icedove starts up again (without lightning).

I also noticed that xulrunner-24.0 was not installed (automatically).
So I manually installed as the referenced libxul.so comes from the
xulrunner package, but no success either.

Could this maybe be related to me using iceweasel from backports ?
But as xulrunner-24.0 is it's own package I guess the below should be a
valid setup ?

ii  icedove
24.5.0-1~deb7u1amd64mail/news client with
RSS and integrated spam filter support
ii  iceweasel
29.0.1-1~bpo70+1   amd64Web browser based on Firefox
ii  xulrunner-24.0
24.5.0esr-1~deb7u1 amd64XUL + XPCOM application
runner
ii  xulrunner-29
29.0.1-1~bpo70+1   amd64XUL + XPCOM application
runner




I hope I did not miss something.


Thanks a lot in advance for any hint, because I am stuck with this.


Tormen


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

Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages icedove depends on:
ii  debianutils   4.3.2
ii  fontconfig2.9.0-7.1
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38+deb7u1
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u1
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libpango1.0-0 1.30.0-1
ii  libpixman-1-0 0.26.0-4+deb7u1
ii  libsqlite3-0  3.7.17-1~bpo70+1
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libvpx1   1.1.0-1
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxext6  2:1.3.1-2+deb7u1
ii  libxrender1   1:0.9.7-1+deb7u1
ii  libxt61:1.1.3-1+deb7u1
ii  psmisc22.19-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages icedove recommends:
ii  hunspell-de-de [hunspell-dictionary]  20120607-1
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  hunspell-fr [hunspell-dictionary] 1:3.3.0-4
ii  myspell-en-gb [myspell-dictionary]1:3.3.0-4

Versions of packages icedove suggests:
ii  fonts-lyx 2.0.3-3
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749038: Autoremoval reports when RC bugs fixed in unstable

[Dominic Hargreaves]

Package: release.debian.org

Hi,

I noticed that the PTS still reports pending autoremovals even when all
RC bug(s) in question are fixed in unstable and are simply awaiting
migration, which seems unwanted: the PTS wording implies that there is
work to be done, and it's likely to cause unnecessary worry amongst
reverse-dependencies; at least whilst the package is simply aging
in unstable rather than because there are issues preventing it
migrating to testing.

Is this something that can be fixed? I would guess that this should
be fixed at the underlying autoremovals level rather than PTS display,
hence filing the bug here.

Cheers,
Dominic.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748422: g++-4.8: Fails to build iceweasel in unstable on armhf

[Mike Hommey]

tag 748422 + patch
thanks

On Sat, May 17, 2014 at 10:23:38AM +0900, Mike Hommey wrote:
> Package: g++-4.8
> Version: 4.8.2-21
> Severity: important
> 
> See 
> https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=armhf&ver=29.0.1-1&stamp=1399804178
> 
> Error is:
> {standard input}: Assembler messages:
> {standard input}:7136: Error: branch out of range
> 
> Filed upstream bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208

Upstream bug is fixed in 4.8 branch:
http://gcc.gnu.org/viewcvs?rev=210814&root=gcc&view=rev

It was actually also affecting 4.9, but somehow iceweasel still built.

Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749039: Wheezy backport

[martin f krafft]

Source: bitlbee
Version: 3.0.5-1.2
Severity: wishlist

Can you provide a wheezy backport of 3.2.1, please?

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#748940: iscsitarget: "service iscsitaget stop" fails when under load

[Craig Barnes]

On 22/05/14 17:45, Ritesh Raj Sarraf wrote:

Please keep the bug email in the recipient list.


On 05/22/2014 09:37 PM, Craig Barnes wrote:

Could you please explain what is "heavy load" here? Is it iSCSI traffic ?


To simulate heavy load ( it does not need to be too heavy ), I initiated
4 dd operations to files on the device, then issued the stop.



I am assuming you are writing to the iscsi devices. If yes, then
there's no reason for this to not fail.


Yes I am writing to the iscsi device, the devices get removed as
expected, the service initiates a stop, only the kernel module unload
fails, I assume waiting for the service to finish or disks to sync.

Is there any reason why this shouldn't successfully stop?







# service iscsitarget stop
[ ok ] Removing iSCSI enterprise target devices: :.
[ ok ] Stopping iSCSI enterprise target service: :.
[] Removing iSCSI enterprise target modules: :FATAL: Module
iscsi_trgt is in use.

Changing etc/init/init.debian to use `rmmod --wait` instead of
`modprobe -r` corrects this issue.


We use 'modprobe -r' to ensure that dependencies also get unloaded. With
'rmmod --wait', wouldn't it hang the shutdown sequence ?


I wasn't able to determine any dependant libraries on my system, if
there are any in other packages that depend on iscsi_trgt then I would
be happy to test this and improve my solution.



Yes. THis one does not have any direct dependencies. As practice, I use
modprobe.


Ok, so
  a) what is the worst thing that could happen using rmmod --wait
  b) is there a better way to do this? maybe wait 2 secs and try again
with modprobe -r?
  c) if we fail at the module shouldn't we bring everything else back
again?




Our deployment has many targets so this is not practical for our use case.

I can see from the other init implementations that init.debian is the
only one that unloads the modules, is this still necessary?



The userspace daemon is very basic. The sessions are handled in the
kernel. So when you ask iscsitarget to stop, you want the session also
terminated, for which, we need to unload the module.

I haven't confirmed it on the iscsitarget code but for open-iscsi (the
initiator) that is the case.

Yes. That is the case. Look at conn.c in the sources.


Sorry my c is a bit rusty and I am no kernel dev.  But I understand and
appreciate your explanation.

However I did find this...
http://sourceforge.net/p/iscsitarget/code/343/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749030: liblwgeom-2.1.3 and liblwgeom-2.1.2: error when trying to install together

[Sebastiaan Couwenberg]

Hi Ralf,

Thanks for reporting this issue.

This same issue was also reported by Ralf Treinen in #Ben
Caradoc-Davies, so I've merged your two bugs.

The liblwgeom-2.1.3 package is fixed using Breaks/Replaces by Markus
Wanner in git, and is pending upload.

Kind Regards,

Bas

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749040: emacs24: frequent "unable to get local issuer certificate: accept? (y or n)" in Gnus

[Pierre Crescenzo]

Package: emacs24
Version: 24.3+1-3
Severity: normal

Hello,

I use with great pleasure, since a very long time, Gnus on Emacs (now 24) in
testing. Since some months/weeks, I have frequent "unable to get local issuer
certificate: accept? (y or n)" questions, for example to load some images from
some web sites (in Facebook mails for example, but not only).

I think this is a bug because I hadn't this question during years with Emacs
and Gnus (and w3m-el-snapshot).

Thank you in advance.

Best Regards,

Pierre Crescenzo



-- System Information:
Debian Release: jessie/sid
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages emacs24 depends on:
ii  emacs24-bin-common   24.3+1-3
ii  gconf-service3.2.6-2
ii  libasound2   1.0.27.2-4
ii  libatk1.0-0  2.12.0-1
ii  libc62.18-5
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libdbus-1-3  1.8.2-1
ii  libfontconfig1   2.11.0-5
ii  libfreetype6 2.5.2-1
ii  libgconf-2-4 3.2.6-2
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libgif4  4.1.6-11
ii  libglib2.0-0 2.40.0-3
ii  libgnutls26  2.12.23-15
ii  libgomp1 4.9.0-3
ii  libgpm2  1.20.4-6.1
ii  libgtk-3-0   3.12.2-1
ii  libice6  2:1.0.8-2
ii  libjpeg8 8d-2
ii  libm17n-01.6.4-2
ii  libmagickcore5   8:6.7.7.10+dfsg-1
ii  libmagickwand5   8:6.7.7.10+dfsg-1
ii  libotf0  0.9.13-1
ii  libpango-1.0-0   1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  libpng12-0   1.2.50-1
ii  librsvg2-2   2.40.2-1
ii  libselinux1  2.3-1
ii  libsm6   2:1.2.1-2
ii  libtiff5 4.0.3-8
ii  libtinfo55.9+20140118-1
ii  libx11-6 2:1.6.2-2
ii  libxft2  2.3.1-2
ii  libxml2  2.9.1+dfsg1-3
ii  libxpm4  1:3.5.10-1
ii  libxrender1  1:0.9.8-1
ii  zlib1g   1:1.2.8.dfsg-1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
ii  emacs24-common-non-dfsg  24.3+1-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748953: blktap-dkms: Struct bio was changed in 3.14 breaking build

[Bob Ball]

Fixed package attached - I'll submit the patch in a minute.

Bob

> -Original Message-
> From: Antony Messerli [mailto:amess...@rackspace.com]
> Sent: 22 May 2014 17:15
> To: Debian Bug Tracking System
> Subject: Bug#748953: blktap-dkms: Struct bio was changed in 3.14 breaking
> build
> 
> Package: blktap-dkms
> Version: 2.0.93-0.2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> The build fails on 3.14 kernel with the following error:
> 
> /var/lib/dkms/blktap/2.0.93/build/ring.c: In function
> ‘blktap_ring_make_tr_request’:
> /var/lib/dkms/blktap/2.0.93/build/ring.c:314:32: error: ‘struct bio’ has no
> member named ‘bi_sector’
>   breq->u.tr.sector_number = bio->bi_sector;
> ^
> Struct bio was changed by commit
> https://github.com/torvalds/linux/commit/4f024f3797c43cb4b73cd2c50cec7
> 28842d0e49e
> 
> Changing bio->bi_sector; to bio->bi_iter.bi_sector; allows the module to
> compile.
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.14-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
> 
> Versions of packages blktap-dkms depends on:
> ii  dkms2.2.0.3-1.2
> ii  libc6-dev   2.18-5
> ii  linux-libc-dev  3.14.4-1
> 
> Versions of packages blktap-dkms recommends:
> ii  linux-headers-amd64  3.14+57
> 
> blktap-dkms suggests no packages.
> 
> -- no debconf information


blktap-dkms_2.0.93-0.3_amd64.deb
Description: blktap-dkms_2.0.93-0.3_amd64.deb

Bug#749015: postgresql-9.3-postgis-2.1: Upgrade fails with liblwgeom-2.1.3.so conflict

[Sebastiaan Couwenberg]

Hi Ben,

Thanks for reporting this issue.

This same issue was also reported by Ralf Treinen in #749030, so I've
merged your two bugs.

The liblwgeom-2.1.3 package is fixed using Breaks/Replaces by Markus
Wanner in git, and is pending upload.

Kind Regards,

Bas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748925: open/save dialog doesn't react to keyboard

[VA]

close 748925
thanks

After upgrading libgtk-3-0 and libgail-3-0, the bug disappeared


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#746916: soprano: ftbfs with GCC-4.9

[sphinx jiang]

Dear maintainer,
Please consider applying attached patch to resolve FTBFS with gcc-4.9.

All the best
Sphinx
diff -Nru soprano-2.9.4+dfsg/debian/changelog soprano-2.9.4+dfsg/debian/changelog
--- soprano-2.9.4+dfsg/debian/changelog	2013-11-04 15:13:52.0 +
+++ soprano-2.9.4+dfsg/debian/changelog	2014-05-23 10:41:04.0 +
@@ -1,3 +1,9 @@
+soprano (2.9.4+dfsg-1+mips64el) UNRELEASED; urgency=medium
+
+  * Update symbols file for mips64el architecture.
+
+ -- Sphinx Jiang   Fri, 23 May 2014 09:39:10 +
+
 soprano (2.9.4+dfsg-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru soprano-2.9.4+dfsg/debian/libsoprano4.symbols soprano-2.9.4+dfsg/debian/libsoprano4.symbols
--- soprano-2.9.4+dfsg/debian/libsoprano4.symbols	2013-11-04 15:13:52.0 +
+++ soprano-2.9.4+dfsg/debian/libsoprano4.symbols	2014-05-23 10:40:56.0 +
@@ -3,8 +3,6 @@
 * Build-Depends-Package: libsoprano-dev
  (optional=external)_Z5qHashRK4QUrl@Base 2.1.67
  _ZN7Soprano10BindingSet6insertERK7QStringRKNS_4NodeE@Base 2.1.1
- (optional=private)_ZN7Soprano10BindingSet7PrivateD1Ev@Base 2.7.6
- (optional=private)_ZN7Soprano10BindingSet7PrivateD2Ev@Base 2.7.6
  _ZN7Soprano10BindingSet7replaceERK7QStringRKNS_4NodeE@Base 2.2.69
  _ZN7Soprano10BindingSet7replaceEiRKNS_4NodeE@Base 2.2.69
  _ZN7Soprano10BindingSetC1ERKS0_@Base 2.1.1
@@ -1163,9 +1161,6 @@
  _ZN7Soprano5Query20BooleanSetExpression7PrivateD2Ev@Base 2.1.1
  _ZN7Soprano5Query20BooleanSetExpressionC1Ev@Base 2.1.1
  _ZN7Soprano5Query20BooleanSetExpressionC2Ev@Base 2.1.1
- _ZN7Soprano5Query20BooleanSetExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query20BooleanSetExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query20BooleanSetExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query20NumericalGreaterThanC1EPNS0_19NumericalExpressionES3_@Base 2.1.1
  _ZN7Soprano5Query20NumericalGreaterThanC2EPNS0_19NumericalExpressionES3_@Base 2.1.1
  _ZN7Soprano5Query20NumericalGreaterThanD0Ev@Base 2.7.0
@@ -1196,9 +1191,6 @@
  _ZN7Soprano5Query22UnaryBooleanExpression7PrivateD2Ev@Base 2.1.1
  _ZN7Soprano5Query22UnaryBooleanExpressionC1EPNS0_17BooleanExpressionE@Base 2.1.1
  _ZN7Soprano5Query22UnaryBooleanExpressionC2EPNS0_17BooleanExpressionE@Base 2.1.1
- _ZN7Soprano5Query22UnaryBooleanExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query22UnaryBooleanExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query22UnaryBooleanExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query23queryLanguageFromStringERK7QString@Base 2.1.1
  _ZN7Soprano5Query24DateTimeGreaterThanEqualC1ERK9QDateTimeS4_@Base 2.1.1
  _ZN7Soprano5Query24DateTimeGreaterThanEqualC2ERK9QDateTimeS4_@Base 2.1.1
@@ -1214,9 +1206,6 @@
  _ZN7Soprano5Query24UnaryNumericalExpression7PrivateD2Ev@Base 2.1.1
  _ZN7Soprano5Query24UnaryNumericalExpressionC1EPNS0_19NumericalExpressionE@Base 2.1.1
  _ZN7Soprano5Query24UnaryNumericalExpressionC2EPNS0_19NumericalExpressionE@Base 2.1.1
- _ZN7Soprano5Query24UnaryNumericalExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query24UnaryNumericalExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query24UnaryNumericalExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC1EPNS0_5RTermE@Base 2.1.1
  _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC1ERKS2_@Base 2.1.1
  _ZN7Soprano5Query24UnaryRTermExpressionBase7PrivateC2EPNS0_5RTermE@Base 2.1.1
@@ -1236,9 +1225,6 @@
  _ZN7Soprano5Query25BinaryNumericalExpression9setSecondEPNS0_19NumericalExpressionE@Base 2.1.1
  _ZN7Soprano5Query25BinaryNumericalExpressionC1EPNS0_19NumericalExpressionES3_@Base 2.1.1
  _ZN7Soprano5Query25BinaryNumericalExpressionC2EPNS0_19NumericalExpressionES3_@Base 2.1.1
- _ZN7Soprano5Query25BinaryNumericalExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query25BinaryNumericalExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query25BinaryNumericalExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query25NumericalGreaterThanEqualC1EPNS0_19NumericalExpressionES3_@Base 2.1.1
  _ZN7Soprano5Query25NumericalGreaterThanEqualC2EPNS0_19NumericalExpressionES3_@Base 2.1.1
  _ZN7Soprano5Query25NumericalGreaterThanEqualD0Ev@Base 2.7.0
@@ -1246,14 +1232,8 @@
  _ZN7Soprano5Query25NumericalGreaterThanEqualD2Ev@Base 2.7.0
  _ZN7Soprano5Query26UnaryRTermStringExpressionC1EPNS0_5RTermE@Base 2.1.1
  _ZN7Soprano5Query26UnaryRTermStringExpressionC2EPNS0_5RTermE@Base 2.1.1
- _ZN7Soprano5Query26UnaryRTermStringExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query26UnaryRTermStringExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query26UnaryRTermStringExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query27UnaryRTermBooleanExpressionC1EPNS0_5RTermE@Base 2.1.1
  _ZN7Soprano5Query27UnaryRTermBooleanExpressionC2EPNS0_5RTermE@Base 2.1.1
- _ZN7Soprano5Query27UnaryRTermBooleanExpressionD0Ev@Base 2.7.0
- _ZN7Soprano5Query27UnaryRTermBooleanExpressionD1Ev@Base 2.7.0
- _ZN7Soprano5Query27UnaryRTermBooleanExpressionD2Ev@Base 2.7.0
  _ZN7Soprano5Query28BinaryRTermBooleanExpression7PrivateC1EPNS0_5RTermES4_@Base 2.1.1
  _ZN7Soprano5Query28BinaryRTermBooleanExpression7PrivateC1ERKS2_@Base 2.1.1
  _ZN7Soprano5Query28BinaryRTermBooleanExpression7Priv

Bug#720083: reportbug: Gtk interface, when gathering system information, has prompts in the terminal causing hang

[Jürgen Kleber]

It's all the same with reportbug_version "6.5.0" / Debian Sid /
linux-image-3.14-1-amd64.

Bug#749041: topgit: New upstream release and new homepage

[Antonio Ospite]

Package: topgit
Version: 0.8-1.1
Severity: wishlist

Dear Maintainer,

topgit upstream is now at 0.9 and it also changed its homepage, the
upstream is now at: https://github.com/greenrd/topgit

You can confirm the new upstream location by looking at a note in the
previous homepage: http://repo.or.cz/w/topgit.git

Any chance you want to package the new version? I may be able to help.

Thanks,
   Antonio

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

Kernel: Linux 3.15.0-rc4-ao2 (SMP w/1 CPU core)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages topgit depends on:
ii  git [git-core]  1:2.0.0~rc4-1
ii  git-core1:2.0.0~rc4-1

topgit recommends no packages.

Versions of packages topgit suggests:
ii  git-email  1:2.0.0~rc4-1
ii  make   4.0-7
ii  quilt  0.63-2

-- no debconf information
-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Johannes Schauer]

Package: dpkg
Version: 1.17.9
Severity: wishlist
Tags: patch

Hi,

dpkg produces an unnecessary whitespace after the fieldname of multiline
fields. Not having this extra whitespace would save 16kb of an
uncompressed Sources file.

Here is a simple patch and updated testcase:

diff --git a/scripts/Dpkg/Control/HashCore.pm b/scripts/Dpkg/Control/HashCore.pm
index 6d6f1c5..155c8ce 100644
--- a/scripts/Dpkg/Control/HashCore.pm
+++ b/scripts/Dpkg/Control/HashCore.pm
@@ -358,12 +358,18 @@ sub output {
$value .= "\n $_";
}
}
+# do not print a trailing space if value starts with a newline
+if ($value =~ /^\n/) {
+$value = "$key:$value\n";
+} else {
+$value = "$key: $value\n";
+}
# Print it out
 if ($fh) {
-   print { $fh } "$key: $value\n"
+   print { $fh } $value
or syserr(_g('write error on control data'));
 }
-   $str .= "$key: $value\n" if defined wantarray;
+   $str .= $value if defined wantarray;
}
 }
 return $str;
diff --git a/scripts/t/Dpkg_Changelog.t b/scripts/t/Dpkg_Changelog.t
index 43bccea..d6372a2 100644
--- a/scripts/t/Dpkg_Changelog.t
+++ b/scripts/t/Dpkg_Changelog.t
@@ -173,7 +173,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld 
 Date: Sun, 13 Jan 2008 15:49:19 +0100
 Closes: 100 111 222
-Changes: 
+Changes:
  fields (2.0-0etch1) stable; urgency=low
  .
* Upload to stable (Closes: #111, #222)
@@ -214,7 +214,7 @@ Urgency: medium
 Maintainer: Frank Lichtenheld 
 Date: Sun, 12 Jan 2008 15:49:19 +0100
 Closes: 111 222
-Changes: 
+Changes:
  fields (2.0-1) unstable  frozen; urgency=medium
  .
[ Frank Lichtenheld ]
@@ -244,7 +244,7 @@ Distribution: unstable
 Urgency: low
 Maintainer: Frank Lichtenheld 
 Date: Sun, 11 Jan 2008 15:49:19 +0100
-Changes: 
+Changes:
  fields (2.0~b1-1) unstable; urgency=low,xc-userfield=foobar
  .
* Beta
@@ -257,7 +257,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld 
 Date: Sun, 10 Jan 2008 15:49:19 +0100
 Closes: 100
-Changes: 
+Changes:
  fields (1.0) experimental; urgency=high,xb-userfield2=foobar
  .
* First upload (Closes: #100)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749043: O: freecraft -- Realtime fantasy strategy game for Unix and X

[René Mayorga]

Package: wnpp
Severity: normal

The current maintainer of freecraft, Lincoln de Sousa Primo Clarete 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: freecraft
Binary: freecraft, freecraft-dbg
Version: 1:1.20-1.1
Maintainer: Lincoln de Sousa Primo Clarete 
Build-Depends: libx11-dev, libxext-dev, libsdl1.2-dev (>> 1.2.2), 
libsdl1.2debian, libpng12-dev, libbz2-dev, debhelper (>= 7.0.50~), pkg-config
Architecture: any
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 aa167f1e83c81b531087c4a2263e9128 1993 freecraft_1.20-1.1.dsc
 d86a8d52ccf5549ef576578bd18c36eb 1346245 freecraft_1.20.orig.tar.gz
 c845551ff670ce73016b120a94992fea 12907 freecraft_1.20-1.1.debian.tar.gz
Vcs-Browser: http://git.comum.org/gitweb.cgi?p=lincoln/debian/freecraft.git
Vcs-Git: http://git.comum.org/lincoln/debian/freecraft.git
Checksums-Sha1:
 6dd9a9df7736870886f2feddd710dbd4042dd2f3 1993 freecraft_1.20-1.1.dsc
 a3915de9f346a2357fdaf39badf55ae8b8fb43a5 1346245 freecraft_1.20.orig.tar.gz
 94689c0d929d0cc11e82a6daa4c216ac038ba995 12907 freecraft_1.20-1.1.debian.tar.gz
Checksums-Sha256:
 dd9a30d4a44a79ce1729e18cb5360ecadda1286eb4250f5c7e716cf127f84bd7 1993 
freecraft_1.20-1.1.dsc
 8336ff3ce962ef384f2f55a62050eb610f51924017e8920c8bb30194d9b7c2c9 1346245 
freecraft_1.20.orig.tar.gz
 b7745dc247f8acf6a9d7ab06fe45e91ff02cb98e8f06b08a5e298c572106d7a2 12907 
freecraft_1.20-1.1.debian.tar.gz
Package-List: 
 freecraft deb games optional
 freecraft-dbg deb debug extra
Directory: pool/main/f/freecraft
Priority: source
Section: games

Package: freecraft
Version: 1:1.20-1.1
Installed-Size: 1297
Maintainer: Lincoln de Sousa Primo Clarete 
Architecture: i386
Depends: fcmp (>= 1.18.20030306-1), libbz2-1.0, libc6 (>= 2.3), libpng12-0 (>= 
1.2.13-4), libsdl1.2debian (>= 1.2.11), libx11-6, zlib1g (>= 1:1.1.4)
Description-en: Realtime fantasy strategy game for Unix and X
 FreeCraft is a clone of the realtime fantasy strategy game WarCraft II
 from Blizzard Entertainment, although it could be used to build other
 games similar to C&C or AoE. It is nearly feature complete compared to
 the original game, and includes a handful of Neat New Features, such as
 queuing peon/fighter production, finding out idle workers, and a completely
 new AI. It also has network connectivity for up to 16 players.
 .
 FreeCraft is not maintained by the upstream anymore, this is the last
 stable version of FreeCraft.
 .
 This version is compiled with some of the possible options, and thus has
 gzip, bunzip2 and SDL support (the last one only for i386 arches). The
 sound options will depend on your personal election on SDL packages.
Description-md5: 54884279f6f66f79873750a522e68932
Tag: uitoolkit::sdl
Section: games
Priority: optional
Filename: pool/main/f/freecraft/freecraft_1.20-1.1_i386.deb
Size: 583540
MD5sum: fd19837c1b4b0e1c4248994449728392
SHA1: cd60ce7206197826d3d1bd4fa955148f01a3997d
SHA256: 9f7fad4ff1465c518d907f14024486bc51a3479e4c7c6dc261e07fcbd42fcb3f

Package: freecraft-dbg
Source: freecraft
Version: 1:1.20-1.1
Installed-Size: 3365
Maintainer: Lincoln de Sousa Primo Clarete 
Architecture: i386
Depends: freecraft
Description-en: Realtime fantasy strategy game - Debugging simbols
 FreeCraft is a clone of the realtime fantasy strategy game WarCraft II
 from Blizzard Entertainment, although it could be used to build other
 games similar to C&C or AoE. It is nearly feature complete compared to
 the original game, and includes a handful of Neat New Features, such as
 queuing peon/fighter production, finding out idle workers, and a completely
 new AI. It also has network connectivity for up to 16 players.
 .
 This package contains unstripped binaries used for debugging.
Description-md5: 3a0c6765ce5511cd3d29a182ef01933b
Section: debug
Priority: extra
Filename: pool/main/f/freecraft/freecraft-dbg_1.20-1.1_i386.deb
Size: 1287784
MD5sum: 120d74412d4fe87df991c9871ab2a8a0
SHA1: 472ec494596e19b867f8da81aa6d7c0207a814d9
SHA256: 7bddfec5d8fe27987b9f6005fa90fd2b91c18908614e09c02263d81d4bb98efa



signature.asc
Description: Digital signature

Bug#749042: O: fcmp -- Free media files for FreeCraft

[René Mayorga]

Package: wnpp
Severity: normal

The current maintainer of fcmp, Lincoln de Sousa ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: fcmp
Binary: fcmp
Version: 1.18.20030311-3
Maintainer: Lincoln de Sousa 
Build-Depends: debhelper (>= 7.0.50~)
Architecture: all
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 1b68c1ca483135787501d3dccfb15144 1782 fcmp_1.18.20030311-3.dsc
 b770c20b2088687d81116f1361d2193d 8339841 fcmp_1.18.20030311.orig.tar.gz
 d1b8a5d9bbacf969cf286e948a99323f 4034 fcmp_1.18.20030311-3.debian.tar.gz
Vcs-Browser: http://git.comum.org/gitweb.cgi?p=lincoln/debian/fcmp.git
Vcs-Git: http://git.comum.org/lincoln/debian/fcmp.git
Checksums-Sha1:
 1f05ccd6075964aceb0bdae5ed92980ff54b1d3c 1782 fcmp_1.18.20030311-3.dsc
 3c3bdd4fdd03eb6240b5e597cb33e8ab95c142a4 8339841 fcmp_1.18.20030311.orig.tar.gz
 4ffc61a168dc7506260b341136143bbf400d6e48 4034 
fcmp_1.18.20030311-3.debian.tar.gz
Checksums-Sha256:
 52742fa0bd89c1200c29bea4bf44e4827837257c58f17e0ecad7de7a4567b094 1782 
fcmp_1.18.20030311-3.dsc
 0a2bf970f071e81ad4c23c151a1feb3599a5925844868d565f73fec35c6621e4 8339841 
fcmp_1.18.20030311.orig.tar.gz
 4b25713c47349b6fa9dd9a1cab2e5ffdbab8f2b9d7eb0eb262b7583f410af105 4034 
fcmp_1.18.20030311-3.debian.tar.gz
Directory: pool/main/f/fcmp
Priority: source
Section: games

Package: fcmp
Version: 1.18.20030311-3
Installed-Size: 13428
Maintainer: Lincoln de Sousa 
Architecture: all
Recommends: freecraft (>= 1:1.18)
Description-en: Free media files for FreeCraft
 These are a set of free sounds and graphics for FreeCraft, a clone of
 the realtime fantasy strategy game, WarCraft II, from Blizzard
 Entertainment.
 .
 Note that this version contains almost all the files needed for a fair
 game experience, and has not anything to do with WarCraft II data (in fact
 spoofs it), as it's completely free.
 .
 This is the last stable snapshot from the FcMP website.
Description-md5: 4dd3d9307a152e990478409111530440
Section: games
Priority: optional
Filename: pool/main/f/fcmp/fcmp_1.18.20030311-3_all.deb
Size: 8370700
MD5sum: 3612ceb89a324848bb9b7cb23f514f6f
SHA1: 9780d9b727f76593058d3b4f6b46d2ec89e7ae8d
SHA256: 1b733275ec22279e088ba2d707ea0468f8f8ac24789b7afd2d69caa41aea5c88



signature.asc
Description: Digital signature

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Guillem Jover]

Hi!

On Fri, 2014-05-23 at 13:23:33 +0200, Johannes Schauer wrote:
> Package: dpkg
> Version: 1.17.9
> Severity: wishlist
> Tags: patch

> dpkg produces an unnecessary whitespace after the fieldname of multiline
> fields. Not having this extra whitespace would save 16kb of an
> uncompressed Sources file.

Yeah, that has bothered me for a while, had pending on fixing it,
thanks!

> Here is a simple patch and updated testcase:

I'm merging this now for 1.17.10, although I think I'll be changing it
a bit, as it seems it could be done in a different way.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749047: haskell-network-info: FTBFS on hurd-i386

[Samuel Thibault]

Source: haskell-network-info
Version: 0.2.0.3-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

haskell-network-info FTBFS on hurd-i386 because it assumes that
non-Linux systems have if_dl.h, but hurd-i386 doesn't. The attached
patch fixes it.

Samuel

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

Kernel: Linux 3.14.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Samuel
 N: j'aime bien Cut d'un truc enorme... ca montre de quel cote de l'ecran 
sont les couilles :)))
 -+- #ens-mim et la peufeupeu -+-
--- haskell-network-info-0.2.0.3/cbits/network-unix.c.original  2014-05-23 
13:33:44.0 +0200
+++ haskell-network-info-0.2.0.3/cbits/network-unix.c   2014-05-23 
13:36:24.0 +0200
@@ -12,8 +12,10 @@
 #else
 #   include 
 #   include 
+#   ifndef __GNU__
 #   include 
-#   define AF_PACKET AF_LINK
+#   define AF_PACKET AF_LINK
+#   endif
 #endif
 
 #ifdef __FreeBSD__
@@ -24,6 +26,7 @@
 #include "common.h"
 
 
+#ifdef AF_PACKET
 void maccopy(unsigned char *dst, struct sockaddr *addr)
 {
 #ifdef __linux__
@@ -35,6 +38,7 @@
 memcpy(dst, sdl->sdl_data + sdl->sdl_nlen, MAC_SIZE);
 #endif
 }
+#endif
 
 struct network_interface *add_interface(struct network_interface *ns, const 
wchar_t *name, int max_ns)
 {
@@ -98,8 +102,10 @@
 ipv4copy(&n->ip_address, addr);
 } else if (family == AF_INET6) {
 ipv6copy(&n->ip6_address, addr);
+#ifdef AF_PACKET
 } else if (family == AF_PACKET) {
 maccopy(n->mac_address, addr);
+#endif
 }
 }
 

Bug#748903: python-tornado: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2014-05-22 at 22:49 +0200, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2014-05-22 at 09:20:59 +0200, Svante Signell wrote:
> > Source: python-tornado
> > Version: 3.2.0-1
> > Severity: important
> > Tags: patch
> > User: debian-h...@lists.debian.org
> > Usertags: hurd
> 
> > Currently python-tornado fails to build from source on GNU/Hurd due to
> > two failed tests: test_unix_socket and test_unix_socket_bad_request.
> > The attached patch fixes these failures by not using the options 
> > SO_REUSEADDR for setsockopt in tornado/netutil.py and SO_ERROR for
> > getsockopt in tornado/iostream.py since they are not yet implemented.
...
> 
> I've not verified but if sock.setsockopt is mostly a wrapper on top of
> the POSIX function, then it would be way better to check if errno is
> ENOPROTOOPT, and ignore the error condition then. Which would make the
> code not GNU/Hurd specific, would also start testing those flags once
> they are implemented, and might also help any other system where those
> SO_* flags are not implemented yet.

Updated path, renamed to sockopt.patch. Test built on GNU/Hurd and
GNU/Linux. Better now?
Index: python-tornado-3.2.0/tornado/netutil.py
===
--- python-tornado-3.2.0.orig/tornado/netutil.py
+++ python-tornado-3.2.0/tornado/netutil.py
@@ -119,7 +119,11 @@ if hasattr(socket, 'AF_UNIX'):
 """
 sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
 set_close_exec(sock.fileno())
-sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+try:
+sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+except socket.error as e:
+if e.args[0] != errno.ENOPROTOOPT:
+raise
 sock.setblocking(0)
 try:
 st = os.stat(file)
Index: python-tornado-3.2.0/tornado/iostream.py
===
--- python-tornado-3.2.0.orig/tornado/iostream.py
+++ python-tornado-3.2.0/tornado/iostream.py
@@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
 self._add_io_state(self.io_loop.WRITE)
 
 def _handle_connect(self):
-err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+try:
+err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+except socket.error as e:
+if e.args[0] == errno.ENOPROTOOPT:
+err = 0
 if err != 0:
 self.error = socket.error(err, os.strerror(err))
 # IOLoop implementations may vary: some of them return

Bug#749048: pkg-config: Use /usr/lib/pkgconfig in cross-builds on Ubuntu

[Dimitri John Ledkov]

Package: pkg-config
Version: 0.28-1
Severity: normal
Tags: patch

Dear maintainer,

In Ubuntu, we regularly cross-build a lot of packages, which does rely
on cross-building against non-multiarched libraries. All builds are
done in clean chroots & this has not raised an issue before.

Regards,

Dimitri.

diff -u pkg-config-0.28/debian/changelog pkg-config-0.28/debian/changelog
--- pkg-config-0.28/debian/changelog
+++ pkg-config-0.28/debian/changelog
@@ -1,3 +1,12 @@
+pkg-config (0.28-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * On Ubuntu, in pkg-config-crosswrapper add /usr/lib/pkgconfig to
+PKG_CONFIG_LIBDIR. As a lot of packages that are cross-build on
+regular basis rely on cross-building with non-multiarched libraries.
+
+ -- Dimitri John Ledkov   Fri, 23 May 2014 12:46:55 +0100
+
 pkg-config (0.28-1) unstable; urgency=medium
 
   * New upstream release.  (Closes: #699476, #744031)
diff -u pkg-config-0.28/debian/control pkg-config-0.28/debian/control
--- pkg-config-0.28/debian/control
+++ pkg-config-0.28/debian/control
@@ -9,7 +9,7 @@
 Package: pkg-config
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, dpkg-dev
 Description: manage compile and link flags for libraries
  pkg-config is a system for managing library compile and link flags that 
  works with automake and autoconf.
diff -u pkg-config-0.28/debian/pkg-config-crosswrapper 
pkg-config-0.28/debian/pkg-config-crosswrapper
--- pkg-config-0.28/debian/pkg-config-crosswrapper
+++ pkg-config-0.28/debian/pkg-config-crosswrapper
@@ -28,7 +28,11 @@
   # If you want to allow use of un-multiarched -dev packages for crossing 
   # (at the risk of finding build-arch stuff you didn't want, if not in a 
clean chroot)
   # Uncomment the next line:
-  # PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/lib/pkgconfig" 
+  # PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/lib/pkgconfig"
+  # ... but on Ubuntu we rely cross-building with non-multiarch libraries:
+  if dpkg-vendor --derives-from Ubuntu; then
+  PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/lib/pkgconfig"
+  fi
   PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/share/pkgconfig"
 
   export PKG_CONFIG_LIBDIR


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749049: RM: kwwidgets -- RoQA; orphaned; RC-buggy; abandoned upstream

[Mathieu Malaterre]

Package: ftp.debian.org

KWWidgets is a legacy software that is currently abandoned upstream
(used in VolView and old Slicer releases).
So please remove KWWidgets from all debian archives.

VolView has been previously removed (#745023), and slicer is only
available on oldstable.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749050: RM: vtkedge -- RoQA; orphaned; RC-buggy; abandoned upstream

[Mathieu Malaterre]

Package: ftp.debian.org

vtkedge is a legacy software that is currently abandoned upstream
(used in VolView and old Slicer releases).
So please remove vtkedge from all debian archives.

VolView has been previously removed (#745023), and slicer is only
available on oldstable.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748903: python-tornado: FTBFS on hurd-i386

[Samuel Thibault]

Svante Signell, le Fri 23 May 2014 13:45:50 +0200, a écrit :
> Index: python-tornado-3.2.0/tornado/iostream.py
> ===
> --- python-tornado-3.2.0.orig/tornado/iostream.py
> +++ python-tornado-3.2.0/tornado/iostream.py
> @@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
>  self._add_io_state(self.io_loop.WRITE)
>  
>  def _handle_connect(self):
> -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> +try:
> +err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> +except socket.error as e:
> +if e.args[0] == errno.ENOPROTOOPT:
> +err = 0
>  if err != 0:
>  self.error = socket.error(err, os.strerror(err))
>  # IOLoop implementations may vary: some of them return

But if it's another error, err and self.error will not be set. Rather
use:

@@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
 self._add_io_state(self.io_loop.WRITE)
 
 def _handle_connect(self):
-err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+try:
+err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+except socket.error as e:
+err = e.args[0]
+if err == errno.ENOPROTOOPT:
+err = 0
 if err != 0:
 self.error = socket.error(err, os.strerror(err))
 # IOLoop implementations may vary: some of them return

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749051: src:confuse: use dh-autoreconf to fix FTBFS on ppc64el

[Erwan Prioul]

Package: src:confuse
Version: 2.7-4
Severity: normal
Tags: patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, 
a full autoreconf is necessary. This is because we need new libtool 
macros for ppc64el.


In Ubuntu, the attached patch was applied to achieve the following:

 * Build with dh-autoreconf instead of autotools-dev for new libtool.

Thanks for considering the patch.

Erwan Prioul.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.13-1-powerpc64le (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

--- a/debian/rules
+++ b/debian/rules
@@ -22,12 +22,7 @@ endif
 
 config.status: configure
 	dh_testdir
-
-	-test -r /usr/share/misc/config.sub && \
-	cp -f /usr/share/misc/config.sub support/config.sub
-	-test -r /usr/share/misc/config.guess && \
-	cp -f /usr/share/misc/config.guess support/config.guess
-	
+	dh_autoreconf	
 	CFLAGS="$(CFLAGS)" ./configure \
 			--enable-shared \
 			--host=$(DEB_HOST_GNU_TYPE) \
@@ -61,7 +56,7 @@ clean:
 	dh_testroot
 	rm -f build-stamp 
 	[ ! -f Makefile ] || $(MAKE) distclean
-	rm -f support/config.sub support/config.guess
+	dh_autoreconf_clean
 	dh_clean 
 
 install: build
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Aurelien Jarno 
-Build-Depends: debhelper (>= 8.1.3), autotools-dev, pkg-config
+Build-Depends: debhelper (>= 8.1.3), dh-autoreconf, pkg-config
 Standards-Version: 3.9.2
 Homepage: http://www.nongnu.org/confuse/
 

Bug#749052: apt-cacher: Separate direct and HTTP-proxied access to different origin servers (repositories/mirrors)

[Jim Klimov]

Package: apt-cacher
Version: 1.7.6
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

We are rolling out an Emdebian-based project in a LAN with weak internet
connectivity, so caching of packages is a substantial requirement for fast
redeployments of our test images. Apt-cacher was shown to be a pretty good
fit for our usecase, though with a nit...

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

While exploring our options, we brought over mirrors of (Em)Debian
repositories and deployed as local mirrors. There is also a corporate HTTP
proxy to access the internet for i.e. updates.
It is possible to configure a "localhost" or otherwise local server as a
backend server for a source (via "path_map") and use it if "use_proxy=0".
However, the internet sources are not accessible because explicit use of
the proxy is required by corporate networking.
It is possible to configure the internet sources like "ftp.XYZ.debian.org"
as backend servers for the sources and access them with "use_proxy=1".
However, the local (faster) mirrors of available packages, as well as
origin repositories of our own development, are thus inaccessible for
apt-cacher - because the corporate proxy does not relay those local
resources (hosted on each developer's "localhost" in the extreme case - and
obviously resolving to a different system by the corporate proxy server).

   * What was the outcome of this action?

We could not simultaneously configure to use some sources accessible only
without an HTTP proxy and some requiring one.
For developer notebooks that travel from corporate to open networks and
back, it would also be very beneficial to have dual access attempts (with
and without proxy) to some but not all resources (internet origin servers).

   * What outcome did you expect instead?

Accessibility of both local (direct) and internet (proxied and/or direct)
origin repository servers with a single configuration of apt-cacher.
It is my understanding that at the moment this separate approach is not
catered for. I believe a proper solution would be to add lists of backend
hosts that should or should not be accessed with an http_proxy, and it
should be valid to have a host listed in both lists (with both ways tried
in this case, if the first attempt over whichever transport fails).

contact: jimkli...@gmail.com

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


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

Kernel: Linux 3.2.0-4-686-pae (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

Versions of packages apt-cacher depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.10
ii  ed 1.6-2
ii  libfilesys-df-perl 0.92-4+b1
ii  libfreezethaw-perl 0.5001-1
ii  libio-interface-perl   1.06-1+b1
ii  libnetaddr-ip-perl 4.062+dfsg-1
ii  libsys-syscall-perl0.23-1
ii  libwww-curl-perl   4.15-1+b2
ii  libwww-perl6.04-1
ii  lsb-base   4.1+Debian8
ii  perl   5.14.2-21+deb7u1
ii  ucf3.0025+nmu3
ii  update-inetd   4.43

Versions of packages apt-cacher recommends:
ii  libberkeleydb-perl  0.51-1

Versions of packages apt-cacher suggests:
pn  libio-socket-inet6-perl  

-- debconf information:
* apt-cacher/mode: daemon

Bug#636783: TC casting vote

[Paul R. Tagliamonte]

(Or having to abstain from a vote)
On May 23, 2014 4:45 AM, "Svante Signell"  wrote:

> On Fri, 2014-05-23 at 09:52 +0200, Lucas Nussbaum wrote:
> > On 23/05/14 at 09:42 +0200, Svante Signell wrote:
> > > On Fri, 2014-05-23 at 08:32 +0200, Lucas Nussbaum wrote:
> > > >
> > > The solution is simple: Have an odd number of members in the TC. Then
> no
> > > casting vote is needed at all.
> >
> > No, one can rank two options at the same level.
>
> Then add to the rules that doing that is forbidden. Or count the number
> of TC members voting on the two problematic options and choose the one
> having most votes. (the only remaining problem the would be that all TC
> members rank two options equal: this probability would be very small)
>
>
> --
> To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/1400834527.17164.9.ca...@g3620.my.own.domain
>
>

Bug#749047: [Pkg-haskell-maintainers] Bug#749047: haskell-network-info: FTBFS on hurd-i386

[Joachim Breitner]

Control: forwarded -1 https://github.com/jystic/network-info/issues/9
Control: tag -1 upstream

Hi,

Am Freitag, den 23.05.2014, 13:38 +0200 schrieb Samuel Thibault:
> haskell-network-info FTBFS on hurd-i386 because it assumes that
> non-Linux systems have if_dl.h, but hurd-i386 doesn't. The attached
> patch fixes it.

thanks. I forwarded it upstream.

We are currently waiting for the Haskell packages to age, so I won’t
upload it to unstable the next 10 days. Feel free to ping me again
later, though.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#735248: NMU debdiff for cmake_2.8.12.1-1.3

[Aníbal Monsalve Salazar]

Hello Modestas,

Please find below the NMU debdiff for cmake_2.8.12.1-1.3. It fixes a
regression that blocks #685112.

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

Regards,

Aníbal
-- 
anibal.monsalvesala...@imgtec.com

debdiff cmake_2.8.12.1-1.2.dsc cmake_2.8.12.1-1.3.dsc
diff -Nru cmake-2.8.12.1/debian/changelog cmake-2.8.12.1/debian/changelog
--- cmake-2.8.12.1/debian/changelog 2014-03-30 21:20:33.0 +0100
+++ cmake-2.8.12.1/debian/changelog 2014-05-23 09:26:23.0 +0100
@@ -1,3 +1,12 @@
+cmake (2.8.12.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * multiarch-python-include-dirs.diff has bad side-effects
+Drop multiarch-python-include-dirs.diff
+Closes: #735248
+
+ -- Anibal Monsalve Salazar   Fri, 23 May 2014 09:25:22 
+0100
+
 cmake (2.8.12.1-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru cmake-2.8.12.1/debian/patches/multiarch-python-include-dirs.diff 
cmake-2.8.12.1/debian/patches/multiarch-python-include-dirs.diff
--- cmake-2.8.12.1/debian/patches/multiarch-python-include-dirs.diff
2014-02-28 14:14:01.0 +
+++ cmake-2.8.12.1/debian/patches/multiarch-python-include-dirs.diff
1970-01-01 01:00:00.0 +0100
@@ -1,52 +0,0 @@
-Description: Python.h and pyconfig.h can be in different locations
-Author: Dmitrijs Ledkovs 
-Bug: http://public.kitware.com/Bug/view.php?id=14156
-Forwarded: yes
-Origin: vendor
-
 a/Modules/FindPythonLibs.cmake
-+++ b/Modules/FindPythonLibs.cmake
-@@ -136,6 +136,27 @@ foreach(_CURRENT_VERSION ${_Python_VERSI
-   
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
-   
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
- PATH_SUFFIXES
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}mu
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}m
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}u
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}
-+  python${_CURRENT_VERSION}mu
-+  python${_CURRENT_VERSION}m
-+  python${_CURRENT_VERSION}u
-+  python${_CURRENT_VERSION}
-+  )
-+
-+  find_path(PYTHON_INCLUDE_DIR2
-+NAMES pyconfig.h
-+PATHS
-+  ${PYTHON_FRAMEWORK_INCLUDES}
-+  
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
-+  
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
-+PATH_SUFFIXES
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}mu
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}m
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}u
-+  ${CMAKE_LIBRARY_ARCHITECTURE}/python${_CURRENT_VERSION}
-   python${_CURRENT_VERSION}mu
-   python${_CURRENT_VERSION}m
-   python${_CURRENT_VERSION}u
-@@ -162,13 +183,14 @@ mark_as_advanced(
-   PYTHON_DEBUG_LIBRARY
-   PYTHON_LIBRARY
-   PYTHON_INCLUDE_DIR
-+  PYTHON_INCLUDE_DIR2
- )
- 
- # We use PYTHON_INCLUDE_DIR, PYTHON_LIBRARY and PYTHON_DEBUG_LIBRARY for the
- # cache entries because they are meant to specify the location of a single
- # library. We now set the variables listed by the documentation for this
- # module.
--set(PYTHON_INCLUDE_DIRS "${PYTHON_INCLUDE_DIR}")
-+set(PYTHON_INCLUDE_DIRS "${PYTHON_INCLUDE_DIR}" "${PYTHON_INCLUDE_DIR2}")
- set(PYTHON_DEBUG_LIBRARIES "${PYTHON_DEBUG_LIBRARY}")
- 
- # These variables have been historically named in this module different from
diff -Nru cmake-2.8.12.1/debian/patches/series 
cmake-2.8.12.1/debian/patches/series
--- cmake-2.8.12.1/debian/patches/series2014-02-28 14:54:27.0 
+
+++ cmake-2.8.12.1/debian/patches/series2014-05-23 09:23:12.0 
+0100
@@ -1,7 +1,6 @@
 FindBoost_add_-lpthread_#563479.diff
 multiarch_findgtk2_fix.diff
 install_to_multiarch_libdir_on_kfreebsd_hurd.diff
-multiarch-python-include-dirs.diff
 qt_import_dir_variable.diff
 FindPHP4_fix_typo.diff
 FindJNI_amd64_ppc_biarch.diff


signature.asc
Description: Digital signature

Bug#748903: python-tornado: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2014-05-23 at 13:58 +0200, Samuel Thibault wrote:
> Svante Signell, le Fri 23 May 2014 13:45:50 +0200, a écrit :
> > Index: python-tornado-3.2.0/tornado/iostream.py
> > ===
> > --- python-tornado-3.2.0.orig/tornado/iostream.py
> > +++ python-tornado-3.2.0/tornado/iostream.py
> > @@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
> >  self._add_io_state(self.io_loop.WRITE)
> >  
> >  def _handle_connect(self):
> > -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> > +try:
> > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > socket.SO_ERROR)
> > +except socket.error as e:
> > +if e.args[0] == errno.ENOPROTOOPT:
> > +err = 0
> >  if err != 0:
> >  self.error = socket.error(err, os.strerror(err))
> >  # IOLoop implementations may vary: some of them return
> 
> But if it's another error, err and self.error will not be set. Rather
> use:
> 
> @@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
>  self._add_io_state(self.io_loop.WRITE)
>  
>  def _handle_connect(self):
> -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> +try:
> +err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> +except socket.error as e:
> +err = e.args[0]
> +if err == errno.ENOPROTOOPT:
> +err = 0
>  if err != 0:
>  self.error = socket.error(err, os.strerror(err))
>  # IOLoop implementations may vary: some of them return

I thoughts it did exactly the same before, indentation stops at err = 0,
i.e. outside the exception, so other errors are not affected. But I can
do as you wish, just let me know. Otherwise al else statement would be
needed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749027: The ClamAV daemon stops working.

[Jim Barber]

Sorry,

That last paragraph should have said that I fixed freshclam on the 20th 
May.

Not the 23rd.

So the sequence of events was the upgrade on the 19th; freshclam on the 
20th;

then the first hang on the 21st.

Regards,

Jim Barber


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749053: src:libvoikko: use dh-autoreconf to fix FTBFS on ppc64el

[Erwan Prioul]

Package: src:libvoikko
Version: 3.7-2
Severity: normal
Tags: patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, 
a full autoreconf is necessary. This is because we need new libtool 
macros for ppc64el.


In Ubuntu, the attached patch was applied to achieve the following:

 * Build-depend on pkg-config.
 * Build using dh-autoreconf.

Thanks for considering the patch.

Erwan Prioul.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.13-1-powerpc64le (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

--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: libvoikko
 Priority: optional
 Maintainer: Timo Jyrinki 
-Build-Depends: debhelper (>= 9.0.0), dpkg-dev (>= 1.13.19), autotools-dev, python (>= 2.6.6-3~), hardening-wrapper
+Build-Depends: debhelper (>= 9.0.0), dpkg-dev (>= 1.13.19), autotools-dev, python (>= 2.6.6-3~), hardening-wrapper, dh-autoreconf, pkg-config
 Standards-Version: 3.9.4
 Section: libs
 Homepage: http://voikko.puimula.org/
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,7 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-archi
 export DEB_BUILD_HARDENING=1
 
 %:
-	dh $@ --fail-missing --with python2
+	dh $@ --fail-missing --with python2,autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --with-dictionary-path=/usr/lib/voikko --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)

Bug#748903: python-tornado: FTBFS on hurd-i386

[Samuel Thibault]

Svante Signell, le Fri 23 May 2014 14:28:49 +0200, a écrit :
> On Fri, 2014-05-23 at 13:58 +0200, Samuel Thibault wrote:
> > Svante Signell, le Fri 23 May 2014 13:45:50 +0200, a écrit :
> > > Index: python-tornado-3.2.0/tornado/iostream.py
> > > ===
> > > --- python-tornado-3.2.0.orig/tornado/iostream.py
> > > +++ python-tornado-3.2.0/tornado/iostream.py
> > > @@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
> > >  self._add_io_state(self.io_loop.WRITE)
> > >  
> > >  def _handle_connect(self):
> > > -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> > > +try:
> > > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > socket.SO_ERROR)
> > > +except socket.error as e:
> > > +if e.args[0] == errno.ENOPROTOOPT:
> > > +err = 0
> > >  if err != 0:
> > >  self.error = socket.error(err, os.strerror(err))
> > >  # IOLoop implementations may vary: some of them return
> > 
> > But if it's another error, err and self.error will not be set. Rather
> > use:
> > 
> > @@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
> >  self._add_io_state(self.io_loop.WRITE)
> >  
> >  def _handle_connect(self):
> > -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> > +try:
> > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > socket.SO_ERROR)
> > +except socket.error as e:
> > +err = e.args[0]
> > +if err == errno.ENOPROTOOPT:
> > +err = 0
> >  if err != 0:
> >  self.error = socket.error(err, os.strerror(err))
> >  # IOLoop implementations may vary: some of them return
> 
> I thoughts it did exactly the same before, indentation stops at err = 0,
> i.e. outside the exception, so other errors are not affected.

Other exceptions (with different e.args[0]) will still be caught by
except. Those need to be handled too.

> But I can do as you wish, just let me know. Otherwise al else
> statement would be needed.

You can go with an else, yes, but it's simpler the way I proposed.

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748852: devscripts: sadt should allow to visualize output even when all tests passed

[Jakub Wilk]

Control: tags -1 + confirmed

Thanks for the bug report.

* Olivier Berger , 2014-05-21, 14:41:
Even with sadt -v, when tests succesfully pass, the standard outputs 
are captured and discarded.


It should be possible to nevertheless have access to them for debugging 
purposes (messages on skipped tests, etc.).


I agree that such a feature would be desirable.

(When I originally wrote sadt, I stole look&feel from nosetests. In 
hindsight, it might not be such a great idea. Python unit tests rarely 
produce any output, unlike autopkgtests, which almost always do.)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#739961: Updates for 1.8.2

[Klee Dienes]

The only change to the packaging I needed to get 1.8.2 to work was to add 
libgssglue-dev to the Build-Depends.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749054: src:libhx: use dh-autoreconf to fix FTBFS on ppc64el

[Erwan Prioul]

Package: src:libhx
Version: 3.19-1
Severity: normal
Tags: patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, 
a full autoreconf is necessary. This is because we need new libtool 
macros for ppc64el.


In Ubuntu, the attached patch was applied to achieve the following:

 * Build using dh-autoreconf.

Thanks for considering the patch.

Erwan Prioul.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.13-1-powerpc64le (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

--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: libhx
 Priority: extra
 Maintainer: Bastian Kleineidam 
-Build-Depends: debhelper (>= 9), hardening-wrapper
+Build-Depends: debhelper (>= 9), hardening-wrapper, dh-autoreconf
 Standards-Version: 3.9.5
 XS-Testsuite: autopkgtest
 Section: libs
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@ export DEB_BUILD_HARDENING=1
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --enable-static

Bug#749055: libmpd: Please package version 11.8.90

[Etienne Millon]

Source: libmpd
Severity: wishlist

Hello,

I maintain gmpc, from the same upstream author.
The version in testing builds only with vala-0.16 which is scheduled
for removal. This would leave gmpc RC-buggy (see #739030).

As a solution I would like to introduce a newer version, probably a
git snapshot. The problem is that it needs a recent libmpd version. No
release has been officially made but everything works with the latest
upstream commit from 2013-03-19.

I see that you're in the Low NMU threshold, if you want I can do the
work as part of a NMU, but as it is quite disruptive I prefer to ask
you first.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Etienne Millon


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749056: rdesktop: Does not support _WM_NET_PID

[Klee Dienes]

Package: rdesktop
Version: 1.7.1-1
Severity: normal
Tags: patch

rdesktop supports a number of extended window manager hints, but not 
_WM_NET_PID.

The attached patch fixes that.  I've tested it against 1.8.2 as well as 1.7.1.

Please let me know if you'd prefer for me to submit it directly upstream as 
well as here.

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

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rdesktop depends on:
ii  libasound21.0.27.2-3
ii  libc6 2.18-5
ii  libpcsclite1  1.8.11-1
ii  libssl1.0.0   1.0.1g-3
ii  libx11-6  2:1.6.2-1
ii  libxrandr22:1.4.2-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
pn  pcscd  

-- no debconf information
>From 5a2fd7d8e2a43d3ac1645cd929f3d17cc7e970af Mon Sep 17 00:00:00 2001
From: Klee Dienes 
Date: Fri, 23 May 2014 08:14:39 -0400
Subject: [PATCH 1/3] Add _WM_NET_PID support.

---
 ewmhints.c | 10 +-
 xproto.h   |  1 +
 xwin.c |  3 +++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/ewmhints.c b/ewmhints.c
index ae132e5..e542ff4 100644
--- a/ewmhints.c
+++ b/ewmhints.c
@@ -35,7 +35,8 @@ extern Display *g_display;
 static Atom g_net_wm_state_maximized_vert_atom, g_net_wm_state_maximized_horz_atom,
 	g_net_wm_state_hidden_atom, g_net_wm_name_atom, g_utf8_string_atom,
 	g_net_wm_state_skip_taskbar_atom, g_net_wm_state_skip_pager_atom,
-	g_net_wm_state_modal_atom, g_net_wm_icon_atom, g_net_wm_state_above_atom;
+	g_net_wm_state_modal_atom, g_net_wm_icon_atom, g_net_wm_state_above_atom,
+	g_net_wm_pid_atom;
 
 Atom g_net_wm_state_atom, g_net_wm_desktop_atom;
 
@@ -191,6 +192,7 @@ ewmh_init()
 	g_net_wm_name_atom = XInternAtom(g_display, "_NET_WM_NAME", False);
 	g_net_wm_icon_atom = XInternAtom(g_display, "_NET_WM_ICON", False);
 	g_utf8_string_atom = XInternAtom(g_display, "UTF8_STRING", False);
+	g_net_wm_pid_atom = XInternAtom(g_display, "_NET_WM_PID", False);
 }
 
 
@@ -409,6 +411,12 @@ ewmh_set_wm_name(Window wnd, const char *title)
 			8, PropModeReplace, (unsigned char *) title, len);
 }
 
+void
+ewmh_set_wm_pid(Window wnd, pid_t pid)
+{
+	XChangeProperty(g_display, wnd, g_net_wm_pid_atom, XA_CARDINAL, sizeof(pid_t) * 8,
+			PropModeReplace, &pid, 1);
+}
 
 int
 ewmh_set_window_popup(Window wnd)
diff --git a/xproto.h b/xproto.h
index e3c07a5..3b7083a 100644
--- a/xproto.h
+++ b/xproto.h
@@ -7,6 +7,7 @@ int ewmh_change_state(Window wnd, int state);
 int ewmh_move_to_desktop(Window wnd, unsigned int desktop);
 int ewmh_get_window_desktop(Window wnd);
 void ewmh_set_wm_name(Window wnd, const char *title);
+void ewmh_set_wm_pid(Window wnd, pid_t pid);
 int ewmh_set_window_popup(Window wnd);
 int ewmh_set_window_modal(Window wnd);
 void ewmh_set_icon(Window wnd, int width, int height, const char *rgba_data);
diff --git a/xwin.c b/xwin.c
index 1637848..f321a05 100644
--- a/xwin.c
+++ b/xwin.c
@@ -506,6 +506,7 @@ sw_find_group(unsigned long id, RD_BOOL dont_create)
 	sg->wnd =
 		XCreateWindow(g_display, RootWindowOfScreen(g_screen), -1, -1, 1, 1, 0,
 			  CopyFromParent, CopyFromParent, CopyFromParent, 0, &attribs);
+	ewmh_set_wm_pid(sg->wnd, getpid());
 
 	sg->id = id;
 	sg->refcnt = 0;
@@ -2030,6 +2031,7 @@ ui_create_window(void)
 			  wndheight, 0, g_depth, InputOutput, g_visual,
 			  CWBackPixel | CWBackingStore | CWOverrideRedirect | CWColormap |
 			  CWBorderPixel, &attribs);
+	ewmh_set_wm_pid(g_wnd, getpid());
 
 	if (g_gc == NULL)
 	{
@@ -3930,6 +3932,7 @@ ui_seamless_create_window(unsigned long id, unsigned long group, unsigned long p
 	wnd = XCreateWindow(g_display, RootWindowOfScreen(g_screen), -1, -1, 1, 1, 0, g_depth,
 			InputOutput, g_visual,
 			CWBackPixel | CWBackingStore | CWColormap | CWBorderPixel, &attribs);
+	ewmh_set_wm_pid(wnd, getpid());
 
 	XStoreName(g_display, wnd, "SeamlessRDP");
 	ewmh_set_wm_name(wnd, "SeamlessRDP");
-- 
1.9.1

Bug#749052: apt-cacher: Separate direct and HTTP-proxied access to different origin servers (repositories/mirrors)

[Mark Hindley]

On Fri, May 23, 2014 at 02:12:08PM +0200, Jim Klimov wrote:
> Package: apt-cacher
> Version: 1.7.6
> Severity: important
> 
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> We are rolling out an Emdebian-based project in a LAN with weak internet
> connectivity, so caching of packages is a substantial requirement for fast
> redeployments of our test images. Apt-cacher was shown to be a pretty good
> fit for our usecase, though with a nit...



>* What outcome did you expect instead?
> 
> Accessibility of both local (direct) and internet (proxied and/or direct)
> origin repository servers with a single configuration of apt-cacher.
> It is my understanding that at the moment this separate approach is not
> catered for. I believe a proper solution would be to add lists of backend
> hosts that should or should not be accessed with an http_proxy, and it
> should be valid to have a host listed in both lists (with both ways tried
> in this case, if the first attempt over whichever transport fails).

Thanks. Yes, I have thought before that the upstream proxy 
implementation was not as fine grained as it could be, but nobody has 
come with a case that warranted working on it. And I don't want to break 
existing installations.

I think we could address this by optionally having the configuration 
option http_proxy be a list (similar to path_map) that is used to lookup 
request hostnames and return the upstream proxy to be used. No entry in 
the list for a direct request.

Would that address your case? 

Best wishes

Mark


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749010: [Debian-astro-maintainers] Bug#749010: eso-midas: FTBFS: expects writable HOME

[Tomasz Kundera]

IMHO this command is not needed at all as it is a user test procedure, a
graphical one. It cannot and shouldn't be done during package installation.


On Fri, May 23, 2014 at 2:00 AM, Aaron M. Ucko  wrote:

> Source: eso-midas
> Version: 13.09pl1.2+dfsg-1
> Severity: serious
> Justification: fails to build from source
>
> Automated builds of eso-midas have been failing:
>
>   /«BUILDDIR»/eso-midas-13.09pl1.2+dfsg/13SEP/system/unix//inmidas -j "@
> compile.all"
>   mkdir: cannot create directory '/sbuild-nonexistent/midwork': No such
> file or directory
>   Could not create directory /sbuild-nonexistent/midwork
>   make[1]: *** [override_dh_auto_build] Error 1
>
> The build evidently tries to work under $HOME, which autobuilders
> typically set to /sbuild-nonexistent because builds shouldn't be
> touching it.  Please arrange for it to work elsewhere, for instance by
> repointing HOME to a specially created directory within the build area.
>
> Thanks!
>
> ___
> Debian-astro-maintainers mailing list
> debian-astro-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers
>



-- 
Tomasz Kundera

Bug#749057: netsniff-ng: Supported Architectures: artificially restricted

[James McCoy]

Source: netsniff-ng
Version: 0.5.8-2
Severity: normal

The Architectures: list in debian/control is limited according to what
liburcu supported the last time the line was updated.  Instead of
manually keeping this up to date, why not set it to "any" and let the
availability of the liburcu-dev package determine whether netsniff-ng
gets built?

If liburcu-dev isn't available on that arch, then the netsniff-ng build
will just sit in the BD-Uninstallable state.  However, if liburcu-dev
does become available, then you won't need a sourceful upload of
netsniff-ng to take advantage of it.

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

Kernel: Linux 3.14-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749058: liboping: Regression: new version (1.6.2-5) FTBFS

[Breno Leitao]

Package: liboping
Version: 1.6.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

With the recent change on liboping, it is not able to be build anymore.  I
tested the build on the ppc64el and amd64 architectures, and both show the same
problem:


src/Makefile.am:50: `pkgconfig_DATA' is used but `pkgconfigdir' is undefined
autoreconf: automake failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
make[1]: *** [override_dh_autoreconf] Error 2
make[1]: Leaving directory `/home/brenohl/source/liboping-1.6.2'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


I believe that it happened due to the last change. Version 1.6.2-4 builds fine
on both architectures.

Thank you,
Breno


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749059: gambas3-ide: Missing dependency on gambas3-gb-clipper

[Shane Kerr]

Package: gambas3-ide
Version: 3.5.2-2
Severity: important

Dear Maintainer,

On Debian testing (jessie), after installing gambas3-ide, it failed to run:

$ sudo apt-get install gambas3-ide
$ gambas3
gbr3: unable to load component: gb.clipper

I installed the gambas3-gb-clipper package and it starts as expected:

$ sudo apt-get install gambas3-gb-clipper
$ gambas3

Success. :)

--
Shane



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

Kernel: Linux 3.10.38-t680c-20140504 (SMP w/8 CPU cores)
Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gambas3-ide depends on:
ii  debhelper  9.20140228
ii  fakeroot   1.18.4-2
ii  gambas3-dev3.5.2-2
ii  gambas3-gb-db  3.5.2-2
ii  gambas3-gb-db-form 3.5.2-2
ii  gambas3-gb-desktop 3.5.2-2
ii  gambas3-gb-eval-highlight  3.5.2-2
ii  gambas3-gb-form3.5.2-2
ii  gambas3-gb-form-dialog 3.5.2-2
ii  gambas3-gb-form-mdi3.5.2-2
ii  gambas3-gb-form-stock  3.5.2-2
ii  gambas3-gb-image-effect3.5.2-2
ii  gambas3-gb-qt4 3.5.2-2
ii  gambas3-gb-qt4-ext 3.5.2-2
ii  gambas3-gb-qt4-webkit  3.5.2-2
ii  gambas3-gb-settings3.5.2-2
ii  gambas3-runtime3.5.2-2

Versions of packages gambas3-ide recommends:
ii  gambas3-examples  3.5.2-2
ii  rpm   4.11.2-3

gambas3-ide suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748917: lightdm: fails to register a logind session

[John Talbut]

Is there anything I can do to diagnose this problem?  Is there a workaround?

John


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749060: klibc: ppc64el needs static binaries as well

[Mauricio Faria de Oliveira]

Package: src:klibc
Version: 2.0.3-1
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el

Hi,

The ppc64el port needs klibc's static binaries, like ppc64.

This patch enables the ARCH=ppc64 make env var in debian/rules, in order
for 'debian/patches/ppc64-static.patch' to take effect on ppp64el too.

I initially thought that wouldn't be needed due to the ARCH=ppc64
definition on some Kbuild files, but it seems that is not used in
some make targets for the binaries (probably why, even though, there
was an ARCH=ppc64 definition already in place..).  The result was
shared binaries being picked, and some of them segfault.

With this patch I can get a functional initramfs and non-segfaulting
binaries in '/usr/lib/klibc/bin/*' (exception: 'kinit.shared', the
only'.shared' file there).

Unfortunately this fix didn't make the first ppc64el bug/patch for klibc
(#744884);  I only happened to notice this more recently. Apologies for
the additional effort.

Thanks,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center
Index: klibc-2.0.3/debian/rules
===
--- klibc-2.0.3.orig/debian/rules
+++ klibc-2.0.3/debian/rules
@@ -33,7 +33,7 @@
 ifeq ($(DEB_HOST_ARCH),sh4)
 DEB_MAKE_ENVVARS := ARCH=sh
 endif
-ifeq ($(DEB_HOST_ARCH),ppc64)
+ifneq (,$(findstring $(DEB_HOST_ARCH),ppc64 ppc64el))
 DEB_MAKE_ENVVARS := ARCH=ppc64
 endif
 

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Guillem Jover]

On Fri, 2014-05-23 at 13:34:27 +0200, Guillem Jover wrote:
> On Fri, 2014-05-23 at 13:23:33 +0200, Johannes Schauer wrote:
> > Here is a simple patch and updated testcase:
> 
> I'm merging this now for 1.17.10, although I think I'll be changing it
> a bit, as it seems it could be done in a different way.

Here's what I'm going to include in the next push. It also covers a
case that was not handled in the supplied patch. :)

Thanks,
Guillem
diff --git a/scripts/Dpkg/Control/HashCore.pm b/scripts/Dpkg/Control/HashCore.pm
index af41c7e..d45e688 100644
--- a/scripts/Dpkg/Control/HashCore.pm
+++ b/scripts/Dpkg/Control/HashCore.pm
@@ -349,22 +349,25 @@ sub output {
 # Skip whitespace-only fields
 next if $$self->{drop_empty} and $value !~ m/\S/;
 	# Escape data to follow control file syntax
-	my @lines = split(/\n/, $value);
-	$value = (scalar @lines) ? shift @lines : '';
+	my ($first_line, @lines) = split /\n/, $value;
+
+	my $kv = "$key:";
+	$kv .= " " . $first_line if $first_line;
+	$kv .= "\n";
 	foreach (@lines) {
 		s/\s+$//;
 		if (/^$/ or /^\.+$/) {
-		$value .= "\n .$_";
+		$kv .= " .$_\n";
 		} else {
-		$value .= "\n $_";
+		$kv .= " $_\n";
 		}
 	}
 	# Print it out
 if ($fh) {
-	print { $fh } "$key: $value\n"
+	print { $fh } $kv
 	or syserr(_g('write error on control data'));
 }
-	$str .= "$key: $value\n" if defined wantarray;
+	$str .= $kv if defined wantarray;
 	}
 }
 return $str;
diff --git a/scripts/t/Dpkg_Changelog.t b/scripts/t/Dpkg_Changelog.t
index 6fe3407..6a7fb42 100644
--- a/scripts/t/Dpkg_Changelog.t
+++ b/scripts/t/Dpkg_Changelog.t
@@ -173,7 +173,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld 
 Date: Sun, 13 Jan 2008 15:49:19 +0100
 Closes: 100 111 222
-Changes: 
+Changes:
  fields (2.0-0etch1) stable; urgency=low
  .
* Upload to stable (Closes: #111, #222)
@@ -214,7 +214,7 @@ Urgency: medium
 Maintainer: Frank Lichtenheld 
 Date: Sun, 12 Jan 2008 15:49:19 +0100
 Closes: 111 222
-Changes: 
+Changes:
  fields (2.0-1) unstable  frozen; urgency=medium
  .
[ Frank Lichtenheld ]
@@ -244,7 +244,7 @@ Distribution: unstable
 Urgency: low
 Maintainer: Frank Lichtenheld 
 Date: Sun, 11 Jan 2008 15:49:19 +0100
-Changes: 
+Changes:
  fields (2.0~b1-1) unstable; urgency=low,xc-userfield=foobar
  .
* Beta
@@ -257,7 +257,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld 
 Date: Sun, 10 Jan 2008 15:49:19 +0100
 Closes: 100
-Changes: 
+Changes:
  fields (1.0) experimental; urgency=high,xb-userfield2=foobar
  .
* First upload (Closes: #100)
diff --git a/scripts/t/Dpkg_Control.t b/scripts/t/Dpkg_Control.t
index 8668b56..2e842d8 100644
--- a/scripts/t/Dpkg_Control.t
+++ b/scripts/t/Dpkg_Control.t
@@ -53,7 +53,7 @@ Long-Field: line1
line 3 line 3 line 3
  ..
  line 4
-Empty-Field: 
+Empty-Field:
 
 Package: mypackage1
 Architecture: any

Bug#667706: [pkg-wpa-devel] Bug#667706: openssl 1.0.1 breaks wpa_supplicant

[Pablo Mazzini]

Hi,

I have tried using the wpa_supplicant 2.1 release and I can no longer 
reproduce this bug.


I think it was fixed in the 2.0 one, this is a meaningful extract from 
the 2.0 changelog:


* added mechanism to disable TLS Session Ticket extension
  - a workaround for servers that do not support TLS extensions that
was enabled by default in recent OpenSSL versions
  - tls_disable_session_ticket=1
  - automatically disable TLS Session Ticket extension by default when
using EAP-TLS/PEAP/TTLS (i.e., only use it with EAP-FAST)

Regards,
Pablo Mazzini


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2014-05-23 15:57:08)
> Here's what I'm going to include in the next push. It also covers a case that
> was not handled in the supplied patch. :)

oh super! Thanks for handling this that fast :D

cheers, josch


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748903: python-tornado: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2014-05-23 at 14:42 +0200, Samuel Thibault wrote:
> Svante Signell, le Fri 23 May 2014 14:28:49 +0200, a écrit :
> > On Fri, 2014-05-23 at 13:58 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Fri 23 May 2014 13:45:50 +0200, a écrit :
> > > > Index: python-tornado-3.2.0/tornado/iostream.py
> > > > ===
> > > > --- python-tornado-3.2.0.orig/tornado/iostream.py
> > > > +++ python-tornado-3.2.0/tornado/iostream.py
> > > > @@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
> > > >  self._add_io_state(self.io_loop.WRITE)
> > > >  
> > > >  def _handle_connect(self):
> > > > -err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > socket.SO_ERROR)
> > > > +try:
> > > > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > socket.SO_ERROR)
> > > > +except socket.error as e:
> > > > +if e.args[0] == errno.ENOPROTOOPT:
> > > > +err = 0
> > > >  if err != 0:
> > > >  self.error = socket.error(err, os.strerror(err))
> > > >  # IOLoop implementations may vary: some of them return
> > > 
> > > But if it's another error, err and self.error will not be set. Rather
> > > use:
> > > 
> > > @@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
> > >  self._add_io_state(self.io_loop.WRITE)
> > >  
> > >  def _handle_connect(self):
> > > -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
> > > +try:
> > > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > socket.SO_ERROR)
> > > +except socket.error as e:
> > > +err = e.args[0]
> > > +if err == errno.ENOPROTOOPT:
> > > +err = 0
> > >  if err != 0:
> > >  self.error = socket.error(err, os.strerror(err))
> > >  # IOLoop implementations may vary: some of them return
> > 
> > I thoughts it did exactly the same before, indentation stops at err = 0,
> > i.e. outside the exception, so other errors are not affected.
> 
> Other exceptions (with different e.args[0]) will still be caught by
> except. Those need to be handled too.
> 
> > But I can do as you wish, just let me know. Otherwise al else
> > statement would be needed.
> 
> You can go with an else, yes, but it's simpler the way I proposed.

I still don't see the difference: with 

try:
  err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
  except socket.error as e:
  if e.args[0] == errno.ENOPROTOOPT:
   err = 0
if err != 0:
...

the exception handling is only treating the case when
e.args[0] ==  errno.ENOPROTOOPT and an else case would not be needed.
For other exceptions there is no explicit handler defined in
_handle_connect(self) and err is unchanged, or is python different?

In C:
if (condition)
{do something}
do something else

No need for an else here

Anyway, an updated patch attached.

Index: python-tornado-3.2.0/tornado/netutil.py
===
--- python-tornado-3.2.0.orig/tornado/netutil.py
+++ python-tornado-3.2.0/tornado/netutil.py
@@ -119,7 +119,11 @@ if hasattr(socket, 'AF_UNIX'):
 """
 sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
 set_close_exec(sock.fileno())
-sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+try:
+sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+except socket.error as e:
+if e.args[0] != errno.ENOPROTOOPT:
+raise
 sock.setblocking(0)
 try:
 st = os.stat(file)
Index: python-tornado-3.2.0/tornado/iostream.py
===
--- python-tornado-3.2.0.orig/tornado/iostream.py
+++ python-tornado-3.2.0/tornado/iostream.py
@@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
 self._add_io_state(self.io_loop.WRITE)
 
 def _handle_connect(self):
-err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+try:
+err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
+except socket.error as e:
+err = e.args[0]
+if err == errno.ENOPROTOOPT:
+err = 0
 if err != 0:
 self.error = socket.error(err, os.strerror(err))
 # IOLoop implementations may vary: some of them return

Bug#749020: apt: policykit-1_0.105-5_amd64 crashes apt-get 1.0.3

[David Kalnischkies]

Control: severity -1 normal

Hi!

On Thu, May 22, 2014 at 11:32:22PM -0400, Martin Furter wrote:
> Package: apt
> Version: 1.0.3
> Severity: critical
> Justification: breaks the whole system

Well, if apt segfaults before anything is installed it by definition
isn't breaking the system. You can't upgrade your system, which defeats
the propose of apt, but your system is still okay. Hence downgrading
and the following hopefully describes why I set it so low…


> Before the dist-upgrade I upgraded apt. Then I ran "apt-get dist-upgrade". It
> downloaded all packages and then crashed with "segmentation fault".

Old system, policykit (and therefore libpam-systemd) in the bug title
and the list of downloaded packages includes systemd-sysv…
I bet you are one of those hit by #748355. See there for the nitty-gritty
details, but in essence: APT encounters an "impossible to upgrade
safely" and "forbidden by debian policy" situation here, which the
involved packages have to solve, so that a good upgrade path exists
and apt can do its assigned work.


I finally managed to get a patch together yesterday to restore apts
detection for these kind of situations, so the next upload should fix
the segfault and instead a user should in the future be greeted again
with the following old error message:
| E: This installation run will require temporarily removing the essential
| package sysvinit:amd64 due to a Conflicts/Pre-Depends loop. This is
| often bad, but if you really want to do it, activate the
| APT::Force-LoopBreak option.

Not really a lot better from a user point as you still can't really
upgrade, it is just slightly less scary than a segfault, but that bug
has really to be resolved on the systemd/sysvinit-side …


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Bug#720391: [sslscan] no ipv6 support

[Robin Bailey]

The original version of sslscan, and the fork of that by ioerror are both
pretty much dead.

I maintain a new fork (available on GitHub at
https://github.com/rbsec/sslscan) that includes support for IPv6, as well
as a number of other features such as TLS 1.1/1.2, CRIME, Heartbleed, etc.

It builds properly on Debian even if SSLv2 support isn't available from
OpenSSL (although it will display a warning when run that it couldn't scan
for SSLv2 ciphers). Dependencies should also be the same as the existing
version.

~rbsec

Bug#749010: eso-midas: FTBFS: expects writable HOME

[Ole Streicher]

Hi Thomasz,

> IMHO this command is not needed at all as it is a user test procedure,
> a graphical one. It cannot and shouldn't be done during package
> installation. 
> 
> On Fri, May 23, 2014 at 2:00 AM, Aaron M. Ucko 
> /«BUILDDIR»/eso-midas-13.09pl1.2+dfsg/13SEP/system/unix//inmidas -
> j "@ compile.all"

I am following the installation guide here which says:

| 2.10 Running MIDAS for the first time
|
| Once the installation of MIDAS is successfully completed, you still
| need to initialize some MIDAS files by executing the following
| sequence, once:
|
| % mkdir /midas/tmp
| % cd /midas/tmp
| % inmidas
| Midas 001> @ compile.all
| (this will produce about 40 lines of output and it will exit to the
| Shell)
| % gomidas
| Midas 002 > @ ascii bin
| (this will create the LUTs and ITTs files)
| Midas 003 > bye

This has IMO nothing to do with a user test procedure, but is the first
initialization of MIDAS. Please correct me if I am wrong.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#737389: emacsen-common: incorrectly handles dependencies during emacsXX upgrade

[Tatsuya Kinoshita]

Control: severity -1 important

On January 31, 2014 at 9:57PM +0900, tats (at debian.org) wrote:
> Subject: Re: Bug#737202: devscripts-el: fails to upgrade from 'wheezy': 
> ERROR: install script from devscripts-el package failed (during Install 
> devscripts-el for emacs23)
>>   Install emacsen-common for emacs23
> [...]
>>   install/devscripts-el: Handling emacs23, logged in /tmp/elc_tCbg9i.log
>>   ERROR: install script from devscripts-el package failed
> [...]
>> devscripts.el:19:1:Error: Cannot open load file: mcharset
>
> It seems apel's mcharset.elc is not found when byte-compiling.
>
> The devscripts-el package depends on apel, so install/devscripts-el
> called from devscripts-el.postinst succeed, but install/devscripts-el
> called from emacsen-common or emacsen could fail as above.
>
> To fix this bug, please skip byte-compilation in install/devscripts-el
> if the depending file is not yet prepared.
>
> e.g.
> if [ ! -e "/usr/share/$FLAVOR/site-lisp/apel/mcharset.elc" ]; then exit 
> 0; fi

This is a known issue since emacsen-common 1.x, not a new serious
bug in emacsen-common 2.0.7.

Thanks,
--
Tatsuya Kinoshita


pgpwY3Q3hRv4p.pgp
Description: PGP signature

Bug#749061: graphviz: Fix typo to ensure autoconf files are updated forbuild

[Wookey]

Package: graphviz
Version: 2.26.3-17
Severity: serious
Tags: patch
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertag: arm64

Graphviz now uses dh_autoreconf and has stuff in the rules file to
update all three copies of config.{sub,guess} (hooray!), but a path
mistake meant that the copies in libltld/config were not being
replaced (instead a 4th set was added in the dir above).

This meant that the libltld suddir ./configure on any arch too new for
the shipped config.{sub,guess} failed. This failed on arm64 as they
are too old for that.

A more robust fix for this would probably be to simply use
dh_autotools-dev as well as dh_autoreconf to ensure that all copies
are updated, without having to maintain paths to a list of them in the
rules file. I don't know if the maintainer had a good reason for
trying to avoid the use of that helper?

Attached is the minimal fix that keeps the existing mechanism but I
don't actually think this is better. I'm happy to do a fix using
autotools-dev if the maintainer would prefer (and NMU it). 

Graphviz is blocking a lot of package builds on arm64 so I'd
appreciate either an upload or request to NMU reasonably quickly. Cheers.

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru graphviz-2.26.3/debian/changelog graphviz-2.26.3/debian/changelog
--- graphviz-2.26.3/debian/changelog	2014-04-20 14:17:40.0 +
+++ graphviz-2.26.3/debian/changelog	2014-05-23 14:26:24.0 +
@@ -1,3 +1,9 @@
+graphviz (2.26.3-17+cfg) unreleased; urgency=low
+
+  * Correct typo in rules so config.{sub,guess} is actually updated.
+
+ -- Wookey   Fri, 23 May 2014 14:25:42 +
+
 graphviz (2.26.3-17) unstable; urgency=medium
 
   * QA upload.
diff -Nru graphviz-2.26.3/debian/rules graphviz-2.26.3/debian/rules
--- graphviz-2.26.3/debian/rules	2014-02-12 02:45:51.0 +
+++ graphviz-2.26.3/debian/rules	2014-05-23 14:24:42.0 +
@@ -35,8 +35,8 @@
 
 RUBY_PACKAGE  = $(CURDIR)/debian/libgv-ruby
 
-CONFIG_SCRIPTS=config/config.guess lib/gd/config/config.guess libltdl/config.guess \
-	   config/config.sub   lib/gd/config/config.sub   libltdl/config.sub
+CONFIG_SCRIPTS=config/config.guess lib/gd/config/config.guess libltdl/config/config.guess \
+	   config/config.sub   lib/gd/config/config.sub   libltdl/config/config.sub
 
 # make's $(shell) doesn't use local variables, thus we need to define a
 # custom command where DEB_LDFLAGS_MAINT_APPEND is passed.

Bug#748703: libvirt-bin: libvirtd version 1.2.4-3 cannot probe backing volume format

[Guido Günther]

On Mon, May 19, 2014 at 04:29:07PM -0400, Bob Weber wrote:
> Package: libvirt-bin
> Version: 1.2.4-3
> Severity: grave
> Justification: renders package unusable
> 
> 
> After upgrading to 1.2.4-3 libvirtd reports:
> 
> kern.log.1:May 17 19:20:06 bob libvirtd[11315]: internal error: cannot probe 
> backing volume format: Debian-7.4-base.img
> 
> This happens for every VM that I have that uses a qcow2 backing image file.  
> A google search only found anything related 
> to backing files on a much earlier version of libvirtd.  I have downgraded 
> the libvirt-bin and libvirt0 to 1.2.1-1 to temporarily
> resolve the issue.

Thanks for the xml but please also read

https://wiki.debian.org/libvirt/Debugging

Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#700758: bcrypt: Bcrypt exposes patterns in data, it is broken

[Agustin Martin]

reassign 740748 bcrypt
forcemerge 700758 740748
thanks

On Thu, May 08, 2014 at 12:33:23PM +0200, Agustin Martin wrote:
> I plan to upload encription-disabled bcrypt package closing #700758, wait for
> it to reach testing in case any problem appear and then reassign #740748 to
> bcrypt and forcemerge it with #700758.

forcemerging as announced.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738702: same problem only different library

[Brent S. Elmer Ph.D.]

Is this the same problem:

(gdb) run
Starting
program: /home/brente/atp_home/tests/fix_20140521/input/atp_bin/atp_engine 
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/i386-linux-gnu/libstdc
++.so.6.0.20-gdb.py", line 59, in 
from libstdcxx.v6.printers import register_libstdcxx_printers
  File
"/usr/lib/i386-linux-gnu/../../share/gcc-4.9/python/libstdcxx/v6/printers.py", 
line 392
raise ValueError, "Unsupported implementation for %s" %
str(node.type)
^
SyntaxError: invalid syntax


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#744403: Please, enable tests at build time

[David Prévot]

Control: reopen -1

Hi,

On Sun, Apr 13, 2014 at 12:14:27PM -0400, David Prévot wrote:
> Since the latest libssh version switched from CMockery to cmocka, you
> may wish to enable tests at build time (by build-depending on
> libcmocka-dev and adding -DWITH_TESTING=ON to DEB_CMAKE_EXTRA_FLAGS, and
> also another action CDBS-specific but I can’t help with that).

Thanks for activating tests at build time, but AFAICT, they are not
actually run. The last CDBS-specific bit is missing: dh_auto_test is
not run during the build.

Regards

David


signature.asc
Description: Digital signature

Bug#749060: klibc: ppc64el needs static binaries as well

[maximilian attems]

Hi,

On Fri, May 23, 2014 at 10:57:31AM -0300, Mauricio Faria de Oliveira wrote:
> 
> The ppc64el port needs klibc's static binaries, like ppc64.

This segfaulting is a bug in klibc that needs investigation.
 
> This patch enables the ARCH=ppc64 make env var in debian/rules, in order
> for 'debian/patches/ppc64-static.patch' to take effect on ppp64el too.

I have no problem to merge this for Debian as workaround for now,
but this is not the solution. Effort in making shared binary
working too is appreciated. It is probably a wrong syscall API.

Thank you.

-- 
maks
 

> Index: klibc-2.0.3/debian/rules
> ===
> --- klibc-2.0.3.orig/debian/rules
> +++ klibc-2.0.3/debian/rules
> @@ -33,7 +33,7 @@
>  ifeq ($(DEB_HOST_ARCH),sh4)
>  DEB_MAKE_ENVVARS := ARCH=sh
>  endif
> -ifeq ($(DEB_HOST_ARCH),ppc64)
> +ifneq (,$(findstring $(DEB_HOST_ARCH),ppc64 ppc64el))
>  DEB_MAKE_ENVVARS := ARCH=ppc64
>  endif
>  


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749009: adios: FTBFS - Could NOT find PYTHON_MPI4PY

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> Please declare a build dependency on python-mpi4py in addition to the
> one on python3-mpi4py.

Thanks for the quick fix!  Alas, builds are still failing, at this point
when trying to build for Python 3, because adios builds for all
installed Python 3.x interpreter versions:

PY3VERS:= $(shell py3versions -s)

but build-depends only on the default version's development files
(python3-dev).  As such, python3-numpy's dependency on python3.4 results
in a failed attempt to build for that version:

  /usr/bin/mpic++   -DADIOS_USE_READ_API_1 -Dadios_EXPORTS -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security  
-fPIC -I/usr/include/python3.4 -I/usr/include/i386-linux-gnu/python3.4 
-I/«PKGBUILDDIR»/debian/tmp/include -I/usr/lib/openmpi/include 
-I/usr/lib/openmpi/include/openmpi -DZLIB  -DBZIP2 -o 
CMakeFiles/adios.dir/adios.cpp.o -c 
/«PKGBUILDDIR»/wrappers/numpy/build_python3.4/adios.cpp
  /«PKGBUILDDIR»/wrappers/numpy/build_python3.4/adios.cpp:8:22: fatal error: 
pyconfig.h: No such file or directory
   #include "pyconfig.h"

If you mean to build for all supported Python 3.x versions, please
build-depend on python3-all-dev, not just python3-dev.  OTOH, if you
mean to build for just the default, please set

PY3VERS := $(shell py3versions -d)

or even

PY3VERS := python3

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748940: iscsitarget: "service iscsitaget stop" fails when under load

[Ritesh Raj Sarraf]

Please keep the bug in the recipient list

On 05/23/2014 02:23 PM, Craig Barnes wrote:

>> I am assuming you are writing to the iscsi devices. If yes, then
>> there's no reason for this to not fail.
> 
> Yes I am writing to the iscsi device, the devices get removed as
> expected, the service initiates a stop, only the kernel module unload
> fails, I assume waiting for the service to finish or disks to sync.
> 
> Is there any reason why this shouldn't successfully stop?
>

You are continuously pumping IO, and that's inflight, and now you want
to deliberately unload the kernel module. It has abort because it is
under use.



>> Yes. THis one does not have any direct dependencies. As practice, I use
>> modprobe.
> 
> Ok, so
>   a) what is the worst thing that could happen using rmmod --wait

In this case nothing. But I still see no reason to switch to rmmod.

>   b) is there a better way to do this? maybe wait 2 secs and try again
> with modprobe -r?

No. Then it becomes a never ending game. Why just 2 secs, why not 5 ?
Your use case is invalid. It is like you have the mount point busy and
you expect the kernel to unmount the file system.

>   c) if we fail at the module shouldn't we bring everything else back
> again?
>

On stop) target, that's not expected. If it is restart), then yes. Which
I guess gets covered in our current init script. Otherwise too, we do
report that things failed. So any calling program should look for and
honor that.



>> Yes. That is the case. Look at conn.c in the sources.
> 
> Sorry my c is a bit rusty and I am no kernel dev.  But I understand and
> appreciate your explanation.
> 
> However I did find this...
> http://sourceforge.net/p/iscsitarget/code/343/
> 
I need to verify that. I'm not very sure how it would really behave.


What exactly is your requirement ? Do you want the init script to exit
clean irrespective of the module state ?

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System



signature.asc
Description: OpenPGP digital signature

Bug#748903: python-tornado: FTBFS on hurd-i386

[Samuel Thibault]

Svante Signell, le Fri 23 May 2014 16:02:16 +0200, a écrit :
> On Fri, 2014-05-23 at 14:42 +0200, Samuel Thibault wrote:
> > Svante Signell, le Fri 23 May 2014 14:28:49 +0200, a écrit :
> > > On Fri, 2014-05-23 at 13:58 +0200, Samuel Thibault wrote:
> > > > Svante Signell, le Fri 23 May 2014 13:45:50 +0200, a écrit :
> > > > > Index: python-tornado-3.2.0/tornado/iostream.py
> > > > > ===
> > > > > --- python-tornado-3.2.0.orig/tornado/iostream.py
> > > > > +++ python-tornado-3.2.0/tornado/iostream.py
> > > > > @@ -748,7 +748,11 @@ class IOStream(BaseIOStream):
> > > > >  self._add_io_state(self.io_loop.WRITE)
> > > > >  
> > > > >  def _handle_connect(self):
> > > > > -err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > > socket.SO_ERROR)
> > > > > +try:
> > > > > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > > socket.SO_ERROR)
> > > > > +except socket.error as e:
> > > > > +if e.args[0] == errno.ENOPROTOOPT:
> > > > > +err = 0
> > > > >  if err != 0:
> > > > >  self.error = socket.error(err, os.strerror(err))
> > > > >  # IOLoop implementations may vary: some of them return
> > > > 
> > > > But if it's another error, err and self.error will not be set. Rather
> > > > use:
> > > > 
> > > > @@ -748,7 +748,12 @@ class IOStream(BaseIOStream):
> > > >  self._add_io_state(self.io_loop.WRITE)
> > > >  
> > > >  def _handle_connect(self):
> > > > -err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > socket.SO_ERROR)
> > > > +try:
> > > > +err = self.socket.getsockopt(socket.SOL_SOCKET, 
> > > > socket.SO_ERROR)
> > > > +except socket.error as e:
> > > > +err = e.args[0]
> > > > +if err == errno.ENOPROTOOPT:
> > > > +err = 0
> > > >  if err != 0:
> > > >  self.error = socket.error(err, os.strerror(err))
> > > >  # IOLoop implementations may vary: some of them return
> > > 
> > > I thoughts it did exactly the same before, indentation stops at err = 0,
> > > i.e. outside the exception, so other errors are not affected.
> > 
> > Other exceptions (with different e.args[0]) will still be caught by
> > except. Those need to be handled too.
> > 
> > > But I can do as you wish, just let me know. Otherwise al else
> > > statement would be needed.
> > 
> > You can go with an else, yes, but it's simpler the way I proposed.
> 
> I still don't see the difference: with 
> 
> try:
>   err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
>   except socket.error as e:
>   if e.args[0] == errno.ENOPROTOOPT:
>err = 0
> if err != 0:
> ...
> 
> the exception handling is only treating the case when
> e.args[0] ==  errno.ENOPROTOOPT and an else case would not be needed.

Take this scenario: getsockopt raises exception socket.error(errno.EIO).
What will be catched by the except socket.error, but nothing will be
done about it, nothing will be stored in err, and execution continues
with if err != 0. Worse, since nothing will be stored in err, err won't
even exist at all, and if err itself will actually error out.

> For other exceptions there is no explicit handler defined in
> _handle_connect(self) and err is unchanged, or is python different?
> 
> In C:
> if (condition)
> {do something}
> do something else
> 
> No need for an else here

This is not a strict equivalent of the python code above. A more strict
equivalent would be

if (socketerror)
{
  if (socketerror == ENOPROTOOPT)
err = 0;
}

if (err != 0)

when socketerror is != 0 but not ENOPROTOOPT, nothing is stored in err.

Samuel


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749062: mdadm: add "containers" to emergency config file

[Miquel van Smoorenburg]

Package: mdadm
Version: 3.3-2
Severity: normal

If no mdadm.conf file is found in initramfs, the local-top mdadm script 
will create one on the fly like this:


  echo DEVICE partitions > $CONFIG
  $MDADM --examine --scan >> $CONFIG

However, this config will fail to assemble Intel RAID (imsm) arrays, 
since those are "containers" and that needs to be explicitly added to 
the DEVICE line.


Also, from the manpage:

  If  no DEVICE line is present, then "DEVICE partitions 
contain-

  ers" is assumed.

So please add "containers" to the DEVICE line or just leave out the 
DEVICE line completely.


Thanks

Mike.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748940: iscsitarget: "service iscsitaget stop" fails when under load

[Ritesh Raj Sarraf]

On 05/23/2014 08:35 PM, Ritesh Raj Sarraf wrote:
> I need to verify that. I'm not very sure how it would really behave.
>
>
> What exactly is your requirement ? Do you want the init script to exit
> clean irrespective of the module state ?

Hey Craig,

By the way, that is not the init scirpt that we ship in Debian. And for
the one that we ship, We are handling your case, as in your rmmod --wait
option.


# check if the module is loaded at all
lsmod | grep -q iscsi_trgt
RETVAL=$?
if [ $RETVAL = "0" ] ; then

for i in $(seq $ISCSITARGET_MAX_SLEEP); do
log_daemon_msg "Removing iSCSI enterprise target
modules: "
modprobe -r iscsi_trgt
RETVAL=$?
if [ $RETVAL = "0" ]; then
break
fi
# give iet some time to finish processing
sleep 1
done

modprobe -r crc32c 2>/dev/null
if [ $RETVAL = "0" ]; then
log_end_msg 0
else
log_end_msg 1
exit $RETVAL
fi
fi


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System



signature.asc
Description: OpenPGP digital signature

Bug#749063: docker makes df horrible

[Joey Hess]

Package: docker.io, coreutils
Severity: minor

docker mounts stuff under a directory that normal users cannot read,
which makes df full of errors. Example below from a system with 4
running containers.

I feel this is a polish/integration issue that would be worth finding
some fix for. At least so far, I have not seen any value in df showing
these mount points to root, so perhaps they should be completly omitted
for clarity?

See also: #693853, which would apparently fix this, since all the docker
mounts seem to be find mounts (but I'm not sure how this aufs stuff works).

df: 
‘/var/lib/docker/aufs/mnt/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/.dockerinit’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/.dockerenv’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/etc/resolv.conf
 (deleted)’: Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/etc/hostname’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/etc/hosts’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/home/builder/gitbuilder’:
 Permission denied
df: 
‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/usr/local/propellor’:
 Permission denied
df: 
‘/var/lib/docker/aufs/mnt/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/.dockerinit’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/.dockerenv’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/etc/resolv.conf
 (deleted)’: Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/etc/hostname’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/etc/hosts’:
 Permission denied
df: 
‘/var/lib/docker/containers/78f2c5369c4b02811c1dbaecb5b46140d5de465d54f61cdd3349b9915937918a/root/usr/local/propellor’:
 Permission denied
df: 
‘/var/lib/docker/aufs/mnt/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/.dockerinit’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/.dockerenv’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/etc/resolv.conf
 (deleted)’: Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/etc/hostname’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/etc/hosts’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/home/builder/gitbuilder’:
 Permission denied
df: 
‘/var/lib/docker/containers/6cdf15597ee26b5b90bdf2d7c96beb6c63af5565ae822cf9863b6b662109c341/root/usr/local/propellor’:
 Permission denied
df: 
‘/var/lib/docker/aufs/mnt/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505’:
 Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505/root’:
 Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505/root/.dockerinit’:
 Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505/root/.dockerenv’:
 Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505/root/etc/resolv.conf
 (deleted)’: Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d04212505/root/etc/hostname’:
 Permission denied
df: 
‘/var/lib/docker/containers/1b77a6a024651cbcaddf286344dff3d56dfcd078821c7a5aae5f643d0421

Bug#749064: src:libcdr: use dh-autoreconf to fix FTBFS on ppc64el

[Erwan Prioul]

Package: src:libcdr
Version: 0.0.15-1
Severity: normal
Tags: patch

Dear Maintainer,

For the ppc64el architecture in Ubuntu, since this package uses libtool, 
a full autoreconf is necessary. This is because we need new libtool 
macros for ppc64el.


In Ubuntu, the attached patch was applied to achieve the following:

 * Build using dh-autoreconf.

Thanks for considering the patch.

Erwan Prioul.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.13-1-powerpc64le (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

--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --docdir=/usr/share/doc/libcdr-doc --libdir=/usr/lib \
--- a/debian/control
+++ b/debian/control
@@ -2,6 +2,7 @@
 Priority: optional
 Maintainer: Rene Engelhard 
 Build-Depends: autotools-dev,
+   dh-autoreconf,
debhelper (>= 9),
doxygen,
libboost-dev,

Bug#749063: docker makes df horrible

[Pádraig Brady]

On 05/23/2014 04:13 PM, Joey Hess wrote:
> Package: docker.io, coreutils
> Severity: minor
> 
> docker mounts stuff under a directory that normal users cannot read,
> which makes df full of errors. Example below from a system with 4
> running containers.
> 
> I feel this is a polish/integration issue that would be worth finding
> some fix for. At least so far, I have not seen any value in df showing
> these mount points to root, so perhaps they should be completly omitted
> for clarity?

Does `df -a` not show them for root?
Perhaps the duplicate suppression is kicking in here,
though one might have to have root access to determine
the mount points were duplicates.

> 
> See also: #693853, which would apparently fix this, since all the docker
> mounts seem to be find mounts (but I'm not sure how this aufs stuff works).
> 
> df: 
> ‘/var/lib/docker/aufs/mnt/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650’:
>  Permission denied
> df: 
> ‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root’:
>  Permission denied
> df: 
> ‘/var/lib/docker/containers/81abbf65e1935a6754e11276c044b94012082304f247be1b70306fa7dfda3650/root/.dockerinit’:
>  Permission denied
> ...
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda138G   29G  7.1G  81% /
> udev 10M 0   10M   0% /dev
> tmpfs   397M  184K  397M   1% /run
> tmpfs   5.0M 0  5.0M   0% /run/lock
> tmpfs   1.2G  3.8M  1.2G   1% /run/shm
> cgroup  2.0G 0  2.0G   0% /sys/fs/cgroup
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable

thanks,
Pádraig.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749060: klibc: ppc64el needs static binaries as well

[Mauricio Faria de Oliveira]

Hi maks,

Adding Anton in CC (who submitted klibc ppc64le support upstream [1]),
in case he can help.


The ppc64el port needs klibc's static binaries, like ppc64.


This segfaulting is a bug in klibc that needs investigation.


This patch enables the ARCH=ppc64 make env var in debian/rules, in order
for 'debian/patches/ppc64-static.patch' to take effect on ppp64el too.


I have no problem to merge this for Debian as workaround for now,
but this is not the solution. [...]


I agree.
Thanks for accepting to carry the workaround for ppc64el too.

> [...] Effort in making shared binary

working too is appreciated. It is probably a wrong syscall API.


Unfortunately I don't find myself in klibc expertise area. I can try,
but maybe it's not the effective way forward (not sure I'd be able to
devote the effort/time that I personally would like to).
Hopefully others can contribute in that more significantly. :)

Thank you.

[1] http://www.zytor.com/pipermail/klibc/2013-December/003518.html

--
Mauricio Faria de Oliveira
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747803: libmrss: FTBFS: configure: line 12750: syntax error near unexpected token `NXML,'

[Joseph Herlant]

Control: tags -1 + pending

Hi David,

Thanks for all those hints.
The fail was due to the missing dependency to pkg-config.
I updated it to the git repo and will upload it on mentors today.

Best,
Joseph


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org