Bug#712634: RFP: scenari

[westlake]

Package: wnpp
Version: N/A
Severity: wishlist

* Package name: scenari
Version: 4.0
Upstream Author: Kelis
* URL : http://scenari-platform.org/
* License : (GPL, LGPL, MPL, CECILL)
Description: documentation tool server/client

http://en.wikipedia.org/wiki/Scenari
http://scenari-platform.org/projects/scenari/en/pres/co/  (english part 
of site)

( scenari-platform  )

Not very known outside of France and Europe because the site is mostly 
french..


This is a documentation toolkit. It's pretty powerful..
I found these resources which might be helpful

http://scenari-platform.org/trac/scenari/wiki/InstallLinux
http://scenari-platform.org/trac/scenari/wiki/servicetomcat

Openoffice 3.3 is mentioned to work with one of the client programs.

If anyone's interested on how this all works.. I'm still trying to get 
the server to start.. I'm having problems..


What makes this tool different than the other's is that it's graphically 
driven for document publishing..


It's a very supported project, a number of universities in Europe are 
using it..


Its .deb repository contains the packages of 'scenariserver' with and 
without tomcat


cat /etc/apt/sources.list.d/scenari.list
deb http://scenari-platform.org/deb wheezy main
, apt-cache search scenari ..

scenaribuilder3.4 - Design publishing chains for SCENARIchain.
scenaribuilder3.5 - Design publishing chains for SCENARIchain.
scenaribuilder3.6 - Design publishing chains for SCENARIchain.
scenaribuilder3.7.fr-fr - SCENARIbuilder 3.7 fr-FR - Publishing chain 
designer.
scenaribuilder4.0.fr-fr - SCENARIbuilder 4.0 fr-FR - Publishing chain 
designer.
scenarichain3.4 - Create content and publish documents within a 
publishing chain created with SCENARIbuilder.
scenarichain3.5 - Create content and publish documents within a 
publishing chain created with SCENARIbuilder.
scenarichain3.6 - Create content and publish documents within a 
publishing chain created with SCENARIbuilder.
scenarichain3.7.en-us - SCENARIchain 3.7 en-US - Create and publish 
documents within a publishing chain.
scenarichain3.7.fr-fr - SCENARIchain 3.7 fr-FR - Create and publish 
documents within a publishing chain.
scenarichain4.0.en-us - SCENARIchain 4.0 en-US - Create and publish 
documents within a publishing chain.
scenarichain4.0.fr-fr - SCENARIchain 4.0 fr-FR - Create and publish 
documents within a publishing chain.
scenariclient3.4 - Connect up to a SCENARIserver providing publishing 
chains created with SCENARIbuilder.
scenariclient3.5 - Connect up to a SCENARIserver providing publishing 
chains created with SCENARIbuilder.
scenariclient3.6 - Connect up to a SCENARIserver providing publishing 
chains created with SCENARIbuilder.
scenariclient3.7.en-us - SCENARIclient 3.7 en-US - Connect to a 
SCENARIserver serving publishing chains.
scenariclient3.7.fr-fr - SCENARIclient 3.7 fr-FR - Connect to a 
SCENARIserver serving publishing chains.
scenariclient4.0.en-us - SCENARIclient 4.0 en-US - Connect to a 
SCENARIserver serving publishing chains.
scenariclient4.0.fr-fr - SCENARIclient 4.0 fr-FR - Connect to a 
SCENARIserver serving publishing chains.
scenariclientnuxeo-pre4.0.fr-fr - SCENARIclientNuxeo-pre 4.0 fr-FR - 
Connect up to a NUXEO server providing publishing chains.
scenaridemoserver4.0.en-us - SCENARIdemoServer 4.0 en-US - Demo 
SCENARIchain Db using a full SCENARIserver backend.
scenaridemoserver4.0.fr-fr - SCENARIdemoServer 4.0 fr-FR - Demo 
SCENARIchain Db using a full SCENARIserver backend.
scenaridiscovery1.1 - Create content and publish documents from some 
Scenari example models.
scenaridiscovery1.2 - Create content and publish documents from some 
Scenari example models.
scenaridiscovery2.0.fr-fr - SCENARIdiscovery 2.0 fr-FR - Decouverte de 
SCENARI

scenariserver3.7 - SCENARIserver 3.7 - Core web-app files.
scenariserver3.7-tomcat6 - SCENARIserver 3.7 - Tomcat6 integration.
scenariserver4.0-jetty - SCENARIserver 4.0 - Jetty integration.
scenariserver4.0 - SCENARIserver 4.0 - Core web-app files.
scenariserver4.0-tomcat6 - SCENARIserver 4.0 - Tomcat6 integration.
scenariserver4.0-tomcat7 - SCENARIserver 4.0 - Tomcat7 integration.
scenariserverlite4.0-jetty - SCENARIserverLite 4.0 - Jetty integration.
scenariserverlite4.0 - SCENARIserverLite 4.0 - Core web-app files.
scenariserverlite4.0-tomcat6 - SCENARIserverLite 4.0 - Tomcat6 integration.
scenariserverlite4.0-tomcat7 - SCENARIserverLite 4.0 - Tomcat7 integration.
..

I'm currently trying "SCENARIserver 4.0 - Core web-app files" which is 
not bundled with a tomcat server.. I believe this is the type of package 
suitable for debian



-Scott


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

Bug#712521: initramfs-tools: please add early-initramfs support for ucode update

[Michael Prokop]

* Henrique de Moraes Holschuh [Mon Jun 17, 2013 at 06:12:27PM -0300]:
> On Mon, 17 Jun 2013, Michael Prokop wrote:
> > * Henrique de Moraes Holschuh [Sun Jun 16, 2013 at 03:42:45PM -0300]:
> > > Enclosed you will find two patches to add early-initramfs support to
> > > initramfs-tools.

> > Thanks! I just applied it after reviewing it together with maks and
> > pushed it to master.

> Thank you.  I have the intel-microcode side ready and tested, do you have
> any tentative time-frame for the initramfs-tools upload?

I'll release and upload a new version today.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#712635: [apt] apt-cache show $packagename spits error on telepathy packages

[Thomas Hackert]

Package: apt
Version: 0.9.8.2
Severity: normal

--- Please enter the report below this line. ---
Hello all,
when I want to get information about a package in apt, I use


apt-cache show $packagename


. When I try this with telepathy-haze (but also with telepathy-gabble or
-rakia) I get only the message

E: Handler silently failed


... :( I am not sure, if this is really a bug in apt and/or a bug in
these packages. If I am wrong here, it would be nice someone could
reassign it to the right package ... ;)
Sorry for the inconvenience
Thomas.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.7-trunk-amd64

Debian Release: jessie/sid
  500 wheezy-pgdg apt.postgresql.org 
  500 unstablesnapshots.ekiga.net 
  500 unstabledownload.jitsi.org 
  500 testing www.deb-multimedia.org 
  500 testing ftp.de.debian.org 
  500 stable  security.debian.org 
  500 stable  dl.google.com 
  500 stable  deb.opera.com 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libapt-pkg4.12 (>= 0.9.8.2) | 0.9.8.2
libc6 (>= 2.15) | 2.17-3
libgcc1(>= 1:4.1.1) | 1:4.8.1-2
libstdc++6 (>= 4.6) | 4.8.1-2
debian-archive-keyring  | 2012.4
gnupg   | 1.4.12-7


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
aptitude  | 0.6.8.2-1
 OR synaptic  | 0.80.2
 OR wajig | 
dpkg-dev  | 1.16.10
apt-doc   | 
xz-utils  | 5.1.1alpha+20120614-2
python-apt| 0.8.9



--- Output from package bug script ---


-- 
Please remain calm, it's no use both of us being hysterical at the same time.


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

Bug#712544: RFS: xalan/1.11-1 [ITA]

[Mathieu Malaterre]

On Tue, Jun 18, 2013 at 8:36 AM, Bill Blough  wrote:
>
>
> Thanks Jakub!
>
> On Mon, Jun 17, 2013 at 10:40:44PM +0200, Jakub Wilk wrote
>> X: libxalan111: binary-file-built-without-LFS-support 
>> usr/lib/i386-linux-gnu/libxalan-c.so.111.0
>> (It might be worth fixing upstream, but I'm not sure if opening
>> files larger than 2GB is a realistic use-case for this library.)
>
> I believe I have addressed all of the issues you listed except for this one. 
> I may pose it as a question to the upstream dev mailing list and see
> what they say.
>
> I have uploaded the updated package to mentors.d.n.

Package looks pretty good. However I cannot build it a second time.
Looks like the clean rule is missing something:

$ dpkg-buildpackage -rfakeroot -us -uc
[...]
dh_clean
 dpkg-source -b xalan-1.11
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building xalan using existing ./xalan_1.11.orig.tar.gz
dpkg-source: warning: ignoring deletion of file c/config.guess
dpkg-source: warning: ignoring deletion of file c/config.sub
dpkg-source: info: local changes detected, the modified files are:
 xalan-1.11/c/configure
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/xalan_1.11-1.diff.w5Wkdf
dpkg-buildpackage: error: dpkg-source -b xalan-1.11 gave error exit status 2

thanks


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

Bug#712570: dvipsnam

[Shriramana Sharma]

For future reference, upstream author indicates that dvipsnam.def will
be the first preference in a future version rather than xcolors.sty:
http://lists.nongnu.org/archive/html/dvipng/2013-06/msg9.html.

One might want to ensure that the dependency will then be corrected
accordingly if necessary. (Currently the only TeX-related packages
dvipng depends on AFAICS are libkpathsea6 and texlive-base-bin and I'm
not sure whether the dependency tree will include texlive-latex-base
which currently contains dvipsnam.def.)

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा


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

Bug#703452: Near Future

[Cyril Bouthors]

On Mon, Jun 17, 2013 at 9:15 PM, Jonas Genannt
wrote:

> so Ansgar tells us, that the full license is missing in your
> debian/copyright file.
>

sounds easy to fix

I'll do that

Thanks


-- 
Cyril Bouthors - ISVTEC: Web Platform Managed Services and Scalability
14 avenue de l'Opéra, 75001 Paris. 1 rue Émile Zola, 69002 Lyon
Tél : 01 84 16 16 17 - Ligne directe : 0x7B9EE3B0E - Fax : 01 77 72 57 24

Bug#712636: erlang-oauth: RFP : erlang-oauth -- An Erlang OAuth 1.0 implementation

[Rodolphe Quiédeville]

Package: erlang-oauth
Severity: wishlist

Version: 1.3.0
URL : https://github.com/tim/erlang-oauth/
License : BSD
Description: An Erlang OAuth 1.0 implementation. Includes functions for
generating signatures (client side), verifying signatures (server side), and
some convenience functions for making OAuth HTTP requests (client side).



-- System Information:
Debian Release: 7.0
Architecture: i386 (x86_64)

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


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

Bug#706348: Sounds about right

[Jonas Smedegaard]

Your plan looks good.  I cannot spot flaws in it, but the real test is 
to actually try use it, e.g. like this:

  compass create /path/to/project --using bootstrap-sass


 - Jonas

P.S.

It missed your update to this bugreport back in April - sorry about 
that, and thanks for your friendly reminder in private just now :-)

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

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


signature.asc
Description: signature

Bug#692884: guilt conflicts with git 1.8

[Axel Beckert]

Hi Jonathan,

Jonathan Nieder wrote:
> >>> I'm not aware of any changes in Git 1.8 that could make guilt
> >>> incompatible.
> [...]
> > I intend to NMU this issue via the DELAYED/N queue. Patch will be
> > based on Jonathan Nieder's suggestion in http://bugs.debian.org/589708
> 
> Thanks!  FWIW this is also fixed upstream, as you probably noticed.

I did, but only when I fixed the homepage URL. I though fixed it the
same way. Well, it was your advice and your upstream commit, so no
wonder it looked the same. :-)

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


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

Bug#712638: tomcat7: dependency to tomcat-native is too weak (no version for libtcnative-1 specified)

[H.-Dirk Schmitt]

Package: tomcat7
Version: 7.0.40-2~precise1~ppa1
Severity: important


This is a forward to the upstream debian package from the original ubuntu bug 
report:
https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1092548

>As I backported tomcat7 7.0.34 from raring to precise I have seen the 
>following error message:
>
>> An incompatible version 1.1.22 of the APR based Apache Tomcat Native library 
>> is installed, while Tomcat requires version 1.1.24
>
>The reason is that the suggests line doesn't set a minimum version for 
>libtcnative-1.
>The tomcat 7.0.34 needs libtcnative-1 1.1.24 (not 1.1.22).


The situation still exists in the currently installed package. This a a 
"no-change-backport" from debian/sid.
Here is also libtcnative-1 without any version number specified.

The problem may break tomcat7 functionality on updates of the tomcat7 package.

Package: tomcat7
Priority: optional
Section: java
Installed-Size: 363
Maintainer: Debian Java Maintainers 

Architecture: all
Version: 7.0.40-2~precise1~ppa1
Recommends: authbind
Suggests: tomcat7-docs (>= 7.0.40-2~precise1~ppa1), tomcat7-admin (>= 
7.0.40-2~precise1~ppa1), tomcat7-examples (>= 7.0.40-2~precise
1~ppa1), tomcat7-user (>= 7.0.40-2~precise1~ppa1), libtcnative-1
Depends: tomcat7-common (>= 7.0.40-2~precise1~ppa1), ucf, adduser, debconf (>= 
0.5) | debconf-2.0
Filename: pool/main/t/tomcat7/tomcat7_7.0.40-2~precise1~ppa1_all.deb
Size: 51744




-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise-backports'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8.0-25-generic (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tomcat7 depends on:
ii  adduser3.113ubuntu2
ii  debconf [debconf-2.0]  1.5.42ubuntu1
ii  tomcat7-common 7.0.40-2~precise1~ppa1
ii  ucf3.0025+nmu2ubuntu1

Versions of packages tomcat7 recommends:
pn  authbind  

Versions of packages tomcat7 suggests:
pn  libtcnative-1 1.1.24-1~precise1~ppa1
pn  tomcat7-admin 7.0.40-2~precise1~ppa1
pn  tomcat7-docs  7.0.40-2~precise1~ppa1
pn  tomcat7-examples  7.0.40-2~precise1~ppa1
pn  tomcat7-user  

-- Configuration Files:
/etc/tomcat7/catalina.properties changed [not included]
/etc/tomcat7/context.xml changed [not included]
/etc/tomcat7/logging.properties changed [not included]
/etc/tomcat7/server.xml changed [not included]
/etc/tomcat7/tomcat-users.xml [Errno 13] Keine Berechtigung: 
u'/etc/tomcat7/tomcat-users.xml'

-- debconf information excluded


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

Bug#712570: dvipsnam

[Jan-Åke Larsson]

On 06/18/2013 09:19 AM, Shriramana Sharma wrote:
> For future reference, upstream author indicates that dvipsnam.def will
> be the first preference in a future version rather than xcolors.sty:
> http://lists.nongnu.org/archive/html/dvipng/2013-06/msg9.html.
> 
> One might want to ensure that the dependency will then be corrected
> accordingly if necessary. (Currently the only TeX-related packages
> dvipng depends on AFAICS are libkpathsea6 and texlive-base-bin and I'm
> not sure whether the dependency tree will include texlive-latex-base
> which currently contains dvipsnam.def.)

No, that is not the case. Sorry for the confusion. For clarity: the
color definitions used will be, in falling order of preference:

"xcolor.sty","dvipsnam.def","svgnam.def","x11nam.def"

None of these will be required for proper functionality, but only be
used for their color naming schemes. The worst that can happen is an
"Undefined color" error.

You do not need to list more packages as requirements. There is an
unfortunate bug in dvipng 1.14, that causes a segfault if "xcolor.sty"
is not present AND a color name (not defined in the .tex file) is used.
A workaround for dvipng 1.14 is to install the xcolor package.

/Jan-Åke


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

Bug#710444: [LCFC] templates://cloud-init/{cloud-init.templates}

[Christian PERRIER]

> Putting it all together:

.../...

For the record, I actually picked Justin's last version (the one that
follows the above sentence in the mail I'm answering to).

But I'm waiting for Charles' input, of course.



signature.asc
Description: Digital signature

Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2

[Didier 'OdyX' Raboud]

Le dimanche, 9 juin 2013 15.08:12, Bill Allombert a écrit :
> On Sun, Jun 09, 2013 at 02:19:51PM +0200, Didier 'OdyX' Raboud wrote:
> > Control: tags -1 +moreinfo
> > 
> > Hi Bill, and thanks for your bugreport,
> > 
> > Le samedi, 8 juin 2013 21.31:32, Bill Allombert a écrit :
> > > There is a circular dependency between libcupsfilters1 and
> > > libcupsimage2:
> > > 
> > > libcupsfilters1 :Depends: libcupsimage2 (>= 1.4.0)
> > > libcupsimage2 :Depends: libcupsfilters1 (>= 1.0~b1)
> > 
> > Indeed. Good catch, thanks.
> > 
> > > Circular dependencies involving shared libraries are known to cause
> > > problems during upgrade between stable releases, so we should try to
> > > get rid of them.
> > 
> > The problem here is that the ABI provided by libcupsimage2 has been split
> > at version 1.6 between libcupsimage2 and libcupsfilters1, hence the
> > depends of libcupsimage2 on libcupsfilters1.
> 
> But libcupsfilters1 already exist in wheezy, so this more a transfer than a
> split ? A split would be more easily dealt with.

Indeed, it's a transfer of symbols without SOVERSION bump. I don't 
particularily like it, but it's there…

> > This could probably be downgraded to a
> > Recommends, but brings in the risk that package A, depending on
> > libcupsimage2 1.5 stops to work if libcupsimage2 is upgraded to 1.6 and
> > libcupsfilters1 is not installed (aka partial upgrade).
> 
> I'd like to be convinced the dependency is actually sufficient to fix
> partial upgrade, especially since dpkg will have to break the circular
> dependency anyway.

Fair enough, but the dependencies ensure that dpkg is only happy with the two 
libraries installed at the same time, so the window of brokenness opportunity 
is quite small.

> It might be necessary to introduce an extra package.

What package do you have in mind?

> Is there packages in wheezy that use the libcupsimage2 symbols that are now
> in libcupsfilters1 but do not depend on libcupsfilters1 ?

As for the symbols I don't know (but could probably given more work), but 
these reverse dependencies (from other source packages) are in place in 
Wheezy:

libcupsimage2-dev ← libgs-dev

libcupsimage2 ← cups-filters, depends on libcupsfilters1
libcupsimage2 ← libcupsfilters1 (shlibs dependency, can't be removed)
libcupsimage2 ← ghostscript-cups, doesn't depend on libcupsfilters1
libcupsimage2 ← libescpr1 (dropped in Jessie)
libcupsimage2 ← libgs9, doesn't depend on libcupsfilters1
libcupsimage2 ← lsb-printing, doesn't depend on libcupsfilters1 [0] 
libcupsimage2 ← printer-driver-c2esp, doesn't depend on libcupsfilters1
libcupsimage2 ← printer-driver-escpr, doesn't depend on libcupsfilters1
libcupsimage2 ← printer-driver-gutenprint, doesn't depend on libcupsfilters1
libcupsimage2 ← printer-driver-hpcups, doesn't depend on libcupsfilters1
libcupsimage2 ← printer-driver-ptouch, doesn't depend on libcupsfilters1
libcupsimage2 ← printer-driver-splix, doesn't depend on libcupsfilters1

So only cups-filters seems fine, for good reasons.

How can I check which symbols are used by each package without rebuilding with 
a special set of packages?

Cheers,

OdyX

[0] LSB only mandates these symbols, all in libcupsimage2:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Printing/LSB-
Printing/libcupsimage.html


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

Bug#712283: qcontrol: add support for i386/amd64 based devices like the QNAP TS-569 Pro

[Ian Campbell]

On Mon, 2013-06-17 at 00:16 +0200, Christoph Anton Mitterer wrote:
> On Sun, 2013-06-16 at 11:36 +0100, Ian Campbell wrote:
> > Hrm, not a lot there to even say we are running on qnap at all, never
> > mind which specific variant.
> Yeah... I haven't found much more so far... any idea about other tools
> like dmidecode which could give some info here?

Other than having a grep around in /sys and /proc for (caseinsensitive)
qnap not much springs to mind.

> With the ARM based devices you just base this on the presence of that
> gpio stuff? Couldn't that be available on other machines as well?

We initially gate on /proc/cpuinfo:Hardware to discover which broad
class of QNAP device we are running on, then use GPIOs to discover the
specific set of peripherals which this particular variant has (the main
one being the LCD).

However in order to be able to consult the GPIOs we need to know we are
on some particular class of hardware, and not some totally different ARM
or x86 box.

> Do we need the check at all? You don't start anything per default, and
> if the user configures a device which he doesn't have it's his fault...

On ARM we use it to provide a suitable default config at package install
time. We use it in the initscript to know whether LEDs/buzzers are
available (i.e. to signal "boot completed").

On x86 we could provide an empty default configuration and abstract the
initscript stuff a bit more to make it easier for people to configure by
hand. However before we do that I think we need to simply get the daemon
working at all on such platforms.

> 
> I would rather want to have automatically determined,... which ttySx is
> what...
> If we could determine that correctly (i.e. it's an A125... or it's a PIC
> xyz ... then we could probably ignore much of the "which QNAP model is
> it"... sure they may not use all functionality of the PIC, but at least
> this shouldn't cause much harm...
> 
> Do you think it's possible to determine which serial device belongs to
> what? And also which type of PIC/etc. is behind it?

At the moment it sounds like it isn't even possible to determine that
you are running on a QNAP device at all. Remember that once the package
exists on x86 people could try and install on a whitebox x86 server or
any random piece of hardware, we need to do the right (i.e.
non-destructive) thing in this case.

Even once we know it is a QNAP I don't think we can safely just probe
serial ports looking for things.

> btw: have you an idea about the difference between lcd clear and reset?!

They are different byte sequences. If I had to guess I would say that
clear just writes all cells to blank and reset actually power cycles the
LCD and/or its controller.

> > Right, on ARM they are all controlled by communicating with the PIC via
> > a serial port, typically ttyS1.
> Ok I see... so one more question for my understanding... if you use the
> serial devices for all this... why do you have/need the gpio_stuff?
> (answered below I guess)

Yes, its for the buttons which don't go via the PIC.

> >  (rebooting is the only exception I'm aware of)
> I saw that pic_raw command... what's the matter with it?

It is from the QNAP drivers. We don't have that driver.

>  I mean can't
> one just use normal "reboot"? Is there anything special with it?

The reboot handing is done as the very last thing the kernel does, after
it has stoppoed all processes umounted all filesystems and quiesced all
the disks etc. This little bit is done in the kernel by opening the
serial and writing the couple of control bytes to reset the board.

> One thing about the gpio_keys... on the ARM devices... does this work
> out of the box? I.e. is it auto-loaded... and/or is any special
> configuration needed? Is a backend GPIO driver needed/auto-loaded?
> Cause GPIO-keys by itself seems to be pretty generic...

I think the installer arranges to have it loaded, by writing the name
to /etc/modules.

The module itself is pretty generic but the GPIO->keys mapping is
platform specific. e.g. for an ARM platform it is defined in the
platform code. See qnap_ts41x_buttons[] in
arch/arm/mach-kirkwood/ts41x-setup.c (in the kernel). And something
needs to provide the driver for the GPIO controller.

> On the Debian amd64 kernels that module is not build... so I built my
> own kernel with it... nevertheless... no success so far... perhaps I'm
> missing something else... at least that device
> in /dev/input/gpioSomething didn't turn up.

You know that GPIO == General Purpose I/O, right? They are literally
just pins on the processor (or some chipset peripheral, more likely on
x86 I think) which you can control to be outputs or inputs, set high/low
or read the current level (perhaps with an IRQ trigger). The only way to
use them is to know how the hardware designed has wired them up.

Something needs to tell the driver which GPIO lines correspond to which
keys. This is a property of the particular hardware platform.

You also need a driver for the par

Bug#710876: [LCFC] templates://ircd-hybrid/{ircd-hybrid.templates}

[Christian PERRIER]

This is the last call for comments for the review of debconf
templates for ircd-hybrid.

The reviewed templates will be sent on Thursday, June 20, 2013 to this bug 
report
and a mail will be sent to this list with "[BTS]" as a subject tag.


-- 


Template: ircd-hybrid/no-more-ssl
Type: boolean
Default: true
_Description: Continue installing version with disabled OpenSSL support?
 Due to licensing issues, ircd-hybrid is no longer built by default with
 OpenSSL. This will be addressed in a future release, pending a rewrite
 of the SSL layer with GnuTLS.
 .
 If any existing server links take advantage of cryptlinks, see
 /usr/share/doc/ircd-hybrid/CRYPTLINKS.txt for the easiest way to build
 ircd-hybrid with SSL support.

Template: ircd-hybrid/restart_on_upgrade
Type: boolean
Default: true
_Description: Restart ircd-hybrid on each upgrade?
 Please choose whether the ircd-hybrid daemon should be restarted
 every time a new version of this package is installed.
 .
 Automatic restarts may be problematic if, for instance, the server is
 running with manually loaded modules, which will need to be reloaded
 after the restart.
 .
 If you reject this option, you will have to restart ircd-hybrid via
 "service ircd-hybrid restart" when needed.

Template: ircd-hybrid/upgrade_secure_links_warn
Type: boolean
Default: true
_Description: Upgrade ircd-hybrid to version without cryptlink support?
 The 8.x version of ircd-hybrid includes a change to the way secure server
 links are implemented, which is not backwards-compatible with ircd-hybrid 7.x,
 from which you are upgrading.
 .
 If you have any secure server links (cryptlinks) configured with this
 server, you should plan to either upgrade all servers in lock-step, or
 temporarily configure non-cryptlink server links, to ensure the continuity
 of your IRC links.

Template: ircd-hybrid/upgrade_no_services_warn
Type: boolean
Default: true
_Description: Upgrade ircd-hybrid to version without compatible services?
 The 8.x version of ircd-hybrid includes a change to the way services are
 supported, losing compatibility with hybserv.
 .
 The plan is for hybserv to be replaced by anope, which is compatible
 with Hybrid 8 services.
Source: ircd-hybrid
Section: net
Priority: optional
Build-Depends: debhelper (>= 8),
 zlib1g-dev,
 docbook-to-man,
 flex,
 bison,
 libpcre3-dev (>= 6.3),
 automake1.13,
 dh-autoreconf,
 libltdl-dev 
Build-Conflicts: autoconf2.13
Maintainer: Dominic Hargreaves 
Standards-Version: 3.9.4
Homepage: http://ircd-hybrid.com/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/dom/ircd-hybrid.git
Vcs-Git: git://anonscm.debian.org/users/dom/ircd-hybrid.git

Package: ircd-hybrid
Architecture: any
Conflicts: ircd-ircu, ircd-irc2, dancer-ircd, oftc-hybrid
Pre-Depends: debconf (>= 0.5) | debconf-2.0
Depends: ${shlibs:Depends}, ${misc:Depends} 
Provides: ircd
Recommends: whois
Suggests: hybserv
Description: high-performance secure IRC server
 ircd-hybrid is a stable, high-performance IRC server that features:
 .
  * If enabled, SSL client support and server-to-server RSA encryption;
  * Compressed server links;
  * Channel exceptions (+e) and invitation exceptions (+I);
  * New configuration file format;
  * Halfops (+h) and anti-spam user mode +g;
  * Dynamically loadable modules;
  * Channel and nickname RESV's (reservations).

Package: hybrid-dev
Section: devel
Architecture: all
Depends: ${misc:Depends}
Suggests: ircd-hybrid
Description: high-performance secure IRC server - development files
 These are the headers used when writing modules for ircd-hybrid.
 For more information on how to write these modules, see the ircd-hybrid
 documentation or example_module.c in the source code for ircd-hybrid.
 .
 It also includes mbuild-hybrid, a shell script that simplifies building 
 and installation of such modules. This shell script is simplistic and
 assumes a lot; if you possess clue, you will know what to do anyway.


signature.asc
Description: Digital signature

Bug#712283: qcontrol: add support for i386/amd64 based devices like the QNAP TS-569 Pro

[Ian Campbell]

On Mon, 2013-06-17 at 00:49 +0200, Christoph Anton Mitterer wrote:
> Uhm... one stupid question... how many serial devices do you have on
> your ARM based QNAPs? And is that one from the PIC the same as the one
> the A124 listens on?

Now, they are two separate peripherals.

On all of the ARM device ttyS1 is the PIC. ttyS0 is either the serial
console or the LCD. On systems which have an it is selectable (via a
jumper, connected to a GPIO) whether ttyS0 is the serial console or the
LCD. On devices without an LCD it is just always the serial console.

My ARM devices don't have ttyS3 or 4. They are probably spare on x86
because PC platforms often have four serial devices.

> 
> I have
> ttyS0 - not sure what this is...

Probably the PIC.

> ttyS1 - the A125
> ttyS2 - seems to be unusable
> ttyS3 - seems to be unusable

Ian.



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

Bug#712639: gnu-efi: New upstream version gnu-efi-3.0u available

[Adam Baxter]

Package: gnu-efi
Version: 3.0s+debian-3
Severity: wishlist
Tags: upstream

Dear Maintainer,
A new version of gnu-efi is available over at sf.net. It's required for 
building 
the latest version of syslinux-efi from git.

See http://www.syslinux.org/archives/2013-June/020155.html and 
http://sourceforge.net/projects/gnu-efi/files/

Thanks,
Adam Baxter


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

Bug#712520: [clang-3.2] dependency issue: needs libstdc6++-4.8-dev, not 4.7

[Sylvestre Ledru]

On 16/06/2013 20:30, Bastien Montagne wrote:
> Package: clang-3.2
> Version: 1:3.2repack-8
> Severity: normal
> 
> --- Please enter the report below this line. ---
> Think dependency for libstdc++6 dev package is wrong, clang-3.2 package
> needs 4.8, not 4.7.
> 
> Was trying to compile OSL, took me ages to finally figure out that
> installing libstdc++6-4.8-dev package fixed the issue I was facing
> (clang not finding stl includes).
Thanks for the feedback. I am waiting for the transition of
llvm-toolchain-3.2 into testing. Once it is done, I will make and upload
to depends on 4.8 headers.

Sylvestre


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

Bug#712151: Bug#712057: Bug#712151: binutils-mingw-w64-i686: conflicts with binutils, uninstallable

[Stephen Kitt]

On Fri, 14 Jun 2013 12:26:04 +0100, Simon McVittie  wrote:
> On Fri, 14 Jun 2013 at 00:20:37 +0200, Stephen Kitt wrote:
> > On Thu, 13 Jun 2013 19:01:40 +0200, Stephen Kitt  wrote:
> > > Matthias, to help upgrades this will still need a Breaks statement in
> > > binutils - presumably binutils-mingw-w64 (<< 2.23.52.20130612-1+3).
> > 
> > Of course that's binutils-mingw-w64-i686 (<< 2.23.52.20130612-1+3),
> > binutils-mingw-w64-x86-64 (<< 2.23.52.20130612-1+3).
> 
> I think it needs both Breaks and Replaces to deal with file conflicts
> gracefully?

Yes indeed, thanks for pointing that out!

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#710668: version in experimental causes FTBFS for packages using libmagick*

[Bastien ROUCARIES]

Please test newer experimental version.

Bastien

On Sat, Jun 1, 2013 at 8:21 PM, Bastien ROUCARIES
 wrote:
> OK will correct with next iteration with correction of size_t symbols.
>
> Pkgconfig need to be per arch and add arch include dir
>
> Thanks for the report I am since 2am UTC on my phone away of my compile farm


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

Bug#712641: lintian: libgd-dev is now a real package

[Laurent Bigonville]

Package: lintian
Version: 2.5.13
Severity: normal

Hi,

Lintian is complaining about libgd-dev being a virtual package. But
since the 2.1 upload libgd-dev is a real package.

This package should be removed from the data/fields/virtual-packages
list.

Cheers

Laurent Bigonville

-- 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.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.23.52.20130612-1
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   1:5.14-2
ii  gettext0.18.2.1-1
ii  hardening-includes 2.3
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.28
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.34-1
ii  libdpkg-perl   1.16.10
ii  libemail-valid-perl0.190-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.3-7
ii  patchutils 0.3.2-2
ii  perl [libdigest-sha-perl]  5.14.2-21
ii  t1utils1.37-2

Versions of packages lintian recommends:
pn  libperlio-gzip-perl 
ii  perl-modules [libautodie-perl]  5.14.2-21

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.16.10
ii  libhtml-parser-perl3.71-1
ii  libtext-template-perl  1.45-2
ii  xz-utils   5.1.1alpha+20120614-2

-- 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#712643: system-config-printer fails to add a new printer on samba network

[Ivan Garcia]

Package: system-config-printer
Version: 1.4.1-2
When I try to add a new printer on samba network I can navigate to find the new 
printer but when I have to introduce the username, domain and password the 
buttons "accept" and "cancel" don't work.
This problem is already solved in redhat: 
https://bugzilla.redhat.com/show_bug.cgi?id=971459
In this links, there more information about the bug, and how to reproduce it.

Bug#712642: mytop: Feature Requests

[Olaf van der Spek]

Package: mytop
Version: 1.6-6
Severity: wishlist

Dear Maintainer,

I noticed you updated MyTop, thanks for that!

I've got some comments / requests, if you don't mind.

> F - unFilter the dispaly
> S - change slow quiery hightlighting

Typos

> load 1.07 1.05 1.04 3/337 1785 up 3+17:15:25 [06:07:56]

Having this in the absolute top right looks wrong on a very wide monitor, could 
you move it to the left?

> i - toggle the display of idle (sleeping) threads

Could idle threads be hidden by default? They're not that interesting.

Does an option exist to hide user, host and DB columns to make more room for 
the query column?

> Queries: 38.9Mqps:  127 Slow:   16.7k Se/In/Up/De(%): 33/42/09/00
> Sorts:83 qps now:  160 Slow qps: 0.0  Threads:   11 (   1/  13) 
> 28/57/04/00

I think alignment is off by one. 

Greetings,

Olaf

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

Kernel: Linux 3.2.0-4-amd64 (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 mytop depends on:
ii  libconfig-inifiles-perl  2.75-1
ii  libdbd-mysql-perl4.021-1+b1
ii  libdbi-perl  1.622-1
ii  libterm-readkey-perl 2.30-4+b2
ii  perl 5.14.2-21

mytop recommends no packages.

Versions of packages mytop suggests:
ii  perl [libtime-hires-perl]  5.14.2-21

-- 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#711874: apt-listbugs: should allow the user to filter on more severity/tag combinations

[Vincent Lefevre]

On 2013-06-17 23:46:32 +0200, Francesco Poli wrote:
>  → the most common use-case for apt-listbugs is: one invocation
> followed by another one done a while later and probably for a different
> set of packages to be checked for bugs

Perhaps most common, but executing apt-listbugs several times in short
interval times on a similar set of packages is not rare for me, even
before doing the OR. And I suppose that this can be the same for other
users due to the limitation of Debian tools (apt, aptitude?): when one
sees that apt-listbugs mentions a broken package before an upgrade,
one generally wants to remove this package from the upgrade list, and
the only way to do this is to refuse the upgrade and do it again (e.g.
just after) without this package. So, apt-listbugs is run twice on a
very similar set of packages.

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


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

Bug#712644: clive: migrate to cclive

[Ansgar Burchardt]

Package: clive
Severity: important
Tags: jessie sid

I would like to get rid of clive during the jessie release cycle. It is
only maintained upstream and cclive is recommended instead. Both support
the same sites as they rely on libquvi, but there are a few differences
in the command-line interface.

My current idea is to replace clive with a transition package that
depends on cclive and includes a clive -> cclive symlink. It should also
include a NEWS.Debian entry.

The clive package could then be removed with jessie+1.

Ansgar


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

Bug#712646: Please backport libvirt/1.0.6-1 to bpo (once it reaches testing)

[Sandro Tosi]

Source: libvirt
Version: 1.0.6-1
Severity: wishlist

Hello,
While installing Debian 7.1, with libvirt/0.9.12-11+deb7u1, on a HP ProLiant
DL385 G7 we notices all the VMs were pinned on CPU 0, without using the second
CPU available.

Looking at the changelog between stable and sid, we noticed several entries that
might solve our issue, so we install the sid package and the problem went away.

Can you please backport libvirt/1.0.6-1 to wheezy BPO as soon as it reached
testing?

Thanks in advance,
Sandro

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

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


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

Bug#712645: ITP: visp-images -- Visual Servoing Platform Reference Files

[Thomas Moulard]

Package: wnpp
Severity: wishlist

ViSP, standing for Visual Servoing Platform, is unique. This software
is a complete cross-platform solution that allows prototyping and
developing applications in visual tracking and visual servoing.

ViSP can be useful in robotics, computer vision, augmented reality and
computer animation.

ViSP is already packaged. This package contains reference data (images)
required by the test suite and program examples.

Package repository:
http://anonscm.debian.org/gitweb/?p=debian-science/packages/visp-images.git

--
Thomas Moulard


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

Bug#712038: Missing copyright information

[Sebastien Jodogne]

Dear Mathieu,

Sorry for missing this copyright information. I have updated the 
upstream source code of Orthanc:


https://code.google.com/p/orthanc/source/browse/OrthancServer/FromDcmtkBridge.cpp

I will fix the "debian/copyright" in the next release.

Sorry again,
Sébastien-



On 06/12/2013 02:00 PM, Mathieu Malaterre wrote:

Package: orthanc
Version: 0.4.0-1
Severity: serious
File: orthanc
Tags: upstream

Neither d/copyright nor upstream COPYING seems to inform that source contains 
code lifted from another project:

$ grep BSD OrthancServer/FromDcmtkBridge.cpp
  * Mathieu Malaterre (under a BSD license).



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

Bug#712647: ITP: digitd -- A simple, flexible and safe finger daemon

[Radovan Garabík]

Package: wnpp
Severity: wishlist
Owner: "Radovan Garabík" 

* Package name: digitd
  Version : 1.0
  Upstream Author : Reuben Thomas 
* URL : https://github.com/rrthomas/digitd
* License : GPL
  Programming Lang: Perl
  Description : A simple, flexible and safe finger daemon

digitd is ready-to-run out of the box, yet easy to customize. It
allows users to opt in to being fingerable, rather than the usual
opt-out.

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (900, 'stable'), (400, 'testing')
Architecture: powerpc (ppc)


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

Bug#712593: paraview: Requires different version of hdf5 library, else crashes on XMF opening

[Wojciech Aniszewski]

There is none. Sorry, I didn't know that one made it through. Please  
close this one.

regards
Wojtek

Anton Gladky  a écrit :


Hi, what is the difference from your previous bugreport #711561?

Anton


On 06/17/2013 06:15 PM, Wojciech Aniszewski wrote:

Package: paraview
Version: 4.0.0~rc1-1
Severity: important

Opening an xmf file (a descriptive file for an hdf5 format), which was
created with current hdf5 version (1.8.8-9.1 as below) causes paraview
to produce a warning message and crash.
The message is like this:
--
Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application
continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.8.10, library is 1.8.8
--
As the message says, an environment variable can be set to get around
this, but in general, HDF5 should be updated in testing. Note that when
paraview is not started from a console, user may not see the message at
all and end up with program crushing everytime.

Wojciech Aniszewski


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

Kernel: Linux 3.2.0-4-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 paraview depends on:
ii  libavcodec53   6:0.8.7-1
ii  libavformat53  6:0.8.7-1
ii  libavutil516:0.8.7-1
ii  libc6  2.17-3
ii  libexpat1  2.1.0-3
ii  libfreetype6   2.4.9-1.1
ii  libgcc11:4.8.0-7
ii  libgl1-mesa-glx [libgl1]   8.0.5-6
ii  libhdf5-openmpi-7 [libhdf5-7]  1.8.8-9.1
ii  libjpeg8   8d-1
ii  libogg01.3.1-1
ii  libopenmpi1.3  1.4.5-1
ii  libpng12-0 1.2.49-4
ii  libpython2.7   2.7.5-4
ii  libqt4-help4:4.8.4+dfsg-4
ii  libqt4-network 4:4.8.4+dfsg-4
ii  libqtcore4 4:4.8.4+dfsg-4
ii  libqtgui4  4:4.8.4+dfsg-4
ii  libqtwebkit4   2.2.1-5
ii  libstdc++6 4.8.0-7
ii  libswscale26:0.8.7-1
ii  libtheora0 1.1.1+dfsg.1-3.1
ii  libtiff4   3.9.6-11
ii  libx11-6   2:1.5.0-1+deb7u1
ii  libxml22.8.0+dfsg1-7+nmu1
ii  libxt6 1:1.1.3-1+deb7u1
ii  tcl8.4 [tclsh] 8.4.19-5
ii  tcl8.5 [tclsh] 8.5.11-2
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages paraview recommends:
ii  mpi-default-bin  1.0.1
ii  paraview-doc 4.0.0~rc1-1
ii  paraview-python  4.0.0~rc1-1

Versions of packages paraview suggests:
pn  h5utils 
pn  hdf5-tools  










--
Wojtek Aniszewski
[Eng: voyteck aanishevsky]
[Fr:  vôytek anichévsky]

 /^..^\  8971f0c181a69d52e444038ce7c8349f...
( (••) ) ...519a5fa111232335e27436a0236888f3
(|)_._(|)~


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

Bug#692884: guilt conflicts with git 1.8

[Axel Beckert]

Hi Iulian,

as usual, some things you notice only after the upload:

Axel Beckert wrote:
> JFTR: The test suite already fails with git 1:1.7.10.4-2 (the last git
> 1.7.x before an 1.8.x version was uploaded to unstable):
> 
[...]
> 025: --- t-025.out  2013-06-17 16:47:39.0 +
> +++ /tmp/guilt.log. 2013-06-17 21:04:50.0 +
> @@ -4,6 +4,7 @@
>  All patches popped.
>  % guilt push
>  Applying patch..file
> +fatal: unrecognized input
>  Patch applied.
>  % list_files
>  d .git/patches
[...]

I suspected these test failures are harmless, but I wasn't 100% sure
as I didn't investigate where the "fatal: unrecognized input" lines
came from.

Ubuntu patched the guilt package so that the test suite runs at build
time. They also patched the test suite to ignore all "fatal:
unrecognized input" lines.

They also rewrote debian/rules to a minimal dh7 style with just one
override. I think most of the patch could be incorporated into
Debian's guilt package. (But that would be too bold for a normal NMU
anyway. :-)

See https://patches.ubuntu.com/g/guilt/guilt_0.35-1ubuntu2.patch

(But take care, quilt's .pc directory errornously seems part of the
Ubuntu patch.)

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


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

Bug#706031: linux-image-3.2.0-4-amd64: WARNING at include/net/mac80211.h:3575 rate_control_send_low+0xa3/0x16c [mac80211]

[Pablo Oliveira]

Dear maintainers,

I am also experiencing this bug on kernel 3.2.0-4-amd64 #1 SMP Debian
3.2.46-1 x86_64 GNU/Linux. Here is the relevant output in
/var/log/messages:

Jun 17 18:30:37 ix kernel: [14217.246449] WARNING: at
/build/linux-s5x2oE/linux-3.2.46/include/net/mac80211.h:3575
rate_control_send_low+0xa3/0x16c [mac80211]()
Jun 17 18:30:37 ix kernel: [14217.246453] Hardware name: HP ProBook 6470b
Jun 17 18:30:37 ix kernel: [14217.246454] Modules linked in: bnep
rfcomm pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
binfmt_misc nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop
snd_hda_codec_hdmi snd_hda_codec_idt uvcvideo videodev btusb bluetooth
v4l2_compat_ioctl32 media joydev arc4 tpm_infineon iTCO_wdt iwlwifi
snd_hda_intel snd_hda_codec snd_hwdep i915 hp_accel snd_pcm lis3lv02d
mac80211 snd_page_alloc snd_timer cfg80211 coretemp hp_wmi parport_pc
sparse_keymap drm_kms_helper drm psmouse tpm_tis input_polldev
crc32c_intel ac acpi_cpufreq iTCO_vendor_support parport wmi
i2c_algo_bit serio_raw pcspkr evdev ghash_clmulni_intel snd tpm rfkill
battery mperf power_supply i2c_core video processor tpm_bios container
button soundcore cryptd ext4 crc16 jbd2 mbcache sg sr_mod usbhid hid
cdrom sd_mod crc_t10dif xhci_hcd firewire_ohci ahci libahci ehci_hcd
sdhci_pci sdhci mmc_core firewire_core crc_itu_t e1000e libata usbcore
scsi_mod thermal thermal_sys usb_common [last unloaded: scsi_wait_scan
Jun 17 18:30:37 ix kernel: ]
Jun 17 18:30:37 ix kernel: [14217.246536] Pid: 3, comm: ksoftirqd/0
Tainted: G   O 3.2.0-4-amd64 #1 Debian 3.2.46-1
Jun 17 18:30:37 ix kernel: [14217.246539] Call Trace:
Jun 17 18:30:37 ix kernel: [14217.246546]  [] ?
warn_slowpath_common+0x78/0x8c
Jun 17 18:30:37 ix kernel: [14217.246556]  [] ?
rate_control_send_low+0xa3/0x16c [mac80211]
Jun 17 18:30:37 ix kernel: [14217.246563]  [] ?
rs_get_rate+0x51/0x142 [iwlwifi]
Jun 17 18:30:37 ix kernel: [14217.246572]  [] ?
rate_control_get_rate+0x7b/0x139 [mac80211]
Jun 17 18:30:37 ix kernel: [14217.246581]  [] ?
invoke_tx_handlers+0x76b/0xded [mac80211]
Jun 17 18:30:37 ix kernel: [14217.246597]  [] ?
ieee80211_tx+0x69/0x94 [mac80211]
Jun 17 18:30:37 ix kernel: [14217.246602]  [] ?
load_TLS+0x7/0xa
Jun 17 18:30:37 ix kernel: [14217.246612]  [] ?
ieee80211_tx_pending+0xd5/0x1a3 [mac80211]
Jun 17 18:30:37 ix kernel: [14217.246616]  [] ?
tasklet_action+0x73/0xc2
Jun 17 18:30:37 ix kernel: [14217.246620]  [] ?
__do_softirq+0xb9/0x177
Jun 17 18:30:37 ix kernel: [14217.246624]  [] ?
run_ksoftirqd+0x7a/0x118
Jun 17 18:30:37 ix kernel: [14217.246627]  [] ?
__do_softirq+0x177/0x177
Jun 17 18:30:37 ix kernel: [14217.246632]  [] ?
kthread+0x76/0x7e
Jun 17 18:30:37 ix kernel: [14217.246637]  [] ?
kernel_thread_helper+0x4/0x10
Jun 17 18:30:37 ix kernel: [14217.246641]  [] ?
kthread_worker_fn+0x139/0x139
Jun 17 18:30:37 ix kernel: [14217.246645]  [] ?
gs_change+0x13/0x13

Kind Regards,

Pablo


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

Bug#712188: choqok

[Michael Prokop]

* Richard Bell [Fri Jun 14, 2013 at 12:50:28AM +0100]:

> I have a small net of i386 machines running the latest version of
> testing. Choqok was working fine until approx two days ago when I
> stopped receiving update and posts. There were no error messages
> at all during normal use or when I updated timelines. I tried to
> install choqok on another machine on my net, but only got as far
> as entering the email address for the user with the error message
> invalid user name or password. Looks like something in a recent
> upgrade is preventing choqok from connecting with twitter,
> although there are no error messages.

This is caused because twitter discontinued the API v1.0 on June 11,
2013 as stated on https://dev.twitter.com/calendar ("Retirement of
deprecated API v1.0. Retirement of Basic Auth support on Streaming
API.") choqok in Debian until and including version 1.3-1+b1 only
supports this old API and therefore choqok is broken for any twitter
usage.

The Debian package mentioned in
https://bugs.kde.org/show_bug.cgi?id=264091 works fine for me
though. Would be nice to see an upload of choqok including the patch
from KDE issue 264091 as choqok as it is just silently stops working
without *any* feedback to the user at all. (Might be even
interesting for getting an update to the upcoming Debian 7.2 point
release IMHO.)

HTH && regards,
-mika-


signature.asc
Description: Digital signature

Bug#679209: Opening a normal terminal when root terminal is open does not work

[Simon McVittie]

On 18/06/13 03:10, Bas Wijnen wrote:
> Gnome 3 (non-classic) has a different way of handling
> applications. When selecting to open an already open application,
> the intended behaviour is to focus that window, not to open a new
> one.  You may not like it, but that is not a bug; it's an
> intentional feature.

Right. (FWIW, if you don't like it, I think there's an extension that
makes clicking on applications always behave like "new window".)

> So the question is whether a terminal and a root terminal are the
> same application.  Technically they are, intuitively they aren't.

The "root terminal" .desktop file is provided by gksu, and is
implemented as "gksu /usr/bin/x-terminal-emulator"; so they are both
gnome-terminal, but run as different users. The app-centric model in
GNOME Shell doesn't really have an answer for that, except "stop
running GUI apps as root" (see below).

> The bug is that it is different: if I read this right, then a root 
> terminal is not considered the same thing as a terminal (so it can
> be opened when a terminal is open), but a terminal is the same
> thing as a root terminal (so it cannot be opened "normally").

The reason for the difference is that in each situation, one flavour
of terminal is a running application and one is a launcher for an
as-yet unstarted application. GNOME Shell can't tell exactly what the
launcher is going to do.

When you're running a root gnome-terminal and you click on Terminal in
the applications list, GNOME Shell asks: is there a window open that I
have associated with gnome-terminal.desktop via various heuristics?
(Mostly WM_CLASS, but there are others: see the source code to the C
parts of gnome-shell if you're interested.) The answer is "yes",
because the root gnome-terminal still has WM_CLASS=gnome-terminal, so
it brings it to the foreground instead of starting a new one.

When you're running a normal gnome-terminal and you click on Root
Terminal in the applications list, GNOME Shell asks: is there a window
open that I have associated with gksu-terminal.desktop? The answer is
"no", because windows with WM_CLASS=gksu-terminal don't exist, and it
doesn't know that on this particular system, gksu-terminal ends up
running gnome-terminal. So, it runs gksu, starting a new
gnome-terminal instance (as root).

I would argue that running a GUI application as root is not a great
idea anyway[1][2], and I suspect gnome-terminal and GNOME Shell
upstream developers would consider this to be something they don't
want to support. There has been a general move towards separating
things into an unprivileged GUI frontend that communicates with a
privileged non-GUI daemon, with authorization via PolicyKit (like
GNOME communicating with NetworkManager, BlueZ, Avahi etc.), which I
think is a better model.

In particular, applications under (gk)su (although not sudo or pkexec)
inherit environment variables from the user environment, leading to
failure to do things like connect to D-Bus (because they see the
user's $DBUS_SESSION_BUS_ADDRESS: D-Bus implementations can't
currently connect to a different user's session bus even when running
as root, and if they could, it would potentially be a security flaw,
so they probably shouldn't gain this functionality).

A better implementation of "give me a GUI terminal where I can run
root commands" might be something like

x-terminal-emulator -e pkexec su --login

or if the "can run other X applications from this terminal as root"
property is required,

/bin/sh -c 'exec x-terminal-emulator -e pkexec env
DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY su --login'

or we could follow what Ubuntu did: get rid of the "Root Terminal"
launcher altogether, and instead say "open a normal terminal and use
sudo, or sudo -s if you need a root shell".

(The "su" in those pkexec command-lines is unnecessary for
privilege-escalation - pkexec does that bit - but was the first way I
found to say "find and execute root's configured login shell"... there
is probably a better way.)

I'm tempted to look into mass-bug-filing for use of gksu, at least
among GNOME applications. If it is really necessary to run a GUI as
root, then pkexec is "a better gksu" in many ways: it clears the
environment (except for a small whitelist of "safe" variables), it
defaults to allowing members of the sudo group to escalate privileges
by typing their own password (like sudo), it can be configured to be
passwordless, and if nobody is in the sudo group, it falls back to
asking for the root password (like su does).

S

[1] https://lwn.net/Articles/551658/
"The X.Org security team would like to take this opportunity to
remind X client authors that current best practices suggest
separating code that requires privileges from the GUI"
[2] http://www.gtk.org/setuid.html


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

Bug#365564: Please fix?

[Harald Thingelstad]

This bug has changed somewhat during the last seven years. (Running Debian
Wheezy/Stable now.)

Bind9 seems to start the lwres service by default (please confirm), so
there is no need to have lwresd installed at the same time as Bind9.

So a fix for this bug could be to set Bind9 to conflict with lwresd, in
order to avoid having both packages installed at once.

Need to test it out more. Will make a note if it doesn't work, but a guess
is this bug has become so easy to fix it's forgotten (with no one bothering
to make the final fix and close it).

Just a reminder, hope it can help.

Bug#712328: strange behavior

[olivier.sallou]

I have just updated my sid system to latest and it indeed FTBS from now

Though it looks really strange. Indeed, it fails on a missing symbol:

[javac]
/tmp/buildd/biomaj-1.2.1/usr/share/biomaj/src/org/inria/biomaj/ant/task/BmajExecute.java:543:
cannot find symbol
[javac] symbol  : method
getRecursiveProperty(java.util.Hashtable,java.lang.String)

But method getRecursiveProperty is part of of class
org.inria.biomaj.exe.bank.BankFactory (part of biomaj package too).

Only "difference" is parameter match:
java.util.Hashtable,java.lang.String

vs

Hashtable ,String

But String to Object should match in Hashtable (as it used to do on
previous builds).


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

Bug#712648: dsniff: tds decoder uses uninitialized pointer, crashes

[Hilko Bengen]

Package: dsniff
Version: 2.4b1+debian-22
Severity: grave
Tags: security

The fix for #609988 was not implemented correctly:

,[ decode_tds.c ]
| int
| decode_tds(u_char *buf, int len, u_char *obuf, int olen)
| {
| struct tds_hdr *th;
| struct tds_login *tl;
| struct tds7_login *t7l, *myt7l;
| u_char *user, *pass, *serv;
| u_short userlen, passlen, servlen;
| 
| obuf[0] = '\0';
| 
| if (th->size != 8) {
|/* wrong header length */
|return (strlen(obuf));
| }
| 
| for (th = (struct tds_hdr *)buf;
|  len > sizeof(*th) && len >= ntohs(th->size);
|  buf += ntohs(th->size), len -= ntohs(th->size)) {
| 
| if (th->type == 2) {
| /* Version 4.x, 5.0 */
`

th is not initialized outside the "for" loop, so uninitialized or
unmapped memory is accessed. This leads to segmentation faults which
makes the program unusable.

This is in part my fault: I only provided a description where put the
four lines, instead of a real patch. Since I was already using a locally
patched dsniff package, I never verified if the problem has been
properly fixed.

This time, I have attached a real patch.

Cheers,
-Hilko

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

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

Versions of packages dsniff depends on:
ii  libc62.13-38
ii  libdb5.1 5.1.29-5
ii  libice6  2:1.0.8-2
ii  libnet1  1.1.4-2.1
ii  libnids1.21  1.23-2
ii  libpcap0.8   1.3.0-1
ii  libsm6   2:1.2.1-2
ii  libssl1.0.0  1.0.1e-2
ii  libx11-6 2:1.5.0-1
ii  libxmu6  2:1.1.1-1
ii  openssl  1.0.1e-2

dsniff recommends no packages.

dsniff suggests no packages.

-- no debconf information
--- decode_tds.c.orig	2013-06-18 10:35:34.0 +0200
+++ decode_tds.c	2013-06-18 10:37:41.0 +0200
@@ -140,15 +140,15 @@
 	
 	obuf[0] = '\0';
 
-if (th->size != 8) {
-   /* wrong header length */
-   return (strlen(obuf));
-}
-
 	for (th = (struct tds_hdr *)buf;
 	 len > sizeof(*th) && len >= ntohs(th->size);
 	 buf += ntohs(th->size), len -= ntohs(th->size)) {
 		
+		if (th->size != 8) {
+			/* wrong header length */
+			break;
+		}
+
 		if (th->type == 2) {
 			/* Version 4.x, 5.0 */
 			if (len < sizeof(*th) + sizeof(*tl))

Bug#712628: gnome-terminal: ctrl-shift-n doesn't keep directory

[Simon McVittie]

On 18/06/13 03:35, Bas Wijnen wrote:
> I hope the new design allows passing the new "current" directory,
> so the old behaviour can be restored.

It does, but for now you have to source a script provided by vte3 in
your ~/.bashrc or similar: see the merged bug
.


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

Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2

[Didier 'OdyX' Raboud]

Le mardi, 18 juin 2013 10.17:15, Didier 'OdyX' Raboud a écrit :
> > Is there packages in wheezy that use the libcupsimage2 symbols that are
> > now in libcupsfilters1 but do not depend on libcupsfilters1 ?

Grepping the output of 'nm -D' in a wheezy chroot showed that the following 
packages in Wheezy use symbols that move to libcupsfilters1 in unstable (cups-
filters does use most of them, not listed here):

printer-driver-c2esp: /usr/lib/cups/filter/c2esp
'cupsDitherDelete'
'cupsDitherLine'
'cupsDitherNew'
'cupsLutDelete'
'cupsLutNew'

So printer-driver-c2esp uses some symbols from libcupsfilters1, but only 
depends on libcupsimage2 in Wheezy. I does depend on libcupsfilters1 in both 
Jessie and Sid.

What do you think? Is there a way to untangle this circular depends by adding 
a breaks somewhere?

Cheers,

OdyX


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

Bug#712649: override: libgd2-xpm-dev:oldlibs/extra, libgd2-noxpm-dev:oldlibs/extra

[Laurent Bigonville]

Package: ftp.debian.org
Severity: normal

Hi,

Both libgd2-xpm-dev and libgd2-noxpm-dev are now transitional packages
that pull libgd-dev package.

Please update the override file accordingly.

Cheers

Laurent Bigonville


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

Bug#712653: [INTL:sv] Swedish strings for glide debconf

[Martin Bagge]

package: glide
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

-- 
brother
http://sis.bthstuden.se


sv.po
Description: Binary data

Bug#712651: [INTL:sv] Swedish strings for b43-fwcutter debconf

[Martin Bagge]

package: b43-fwcutter
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

-- 
brother
http://sis.bthstuden.se


sv.po
Description: Binary data

Bug#712650: [INTL:sv] Swedish strings for tt-rss debconf

[Martin Bagge]

package: tt-rss
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

-- 
brother
http://sis.bthstuden.se


sv.po
Description: Binary data

Bug#712652: [INTL:sv] Swedish strings for squid-deb-proxy debconf

[Martin Bagge]

package: squid-deb-proxy
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

-- 
brother
http://sis.bthstuden.se


sv.po
Description: Binary data

Bug#712654: New default test behaviour is backwards incompatible, and so is the backwards compatibility option

[Enrico Zini]

Package: automake
Version: 1:1.13.2-1
Severity: normal

Hello,

thanks for maintaning automake.

I'm reporting this in order to document the situation. I'm not sure if
it should be considered a bug or just an unfortunate decision from the
upstream maintainer.

The new parallel test harness, which is a default in 1.13, is backwards
incompatible and breaks the test suite in basically all my packages.

There is an option "AM_INIT_AUTOMAKE([serial-tests])" to restore the old
backwards-compatible behaviour, but the option itself is only supported
since version 1.12; 1.11 (default, for example, in Fedora 16, which is
just one year old) breaks when using it.

This has some more details, and a workaround:
http://gnu-automake.7480.n7.nabble.com/serial-tests-option-and-backwards-compatibility-td19571.html


Ciao,

Enrico

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

Kernel: Linux 3.2.0-4-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 automake depends on:
ii  autoconf   2.69-1
ii  autotools-dev  20130515.1

automake recommends no packages.

automake 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#705977: [Piuparts-devel] Bug#705977: Bug#705977: Bug#705977: ib/db: sort packages returned by reserve() by importance

[Holger Levsen]

Hi Dave,

On Dienstag, 18. Juni 2013, Dave Steele wrote:
> > can you please point me to the commits? Best in a new branch rebased on
> > current develop :)
> rdep-chain-len (2):
> e45679f piupartslib/packagesdb.py - Add rdep chain length metric calc.
> e8900a0 piupartslib/packages.db - Prioritize by rdep chain len in reserve()

merged, even though I had to rebase myself ;)


thanks & cheers,
Holger


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

Bug#712544: RFS: xalan/1.11-1 [ITA]

[Bill Blough]

On Tue, Jun 18, 2013 at 09:18:25AM +0200, Mathieu Malaterre wrote:
> Package looks pretty good. However I cannot build it a second time.
> Looks like the clean rule is missing something:

It looks like that problem is a result of the switch from using the 
shipped configure script to regenerating it from configure.in at
build-time.  I've added a rule to delete configure as part of the
clean.  That appears to resolve the problem.

Thanks for your feedback.




signature.asc
Description: Digital signature

Bug#708527: help does not work from interactive shell

[Muammar El Khatib]

Package: yacas
Followup-For: Bug #708527

Hi,

For getting help you have to enter:

??

 muammar@ihacku ⮀ ~ ⮀ yacas
 True;
 This is Yacas version '1.3.3'.
 Yacas is Free Software--Free as in Freedom--so you can redistribute Yacas or
 modify it under certain conditions. Yacas comes with ABSOLUTELY NO WARRANTY.
 See the GNU General Public License (GPL) for the full conditions.
 Type ?license or ?licence to see the GPL; type ?warranty for warranty info.
 See http://yacas.sf.net for more information and documentation on Yacas.
 Type ?? for help. Or type ?function for help on a function.

 To exit Yacas, enter  Exit(); or quit or Ctrl-c.
 Type 'restart' to restart Yacas.
 To see example commands, keep typing Example();
 In> ??
 Out> True
 In> Created new window in existing browser session.
 In>

Then, your web browser should point to:
http://yacas.sourceforge.net/refmanual.html I think it always has worked like
that. Now, I agree that the reference manual should be locally available. I have
to check that. AFAIK, yacas does not provide interactive help through
the shell, does it?

Regards,

-- 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.8-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
(ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages yacas depends on:
ii  gnuplot   4.6.3-1
ii  google-chrome-unstable [www-browser]  28.0.1500.11-r199640
ii  iceweasel [www-browser]   17.0.6esr-1
ii  libc6 2.17-3
ii  libgcc1   1:4.8.0-7
ii  libstdc++64.8.0-7
ii  lynx  2.8.8dev.15-2
ii  lynx-cur [www-browser]2.8.8dev.15-2
ii  w3m [www-browser] 0.5.3-8
ii  yacas-doc 1.3.3-2

yacas recommends no packages.

Versions of packages yacas suggests:
pn  texmacs  

-- no debconf information

--
Muammar El Khatib.
Linux user: 403107.
Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-


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

Bug#708549: ITA: python-roman -- Python module for generating/analyzing Roman numerals

[Andrea Colangelo]

retitle 708549 ITA: python-roman -- Python module for generating/analyzing 
Roman numerals
owner 708549 !
thanks


On Mon, Jun 17, 2013 at 01:20:18PM +0200, Jakub Wilk wrote:
> * Andrea Colangelo , 2013-06-15, 16:27:
> >I'm still interested in adopting this package. What's your mind
> >about that?
> 
> Please go ahead. However, I'd like the package to remain under the
> Python Modules Packaging Team umbrella.

That was my mind too, no probs about that.

Thank you,
Andrea.

-- 
Andrea Colangelo |   http://andreacolangelo.com
Ubuntu Developer |   Debian Maintainer  


signature.asc
Description: Digital signature

Bug#711924: claws-mail: segmentation fault if click on Inbox right after startup while new messages are being read in

[Ricardo Mones]

tags 711924 moreinfo
thanks

  Hi js,

On Mon, Jun 10, 2013 at 11:00:44PM -0400, js wrote:
> Package: claws-mail
> Version: 3.9.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> 
>   When one clicks on any email in the Inbox just after claws-mail starts
> up and there are new emails being read in, claws-mail gets a segmentation
> fault (stack trace below) that looks like:
> fancy_viewer.c:856:fancy_viewer_create
 
>   Can work around this by waiting several minutes after claws-mail starts
> up before selecting any mail in the Inbox.
>   Note that this problem only happens for mails in the Inbox; one can 
> select an email in Trash, Drafts, Sent, etc. immediately after startup 
> without any problem. Only emails in the Inbox cause the segmentation fault.
> 
>   Claws-mail should continue to run without crashing after selecting an 
> email in Inbox right after startup, just as it does when selecting an email
> in the other mail folders just after startup.

  That's very strange, unless all the messages in your inbox are HTML.

  Even more weird that waiting fixes the crash below, unless there's some
process in the background playing.

> 
>   Full stack trace:
> 0xb7fe8329 in dl_new_hash (s=0xd5d003f7  bounds>) at dl-lookup.c:477
> 477   dl-lookup.c: No such file or directory.
> (gdb) bt
> #0  0xb7fe8329 in dl_new_hash (s=0xd5d003f7  bounds>) at dl-lookup.c:477
> #1  _dl_lookup_symbol_x (undef_name=0xd5d003f7  bounds>, undef_map=undef_map@entry=0x89d33a0, ref=ref@entry=0xbfffd5e4, 
> symbol_scope=symbol_scope@entry=0x89d3558, version=0x0, type_class=0, 
> flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:717
> #2  0xb7fe9fd1 in elf_machine_rel (sym=0xb0ae7738, skip_ifunc=0, 
> reloc_addr_arg=0xab78e000, version=, map=0x89d33a0, 
> reloc=)
> at ../sysdeps/i386/dl-machine.h:339
> #3  elf_dynamic_do_Rel (skip_ifunc=0, lazy=, 
> nrelative=, relsize=, reladdr=, 
> map=0x89d33a0) at do-rel.h:137
> #4  _dl_relocate_object (scope=0x89d3558, reloc_mode=reloc_mode@entry=0, 
> consider_profiling=0, consider_profiling@entry=5) at dl-reloc.c:265
> #5  0xb7ff1de7 in dl_open_worker (a=a@entry=0xbfffd7ec) at dl-open.c:420
> #6  0xb7fedb2e in _dl_catch_error (objname=objname@entry=0xbfffd7e4, 
> errstring=errstring@entry=0xbfffd7e8, mallocedp=mallocedp@entry=0xbfffd7e3, 
> operate=operate@entry=0xb7ff1a00 , 
> args=args@entry=0xbfffd7ec) at dl-error.c:177
> #7  0xb7ff15d4 in _dl_open (file=0x89d2390 
> "/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=-2147483646, 
> caller_dlopen=caller_dlopen@entry=0xaed941ac 
> , nsid=-2, argc=argc@entry=2, 
> argv=argv@entry=0xb484, env=0x83f4690) at dl-open.c:656
> #8  0xb6cc4cce in dlopen_doit (a=a@entry=0xbfffd9a0) at dlopen.c:66
> #9  0xb7fedb2e in _dl_catch_error (objname=0x83fbbf4, 
> errstring=0x83fbbf8, mallocedp=0x83fbbf0, operate=0xb6cc4c30 , 
> args=0xbfffd9a0) at dl-error.c:177
> #10 0xb6cc5422 in _dlerror_run (operate=operate@entry=0xb6cc4c30 
> , args=args@entry=0xbfffd9a0) at dlerror.c:163
> #11 0xb6cc4d87 in __dlopen (file=0x89d2390 
> "/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=2) at dlopen.c:87

  Seems the error is generated by libproxy trying to open an unexisting so
file; libproxy has been multi-arch-ified recently and pacruner_mozjs.so
is in a different (architecture-dependent) location:
 
 
http://packages.debian.org/search?mode=filename&suite=sid§ion=all&arch=any&searchon=contents&keywords=pacrunner_mozjs.so

  My first suggestion is to try to upgrade libroxy package and see if this
fixes the problem.

  Are you using a pac file in your proxy settings? See also this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644373


> #12 0xaed941ac in px_module_manager_load () from /usr/lib/libproxy.so.0
> #13 0xaed94299 in px_module_manager_load_dir () from 
> /usr/lib/libproxy.so.0
> #14 0xaed95837 in px_proxy_factory_new () from /usr/lib/libproxy.so.0
> #15 0xb5151f24 in ?? () from 
> /usr/lib/i386-linux-gnu/gio/modules/libgiolibproxy.so
> #16 0xb74701b4 in g_type_create_instance () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #17 0xb7452af1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #18 0xb7454819 in g_object_newv () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #19 0xb7454db8 in g_object_new () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #20 0xb790b4ab in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
> #21 0xb790b665 in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
> #22 0xb791c881 in g_proxy_resolver_get_default () from 
> /usr/lib/i386-linux-gnu/libgio-2.0.so.0
> #23 0xb3a8826d in ?? () from /usr/lib/i386-linux-gnu/libsoup-2.4.so.1
> #24 0xb74547a2 in g_object_newv () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #25 0xb7454db8 in g_object_new () from 
> /usr/lib/i386-linu

Bug#685575: ITP: opentracker -- An open and free bittorrent tracker

[Alexander List]

Control: retitle -1 ITP: opentracker -- An open and free bittorrent tracker
Control: severity -1 wishlist
Tags: ITP

* Package name: opentracker
* Version : 0.20120528
* Upstream Author : Dirk Engling 
* URL : http://erdgeist.org/arts/software/opentracker
* License : Beer ware
* Programming Lang: C
* Description : An open and free bittorrent tracker

opentracker is a open and free bittorrent tracker project. It aims for
minimal resource usage and is intended to run at your wlan
router. Currently it is deployed as an open and free tracker
instance. Read our free and open tracker blog and announce your
torrents there (but do not hesitate to setup your own free trackers!).

Following up on the license discussion, 

a) it was established that Beer ware is DFSG-free
b) I contacted the author and asked him if he's OK with adding a LICENSE file 
declaring the software as Beer Ware.
   The answer is yes, as he made clear in the forum post mentioned above and as 
it's declared
   on the opentracker web site. We have more than 3 yes already, so licensing 
issue *resolved*.

Suggested contents of LICENSE file:

/*
 * 
 * "THE BEER-WARE LICENSE" (Revision 42):
 * Dirk Engling  wrote this file. As long as you retain
 * this notice you can do whatever you want with this stuff. If we meet some
 * day, and you think this stuff is worth it, you can buy me a beer in return
 *   Dirk Engling
 * 
 */

This passes the devscripts' licensecheck.

I would thus go ahead and start packaging opentracker if there are no 
objections, co-maintainers welcome.

I was inactive for quite a while, so I have to catch up on a lot of things like 
collab-maint etc. - please be patient with me ;)

Alex



signature.asc
Description: OpenPGP digital signature

Bug#712655: logwatch: uninitialized values in exim script with empty log file

[Teemu Ikonen]

Package: logwatch
Version: 7.4.0+svn20130529rev144-1
Severity: normal
Tags: patch

Logwatch reports contain perl error output from exim script, when ran
with an almost empty exim log file (this can happen when exim is removed
soon after installation):

 - EXIM Begin  

 Use of uninitialized value $StartQueue in numeric gt (>) at
/usr/share/logwatch
/scripts/services/exim line 312,  line 1.
 Use of uninitialized value $EndQueue in numeric gt (>) at
/usr/share/logwatch/s
cripts/services/exim line 312,  line 1.
 
 -- EXIM End - 

The attached patch fixes this.

Best,
Teemu
--- exim.orig-new	2013-06-18 12:23:04.004707191 +0200
+++ exim	2013-06-18 12:05:45.799181443 +0200
@@ -114,6 +114,8 @@
 # START
 
 my $SearchDate = TimeFilter("%Y-%m-%d %H:%M:%S");
+$StartQueue = 0;
+$EndQueue = 0;
 
 while (defined($ThisLine = )) {
chomp($ThisLine);

Bug#712656: ifenslave-2.6: Primary slave will not be set

[Christian Ruppert]

Package: ifenslave-2.6
Version: 1.1.0-20

Hi,

the current ifenslave-2.6 (1.1.0-20) in Wheezy doesn't set the primary
slave anymore. Squeeze is not affected as far as I know.
In /etc/network/if-pre-up.d/ifenslave around line 151 it does:

for slave in $IF_BOND_PRIMARY ; do
if grep -sq "\\<$slave\\>"
"/sys/class/net/$BOND_MASTER/bonding/slaves" ; then
sysfs primary "$slave"
break
fi
done

The problem here is that the grep won't get a match. This is because the
slaves file is empty at the time of the call.
On line ~206 It does "setup_master" first, so before "enslave_slaves".
So the slaves file will be filled in the "enslave_slaves" function and
thus it will always be empty in "setup_master".

It may be enough to just move the "set primary slave" block into the
"enslave_slaves" function.


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

Bug#712657: sh-syntax classifies $() as error

[martin f krafft]

Package: vim-runtime
Version: 2:7.3.547-7
Severity: normal
File: /usr/share/vim/vim73/syntax/sh.vim
Tags: patch

This $(shell construct) is almost identical to `this one`, except
the first implicitly quotes the result and may be arbitrarily
nested. Both are POSIX-compliant.

The sh syntax plugin unfortunately claims that $(such an expression)
is an error and causes the leader and closing parentheses to be
highlighted as Error.

Line 258ff. of the file explains what's going on.

Since all Debian shells including dash (the default) support $(),
I suggest to either remove the conditional in that paragraph, or to
apply the following minimal patch in the Debian package.

--- -   2013-06-18 12:54:43.124660035 +0200
+++ .vim/syntax/sh.vim  2013-06-18 12:54:15.839065086 +0200
@@ -260,7 +261,7 @@
 " (ie. Posix compliant shell).  /bin/ksh should work for those
 " systems too, however, so the following syntax will flag $(..) as
 " an Error under /bin/sh.  By consensus of vimdev'ers!
-if exists("b:is_kornshell") || exists("b:is_bash")
+if exists("b:is_kornshell") || exists("b:is_bash") || exists("b:is_sh")
  syn region shCommandSub matchgroup=shCmdSubRegion start="\$("  
skip='\|\\.' end=")"  contains=@shCommandSubList
  syn region shArithmetic matchgroup=shArithRegion  start="\$((" 
skip='\|\\.' end="))" contains=@shArithList
  syn region shArithmetic matchgroup=shArithRegion  start="\$\[" 
skip='\|\\.' end="\]" contains=@shArithList

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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim2:7.3.547-7
ii  vim-gtk [vim]  2:7.3.547-7

vim-runtime suggests no packages.

-- no debconf information


-- 
 .''`.   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#712526: freefem++: FreeFem++-mpi not working

[Giuseppe Pitton]

Dear Dimitris,
here are some thoughts on how to solve the issue (i tried to make HYPRE solver 
work).
Installing from source FreeFem++-3.23 I noticed that in the folder 
ff++/downloads/hypre nothing was built. So I compiled manually hypre-2.9.0b 
from source and I changed the paths in the file 
ff++/src/solver/makefile-sparsesolver.inc and I also commented the non HYPRE 
lines in ff++/src/solver/makefile. Please note that I had to modify several 
other lines in ff++/src/solver/makefile-sparsesolver.inc, in particular:
on line 56 after MPI_INCLUDE = there is a /I/ that should instead be a -I
on line 77 suffix should be changed to so
several paths should be adapted to the system in use (for instance lines 87, 
121, 126, 130, 135 and of course lines 185 and following)
lines 99 and 100 should be commented
then moving in directory ff++/src/solver and running make I get a 
hypre_FreeFem.so that I moved to FreeFem++ library directory 
(/usr/local/lib/ff++/3.23/lib/ on my system). Now HYPRE is running but not 
working, see this test case for instance:

$ ff-mpirun -np 2 chaleur3d-hypre.edp 
initparallele rank 0 on 2
-- FreeFem++ v  3.23 (date Jeu  6 jui 2013 20:58:44 CEST)
 Load: lg_fem lg_mesh lg_mesh3 eigenvalue parallelempi 
(large output)
  -- Square mesh : nb vertices  =441 ,  nb triangles = 800 ,  nb boundary edges 
80
  -- Square mesh : nb vertices  =441 ,  nb triangles = 800 ,  nb boundary edges 
80
  -- Build Nodes/DF on mesh :   n.v. 9261, n. elmt. 48000, n b. elmt. 4800
 nb of Nodes 68921nb of DoF   68921  DFon=1100
  -- FESpace: Nb of Nodes 68921 Nb of DoF 68921
  -- Build Nodes/DF on mesh :   n.v. 9261, n. elmt. 48000, n b. elmt. 4800
 nb of Nodes 68921nb of DoF   68921  DFon=1100
  -- FESpace: Nb of Nodes 68921 Nb of DoF 68921
###DEFAULT PARAMETERS WILL BE SET###
SOLVER: AMG-GMRES
tgv1e+10
time 0.01
tgv1e+10
time 0.01
 *** Process received signal ***
 Signal: Segmentation fault: 11 (11)
 Signal code: Address not mapped (1)
 Failing at address: 0x7f88d259d880
 *** Process received signal ***
 Signal: Segmentation fault: 11 (11)
 Signal code: Address not mapped (1)
 Failing at address: 0x7fe9f2d9d5c0
 *** End of error message ***
 *** End of error message ***
--
mpirun noticed that process rank 1 with PID 550 on node (...) exited on signal 
11 (Segmentation fault: 11).
--



Hope this helps.
Best regards.
Giuseppe


Il giorno 17/giu/2013, alle ore 12:18, Dimitrios Eftaxiopoulos ha scritto:

> Hello Giuseppe
> Thank you for raising the mpi related issues. 
> The failing to load msh3 seems to me to be a more general issue not related 
> to 
> the parallel solver in particular. 
> For the rest of the problems I do not have an immediate answer. 
> I plan to try to upload freefem++-3.23 to unstable shortly so I will have a 
> look on these issues.
> 
> Best regards
> Dimitris 
> 
> On Sunday 16 of June 2013 21:47:49 you wrote:
>> Package: freefem++
>> Version: 3.19.1-1
>> Severity: normal
>> 
>> Dear Maintainer,
>> I installed freefem++ on the default Wheezy (7.1) with apt-get, I also
>> installed freefem++-dev. I experienced the same issue on Wheezy (7.0).
>> FreeFem++ is working properly, but the parallel version FreeFem++-mpi does
>> not. I tried running the built-in examples of the examples++-mpi folder and
>> they are not working. The mentioned example files can be found at the
>> following URL: http://www.freefem.org/ff%2B%2B/ff%2B%2B/examples%2B%2B-mpi/
>> In particular, I tried running some test cases with both the following
>> commands:
>> FreeFem++-mpi chaleur3D-hips.edp
>> ff-mpirun -np 2 chaleur3D-mumps.edp
>> I obtain two kind of errors: msh3 libraries are missing or parallel solver
>> libraries are missing, for instance:
>> 
>> $ FreeFem++-mpi chaleur3D-pastix.edp
>> initparallele rank 0 on 1
>> -- FreeFem++ v  3.190001 (date Mer  9 mai 2012 21:50:21 CEST)
>> Load: lg_fem lg_mesh lg_mesh3 eigenvalue parallelempi
>>1 :  // other
>>2 : load "msh3"
>> load error : msh3
>> fail :
>> list  prefix: './' '/usr/lib/x86_64-linux-gnu/freefem++/' list  suffix : ''
>> , '.so'
>> 
>> Error line number 2, in file chaleur3D-pastix.edp, before  token msh3
>> Error load
>>  current line = 2 mpirank 0 / 1
>> Compile error : Error load
>>line number :2, msh3
>> error Compile error : Error load
>>line number :2, msh3
>> code = 1 mpirank: 0
>> FreeFem++-mpi finalize correctly .
>> 
>> $ FreeFem++-mpi chaleur3D-superludist.edp
>> initparallele rank 0 on 1
>> -- FreeFem++ v  3.190001 (date Mer  9 mai 2012 21:50:21 CEST)
>> Load: lg_fem lg_mesh lg_mesh3 eigenvalue parallelempi
>>1 :  // other
>>2 :  // NBPROC 2
>>3 : // ff-mpirun -np 4 chaleur3D-superludist.edp -glut ffglut  -n 20 -op
>> 1 -dt 0.01 -niter 10
>>4 :
>>5 : load "real_SuperLU_DIST_FreeFem"
>> load error : real_SuperLU_DIST_FreeFem

Bug#712659: mkvmlinuz missing xxd from vim-common

[Andrew Buckeridge]

Package: mkvmlinuz
Version: 36

> Depends: bash (>= 3), binutils, debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.4)

I got hit with this on my Pegasos2 when upgrading to wheezy because I
run nvi and did not have vim-common installed. There is also hexdump
or hd command from bsdmainutils.

Now have 3.2.0-4-powerpc up running.
(Bug 627585 led to 630845 also with linux-image-3.0.0 may be related.)

Test for compression magic depends on xxd command from vim-common.

> 299 if test -z "$compressed"; then
> 300 if test "`xxd -p -l2 $initrd`" = "1f8b"; then
> 301 test -z "$verbose" || echo === $initrd is already gzip 
> compressed
> 302 do_cmd cp -p $initrd $work/initrd.gz
> 303 if test "$is_xz_supported" && test "$arch" != "prep"; then
> 304   test -z "$verbose" || echo === recompressing to xz
> 305   zcat $initrd | $XZ - > $work/initrd.xz
> 306 fi
> 307 elif test "`xxd -p -l6 $initrd`" = "fd377a585a00"; then
> 308 test -z "$verbose" || echo === $initrd is already xz 
> compressed
> 309 do_cmd cp -p $initrd $work/initrd.xz
> 310 else
> 311 test -z "$verbose" || echo === assuming $initrd was not 
> compressed
> 312 compressed="No"
> 313 fi
> 314 fi
/usr/sbin/mkvmlinuz


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

Bug#712658: maven-repo-helper: POMReader doesn't trim whitespace

[Jakub Adam]

Package: maven-repo-helper
Severity: important
Tags: patch

Because of recent changes in POMReader.java, values parsed from XML keep their
leading and trailing whitespace.

Consequently, a malformed .mh/pom.properties is created for example from 
pom.xml[1],
causing a build failure.

I propose a very simple patch to fix this issue.

Regards,

Jakub

[1] 
http://anonscm.debian.org/viewvc/pkg-java/trunk/bnd/debian/pom.xml?revision=15264&view=markup
>From 784c41c79cfa7d1ca660a2a2a4237b88bb043a54 Mon Sep 17 00:00:00 2001
From: Jakub Adam 
Date: Tue, 18 Jun 2013 12:54:23 +0200
Subject: [PATCH] Trim whitespace from values in POMReader

---
 src/main/java/org/debian/maven/repo/POMReader.java |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/main/java/org/debian/maven/repo/POMReader.java b/src/main/java/org/debian/maven/repo/POMReader.java
index cc2f4ce..47b2408 100644
--- a/src/main/java/org/debian/maven/repo/POMReader.java
+++ b/src/main/java/org/debian/maven/repo/POMReader.java
@@ -103,7 +103,7 @@ public class POMReader {
 }
 
 case XMLStreamConstants.END_ELEMENT: {
-String value = buffer != null ? buffer.toString() : null;
+String value = buffer != null ? buffer.toString().trim() : null;
 if (inIgnoredElement > 0 || path.contains("exclusions")) {
 // ignore
 } else if (path.contains("dependency") || path.contains("plugin") || path.contains("extension")) {
-- 
1.7.10.4

Bug#712015: cups-filters: cups-pdf produces ugly pdfs through its pixelated font

[Brian Potkin]

On Mon 17 Jun 2013 at 17:35:19 +0800, 王晓林 wrote:

> Yeah, I just tried 300, 600, 1200, 2400dpi while setting cost factor to 66.
> Higher DPI value indeed results better PDF quality. But I still prefer cost
> factor 65, because
> 
>1. Size matters. With same dpi value, cost factor 65 results in a much
>smaller PDF file. Examples:
>   - 66-2400dpi.pdf is 15523 bytes
>   - 65-2400dpi.pdf is 8386 bytes
>2. Name matters. Processing a hello.c file into a PDF,
>   - With cost factor 65, it give me a hello.pdf
>   - With cost factor 66, it always give me a _stdin_.pdf. So I have to
>   rename it to something else before it's overwritten by next run.

This is a very sound argument and, after all, you are only reverting to
the way Squeeze deals with PostScript files sent to cups-pdf.  However,
I just wanted to tidy up a loose end or two, so thanks for confirming
that PDF quality does not depend on cost factor. And thank you for the
level of detail you have provided during discussion.

Always getting _stdin_.pdf results from a combination of a number of
things. In the first place the name originates from the method used by
Emacs to send the file to CUPS. Then CUPS simply processes the file in a
normal and, as far as I can tell, non-buggy, way. We see this in your
error_log:

   D [13/Jun/2013:10:44:42 +0800] [Job 102] argv[3]="(stdin)"

argv[3] is the job title and is used on the command lines of pstopdf,
pdftopdf and pdftops.  If TitlePref is 1 in /etc/cups/cups-pdf.conf then
argv[3].pdf becomes the output filename.

For a TitlePref of 0 (the default) the output filename is taken from
%Title in the PostScript file received from CUPS *after filtering by
pdftops*. pdftops contructs a %Title from the job title.

Cheers,

Brian.


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

Bug#712660: speech-dispatcher espeak: holds audio open for lifetime of module

[Sam Hartman]

package: speech-dispatcher
version: 0.7.1-6.2
severity: important
tags: upstream

The espeak module of speech-dispatcher leaves the audio open the entire
time the module is running.

This has amazingly bad consequences for accessibility situations
especially with gnome and gdm, although I suspect the problem is broader
than that.

With raw ALSA, this produces the following problems:

1) speech-dispatcher can no longer speak after suspend or hibernate.
This breaks orca until k speech-dispatcher is restarted

2) You use extra power and drain the battery when nothing is speaking.

If you happen to use pulseaudio then problems are worse:

3) You cannot use any ALSA only applications or any applications using
audio from another user if pulse is run as a user.

4) If pulse crashes, you never get speech back until you kill
speech-dispatcher.


Based on other bugs I suspect this applies to modules other than espeak,
although apparently not the dummy module.

I have analyzed src/modules/espeak.c and src/audio/alsa.c.  I have not
looked at src/audio/pulse.c but based on behavior looks like similar
things must be going on there.

The device is opened in module initialization and closed in module
termination.

Only the playback thread appears to interact with the audio device.

Alsa_open does some device setup, but most device setup is done in
alsa_play.

alsa_close doesn't actually appear to close the device.  The issue is
that the is_open boolean in the spd audio structure is somewhat
overloaded.  alsa_open|alsa_close assume that it is used to convey
whether alsa_close should do anything.
However, alsa_play uses it mostly to indicate whether alsa_stop should
do anything.  When alsa_play is not active, is_open is false, even when
the device is open.

I can see a few approaches.

A) Close the alsa device after each chunk.  That's almost certainly
going to introduce some artifacts and in the case of pulse probable
latency.

B)  Use sem_timedwait instead of sem_wait in the playback thread.  If
the timeout expires, call spd_audio_close; call spd_audio_open later.
Fix the bugs surrounding alsa_close and any similar bugs in the pulse
path.  This can be done fairly easily, but is module specific; you'd
need to make similar changes to any other modules with the same problem.

I'm happy to implement either approach, but want feedback from others
before doing so.

Thanks,

--Sam


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

Bug#712655: Fwd: Bug#712655: logwatch: uninitialized values in exim script with empty log file

[Willi Mann]

Hi,

attached is a patch submitted by a Debian user for the exim script.
Please consider to apply it if you find it appropriate.

thanks
WM





 Original Message 
Subject: Bug#712655: logwatch: uninitialized values in exim script with
empty log file
Resent-Date: Tue, 18 Jun 2013 10:48:01 +
Resent-From: Teemu Ikonen 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: tpiko...@gmail.com, Willi Mann 
Date: Tue, 18 Jun 2013 12:45:07 +0200
From: Teemu Ikonen 
Reply-To: Teemu Ikonen , 712...@bugs.debian.org
To: Debian Bug Tracking System 

Package: logwatch
Version: 7.4.0+svn20130529rev144-1
Severity: normal
Tags: patch

Logwatch reports contain perl error output from exim script, when ran
with an almost empty exim log file (this can happen when exim is removed
soon after installation):

 - EXIM Begin 

 Use of uninitialized value $StartQueue in numeric gt (>) at
/usr/share/logwatch
/scripts/services/exim line 312,  line 1.
 Use of uninitialized value $EndQueue in numeric gt (>) at
/usr/share/logwatch/s
cripts/services/exim line 312,  line 1.

 -- EXIM End -

The attached patch fixes this.

Best,
Teemu



--- exim.orig-new	2013-06-18 12:23:04.004707191 +0200
+++ exim	2013-06-18 12:05:45.799181443 +0200
@@ -114,6 +114,8 @@
 # START
 
 my $SearchDate = TimeFilter("%Y-%m-%d %H:%M:%S");
+$StartQueue = 0;
+$EndQueue = 0;
 
 while (defined($ThisLine = )) {
chomp($ThisLine);

Bug#712630: ITP: pyqt5 -- Python bindings for Qt5

[Dmitrijs Ledkovs]

On 18 June 2013 05:12, Scott Kitterman  wrote:
>
> This will have binaries for both python and python3 as both are
> supported.  DPMT will be the maintainer and I'll be an uploader.  Anyone
> who wants to work on putting this together, please let me know.
>

I'd be interested. I haven't looked into details, but are:
lp:~xnox/ubuntu/raring/python-qt4/qt5
lp:~mitya57/+junk/wip-pyqt5-packaging

of any use? Have you started packaging yet? I don't see anything
committed in DPMT svn.

Regards,

Dmitrijs.


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

Bug#693658: bugs.debian.org: unable to print some pdf files freshly downloaded old pdf ok

[Didier 'OdyX' Raboud]

Hi Frank,

Please provide the complementary informations asked below:

Le mercredi, 21 novembre 2012 08.02:01, Don Armstrong a écrit :
> You seem to be reporting a bug in cups, but I'm not quite sure. You'll
> have to provide quite a bit more information before anyone can help
> you, though.
> 
> 1) What pdf are you printing?
> 2) What are you using to print it?
> 3) Does it display properly?

Can you try with a recent cups too (up-to-date Wheezy would be nice)?

Thanks in advance, cheers,

OdyX
-- 
OdyX


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

Bug#711055: bisection

[Mathieu Parent]

Hi,

Faulty commit is: 1a0bc0cf [1].

Patch is attached.

[1]: 
http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/ucf.git;a=commitdiff;h=1a0bc0cf1990f7eec6c31fc3ffc3ebe9880a5367

Regards
--
Mathieu


0001-Put-the-Cwd-at-the-right-place.patch
Description: Binary data

Bug#712630: ITP: pyqt5 -- Python bindings for Qt5

[Scott Kitterman]

Dmitrijs Ledkovs  wrote:

>On 18 June 2013 05:12, Scott Kitterman  wrote:
>>
>> This will have binaries for both python and python3 as both are
>> supported.  DPMT will be the maintainer and I'll be an uploader. 
>Anyone
>> who wants to work on putting this together, please let me know.
>>
>
>I'd be interested. I haven't looked into details, but are:
>lp:~xnox/ubuntu/raring/python-qt4/qt5
>lp:~mitya57/+junk/wip-pyqt5-packaging
>
>of any use? Have you started packaging yet? I don't see anything
>committed in DPMT svn.

I'm aware of mitya57's work. No. I've not done anything additional yet.


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

Bug#705495: Tests fail to build on powerpc

[Gert Wollny]

I tried the new package, and one test fails to build on powerpc (sid, g
++ 4.6.4). The solution could be to replace the __sync_* calls by
__atomic_* calls (like in #708929)

The packages are build though, and the new version seems to fix
#705385. 

[...]
g++ -o test_atomic_compiler_builtins.exe  -g -O2 -DUSE_PTHREAD  -Wall
-Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wextra -g
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D__TBB_TEST_BUILTINS=1   -I../../src
-I../../src/rml/include -I../../include
-I. ../../src/test/test_atomic.cpp -lpthread -lrt  -Wl,-rpath-link=.
-Wl,-z,relro -Wl,--as-needed
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o:/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 more undefined references to `__sync_val_compare_and_swap_8' follow
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and_add_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_cmpswp8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_val_compare_and_swap_8'
/tmp/ccMIgORs.o: In function `__TBB_machine_fetchadd8':
/home/gerddie/tbb-4.1~20130516/build/linux_ppc_gcc_cc4.6_libc2.17_kernel3.2.0_release/../../include/tbb/machine/gcc_generic.h:83:
 undefined reference to `__sync_fetch_and

Bug#711793: rdfind: FTBFS on hurd-i386

[Paul Dreik]

2013-06-17 13:50, Samuel Thibault skrev:
> Hello,
> 
> Paul Dreik, le Mon 10 Jun 2013 20:02:53 +0200, a écrit :
>> As soon as I release the next version 1.3.3, this bug can be closed.
> 
> Do you have an ETA for this?  Not having rdfind on hurd-i386 is a
> blocker for being able to build the libc, which is kind of problematic
> :)
> 
> Otherwise, Takaki, maybe we could include the upstream patch already
> without waiting for the upstream release?
> 
> Samuel
> 

I have something better than an ETA, namely a release :-)

Here is the link: http://rdfind.pauldreik.se/rdfind-1.3.3.tar.gz

Please let me hear if there are any problems.
Paul


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

Bug#653111: postgresql-9.1-postgis: postgis dependencies are very strong

[Jonas Smedegaard]

Package: postgis
Version: 1.5.3-2
Followup-For: Bug #653111

I agree with the original poster of this bugreport.

Package postgresql-9.1-postgis is an extension to postgresql-9.1 i.e. a
plugin package for servers.

Package postgis contains runtime tools both for server and client use.

What I suggest (in line with original poster but more detailed) is to
move tool shp2pgsql-gui to new package postgis-x11, and have package
postgis recommend package shp2pgsql-gui.

This bugreport has seen no responses at all.  Would anyone mind me do an
NMU to fix this as proposed above?


 - Jonas


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

Bug#690605: ibus-foo does not install ibus

[Osamu Aoki]

Control: severity 690605 wishlist
Control: summary 690605 0

Hi,

== BUG ==

Installation of ibus does not install any ibus-foo as default.

The dependency chain is 
 * ibus-xkbc depends on ibus
 * ibus does not depends/recommends any ibus-foo (like ibus-xkbc).

So people installing ibus are left without hint for how to enable
ibus-module.

== ASSESSMENT ==

Since cyclic dependency is deprecated, we can not add
depends/recommends on ibus-foo pointing to ibus.

== SOLUTION ==

I can think of followings:

 * add suggests to ibus-foo packages.
 * add GUI UI preference panel "Help" with
   /usr/share/doc/ibus/README.Debian" contents.

Since these are feature request, severity wishlist is appropriate.

== NOTE ==

There is new https://github.com/sun-im/ibus-xkbc for ibus 1.5

Osamu


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

Bug#693432: psgml: Doesn't work with emacs24

[Roland Mas]

Roland Mas, 2012-12-12 11:41:03 +0100 :

> Neil Roeth, 2012-11-18 14:02:22 -0500 :
>
>> Thanks for the report.  I will take a look and fix in the next version.
>
> Thank you.  If it helps, I noticed that FreeBSD seems to ship a package
> called psgml-emacs24-1.3.2_18, so maybe the patches at
> http://svnweb.freebsd.org/ports/head/editors/psgml/files/ could be a
> useful starting point.

I found http://www.emacswiki.org/emacs/PsgmlMode, which says:

,
| The last official version on sourceforge mentioned here (1.3.2) does not
| work with Emacs 24 any longer because of some quirks with backquotes and
| other minor syntactical changes. These problems have been fixed, and the
| fixed version (called 1.4.0) is available at
| http://www.fsavigny.de/gpled-software/psgml-1.4.0.tar.gz. (Except for
| these fixes, there are absolutely no differences to version 1.3.2.)
`

  May I humbly request that the psgml package in Sid be updated to use
that version?  I'd like to keep only one version of Emacs installed if
possible, but I still use much PSGML so I'm currently forced to keep
Emacs 23.

  Thanks,

Roland.
-- 
Roland Mas

If you spit in the air, it lands in your face.
  -- Tevye, in Fiddler on the roof


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

Bug#677785: O: zorroutils -- Zorro bus utilities for Amigas running 2.1 and later kernels

[John Paul Adrian Glaubitz]

retitle 677785 'ITA: zorroutils - Zorro bus utilities for Amigas running 2.1 
and later kernels'
owner 677785
thanks

Hi,

I am one of the guys who are working to revive the m68k port of
Debian. As a long time Amiga user, I am naturally primarily interested
in getting Debian to run on Amigas and I am therefore taking care of
all Amiga-related packages that have been orphanend.

Thus, I am adopting zorroutils.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#712661: xen-utils-common: xl start HVM domU instead of PV if disk placed on file

[Ivan]

Package: xen-utils-common
Version: 4.1.4-3+deb7u1
Severity: normal

Dear Maintainer,
i changed toolkit to xl, after that i observe that my domU started as HVM 
domains.
I found same problem here: 
http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html
When i manualy setup loop devices and specify it as disks in my VM conf file, 
domU started as PV.

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

Kernel: Linux 3.2.0-4-amd64 (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 xen-utils-common depends on:
ii  gawk1:4.0.1+dfsg-2.1
ii  lsb-base4.1+Debian8+deb7u1
ii  python  2.7.3-4
ii  ucf 3.0025+nmu3
ii  udev175-7.2
ii  xenstore-utils  4.1.4-3+deb7u1

xen-utils-common recommends no packages.

xen-utils-common suggests no packages.

-- Configuration Files:
/etc/default/xendomains changed:
XENDOMAINS_SAVE=
XENDOMAINS_RESTORE=false
XENDOMAINS_AUTO=/etc/xen/auto
XENDOMAINS_STOP_MAXWAIT=300

/etc/xen/xend-config.sxp changed:
(#xend-unix-server yes)
(vif-script vif-bridge)
(dom0-min-mem 196)
(enable-dom0-ballooning yes)
(total_available_memory 0) 
(dom0-cpus 0)
(vncpasswd '')

/etc/xen/xl.conf changed:
autoballoon=1
lockfile="/var/lock/xl"
vifscript="vif-bridge"


-- 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#712662: conntrackd: cannot restart daemon after first start

[Bauer, Stefan (IZLBW Extern)]

Package: conntrackd
Version: 1:0.9.14-2

After package installation by running apt-get install conntrackd, the daemon is 
started (as the output of ps aux indicates).
Now a /etc/init.d/contrackd restart is denied with the error message - 
Permission denied.

After a kill 'pid of conntrackd' and a /etc/init.d/conntrack start, the daemon 
can be restarted without problems.

Regards

Stefan

Bug#708847: forcibly merging 690605 708847

[Osamu Aoki]

forcemerge 690605 708847
summary 708847 0
thanks

Original request:
 provide default input methods if one is not specified

I hope you aree with my suggested solution at:
  http://bugs.debian.org/690605


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

Bug#712359: itext5 switch defaultfontmapper to com.itextpdf.awt

[Olivier Sallou]

DefaultFontMpapper moved to a new package.

Need to patch source to match this new name and depend on latest
libitext5-java

-- 


gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


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

Bug#712661: [Pkg-xen-devel] Bug#712661: xen-utils-common: xl start HVM domU instead of PV if disk placed on file

[Ian Campbell]

On Tue, 2013-06-18 at 16:19 +0400, Ivan wrote:
> Package: xen-utils-common
> Version: 4.1.4-3+deb7u1
> Severity: normal
> 
> Dear Maintainer,
> i changed toolkit to xl, after that i observe that my domU started as HVM 
> domains.
> I found same problem here: 
> http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html
> When i manualy setup loop devices and specify it as disks in my VM conf file, 
> domU started as PV.

How have you determined that the guest is an HVM domain?

Note that the presence of a qemu process does not necessarily correspond
to HVM, since qemu can also under some circumstances be used to provide
a PV disk backend.

And just to clarify: Neither your dom0 not your domU are BSD? Both are
Debian Linux?

Ian.


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

Bug#712663: gdb with pid argument doesn't work

[Vincent Lefevre]

Package: gdb
Version: 7.6-3
Severity: normal

According to the gdb(1) man page:

  You can, instead, specify a process ID as a second argument, if you
  want to debug a running process:

  gdb program 1234

  would attach GDB to process 1234 (unless you also have a file named
  `1234'; GDB does check for a core file first).

but this doesn't work:

ypig:~> gdb =iceweasel 29743
GNU gdb (GDB) 7.6-debian
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 /usr/lib/iceweasel/iceweasel...Reading symbols from 
/usr/lib/debug/usr/lib/iceweasel/iceweasel...done.
done.
Attaching to program: /usr/lib/iceweasel/iceweasel, process 29743
ptrace: Operation not permitted.
/home/vlefevre/29743: No such file or directory.
(gdb) 

I wonder what gdb is trying to do, but the error messages are no clear.
Does it fail because /home/vlefevre/29743 doesn't exist???

I don't know about ptrace, but I'm using a standard Debian kernel
(linux-image-3.9-1-amd64 Debian package).

FYI:

ypig:~> ll /proc/29743
total 0
dr-xr-xr-x  2 vlefevre vlefevre 0 2013-06-18 14:16:22 attr/
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 autogroup
-r  1 vlefevre vlefevre 0 2013-06-18 14:16:22 auxv
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:13:14 cgroup
--w---  1 vlefevre vlefevre 0 2013-06-18 14:16:22 clear_refs
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:12:02 cmdline
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 comm
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 coredump_filter
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 cpuset
lrwxrwxrwx  1 vlefevre vlefevre 0 2013-06-18 14:16:22 cwd -> /home/vlefevre/
-r  1 vlefevre vlefevre 0 2013-06-18 14:16:22 environ
lrwxrwxrwx  1 vlefevre vlefevre 0 2013-06-18 14:16:22 exe -> 
/usr/lib/iceweasel/iceweasel*
dr-x--  2 vlefevre vlefevre 0 2013-06-18 14:12:18 fd/
dr-x--  2 vlefevre vlefevre 0 2013-06-18 14:16:22 fdinfo/
-r  1 vlefevre vlefevre 0 2013-06-18 14:13:14 io
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 limits
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 loginuid
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:12:02 maps
-rw---  1 vlefevre vlefevre 0 2013-06-18 14:16:22 mem
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:12:02 mountinfo
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 mounts
-r  1 vlefevre vlefevre 0 2013-06-18 14:16:22 mountstats
dr-xr-xr-x  6 vlefevre vlefevre 0 2013-06-18 14:16:22 net/
dr-x--x--x  2 vlefevre vlefevre 0 2013-06-18 14:16:22 ns/
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 numa_maps
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 oom_adj
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 oom_score
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 oom_score_adj
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 pagemap
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 personality
lrwxrwxrwx  1 vlefevre vlefevre 0 2013-06-18 14:16:22 root -> //
-rw-r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 sched
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 sessionid
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 smaps
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 stack
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:12:06 stat
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:13:14 statm
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:12:18 status
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 syscall
dr-xr-xr-x 39 vlefevre vlefevre 0 2013-06-18 14:12:06 task/
-r--r--r--  1 vlefevre vlefevre 0 2013-06-18 14:16:22 wchan

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

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

Versions of packages gdb depends on:
ii  gdbserver 7.6-3
ii  libc6 2.17-5
ii  libexpat1 2.1.0-3
ii  liblzma5  5.1.1alpha+20120614-2
ii  libncurses5   5.9+20130608-1
ii  libpython2.7  2.7.5-6
ii  libreadline6  6.2+dfsg-0.1
ii  libtinfo5 5.9+20130608-1
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.17-5

Versions of packages gdb suggests:
ii  gdb-doc  7.6-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#702180: hyperestraier: Still FTBFS on powerpcspe due to incorrectly applied change

[Roland Stigge]

Hi,

thanks for adding powerpcspe to the list of supported architectures of
hyperestraier. Unfortunately, it still FTBFS:

...
Exception `LoadError' at /usr/lib/ruby/1.9.1/rubygems.rb:1273 - cannot
load such file -- rubygems/defaults/ruby
rm -rf casket
make[1]: Leaving directory `/«PKGBUILDDIR»/rubynative19'
perl -p -i -e 's@^#! /usr/bin/ruby1\.8 -w@#! /usr/bin/ruby1.9.1 -w@'
rubynative19/estcmd.rb
cd javapure && /usr/bin/make
make[1]: Entering directory `/«PKGBUILDDIR»/javapure'
/usr/java/bin/javac -source 1.5 -target 1.5 -d . Document.java
Condition.java ResultDocument.java NodeResult.java Node.java
Utility.java Call.java
/bin/bash: /usr/java/bin/javac: No such file or directory
make[1]: *** [estraierpure.jar] Error 127
make[1]: Leaving directory `/«PKGBUILDDIR»/javapure'
make: *** [build-arch-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
...

This is also caused by a temporary openjdk-7 FTBFS issue (openjdk-7 buil
before on powerpcspe), which I'm working on separately.

However, the patch that I proposed in #702180 wasn't applied correctly.
Only some hunks were applied. Others not, and in one case, "powerpc" was
accidentally _changed_ to "powerpcspe" which is actually an issue on
powerpc now.

I'm attaching a new incremental patch for hyperestraier 1.4.13-10 which
fixes this.

Further, I don't think that the powerpcspe exception you put into
JAVA_UNSUPPORTED_CPUS (debian/rules) is necessary, because java is
supposed to work fine on powerpcspe (consider the issue I described
above as only temporary).

Thanks in advance,

Roland
--- hyperestraier-1.4.13/debian/control.orig	2013-06-18 08:35:05.801949554 +0200
+++ hyperestraier-1.4.13/debian/control	2013-06-18 08:36:46.097945353 +0200
@@ -2,7 +2,7 @@
 Section: text
 Priority: optional
 Maintainer: KURASHIKI Satoru 
-Build-Depends: debhelper (>= 9), autotools-dev, pkg-config, zlib1g-dev, libqdbm-dev (>= 1.8.75), libfcgi-dev (>= 2.4.0-6), ruby1.8, ruby1.8-dev, ruby1.9.1, ruby1.9.1-dev, openjdk-7-jdk [amd64 armel armhf i386 ia64 powerpc s390 sparc], chrpath, perl
+Build-Depends: debhelper (>= 9), autotools-dev, pkg-config, zlib1g-dev, libqdbm-dev (>= 1.8.75), libfcgi-dev (>= 2.4.0-6), ruby1.8, ruby1.8-dev, ruby1.9.1, ruby1.9.1-dev, openjdk-7-jdk [amd64 armel armhf i386 ia64 powerpc powerpcspe s390 sparc], chrpath, perl
 Standards-Version: 3.9.4
 Homepage: http://fallabs.com/hyperestraier/
 Vcs-Git: git://anonscm.debian.org/collab-maint/hyperestraier.git
@@ -47,7 +47,7 @@
  library.
 
 Package: ruby-hyperestraier
-Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpcspe s390 sparc hurd-i386
+Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 sparc hurd-i386
 Section: ruby
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: ruby-hyperestraier-doc
@@ -77,7 +77,7 @@
  generated rdoc.
 
 Package: libestraier-ruby
-Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc hurd-i386
+Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 sparc hurd-i386
 Section: oldlibs
 Priority: extra
 Depends: ${misc:Depends}, ruby-hyperestraier
@@ -86,7 +86,7 @@
  This is a dummy package to ease transition to new package name.
 
 Package: libestraier-ruby1.8
-Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc hurd-i386
+Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 sparc hurd-i386
 Section: oldlibs
 Priority: extra
 Depends: ${shlibs:Depends}, ruby-hyperestraier, ${misc:Depends}
@@ -95,7 +95,7 @@
  This is a dummy package to ease transition to new package name.
 
 Package: libestraier-ruby1.9.1
-Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc hurd-i386
+Architecture: i386 amd64 armel armhf ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 sparc hurd-i386
 Section: oldlibs
 Priority: extra
 Depends: ${shlibs:Depends}, ruby-hyperestraier, ${misc:Depends}
@@ -113,7 +113,7 @@
  This is a dummy package to ease transition to new package name.
 
 Package: libestraier-java
-Architecture: linux-amd64 armel linux-i386 ia64 mips mipsel powerpc s390 sparc alpha armhf ppc64
+Architecture: linux-amd64 armel linux-i386 ia64 mips mipsel powerpc powerpcspe s390 sparc alpha armhf ppc64
 Section: java
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: hyperestraier, java-virtual-machine

Bug#712661: [Pkg-xen-devel] Bug#712661: xen-utils-common: xl start HVM domU instead of PV if disk placed on file

[Bastian Blank]

On Tue, Jun 18, 2013 at 04:19:09PM +0400, Ivan wrote:
> i changed toolkit to xl, after that i observe that my domU started as HVM 
> domains.

Please explain what you mean with "started as HVM". The existance of a
qemu-dm process does not necesarily mean HVM, but it can be used to
support stuff the kernel does not.

> I found same problem here: 
> http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html

This is about NetBSD and not about HVM.

Bastian

-- 
Knowledge, sir, should be free to all!
-- Harry Mudd, "I, Mudd", stardate 4513.3


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

Bug#712664: kfreebsd-9: CVE-2013-2171: Privilege escalation via mmap

[Steven Chamberlain]

Source: kfreebsd-9
Version: 9.0-11
Severity: grave
Tags: security upstream
Control: found -1 kfreebsd-9/9.0~svn223109-0.1

Privilege escalation via mmap:
http://security.freebsd.org/advisories/FreeBSD-SA-13:06.mmap.asc

This was introduced by r199819 when FreeBSD 9 was the SVN head.  As such
it affects 9.0 as well as 10.0 snapshots before today; I'm preparing a
backport from 9-STABLE.

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

Kernel: kFreeBSD 9.0-2-amd64
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 kfreebsd-image-9.0-2-amd64 depends on:
ii  devd   9.0+ds1-9
ii  freebsd-utils  9.0+ds1-9
ii  kbdcontrol 9.0+ds1-9
ii  kldutils   9.0+ds1-9

kfreebsd-image-9.0-2-amd64 recommends no packages.

kfreebsd-image-9.0-2-amd64 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#712665: bumblebee: Easier backport to oldstable

[Mathieu Malaterre]

Package: bumblebee
Version: 3.2.1-2
Severity: wishlist

it would be nice if the d/rules would also contains legacy path for oldstable:

$ cat debian/rules

CONF_PRIMUS_LD_PATH=/usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus

CONF_LDPATH_NVIDIA seems to handle the non-multi-arched path, so this would 
make the d/rules consistant.

Thanks


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

Bug#712666: primus: fatal: failed to load PRIMUS_LOAD_GLOBAL

[Mathieu Malaterre]

Package: primus
Version: 0~20130601-1
Severity: normal

For some reason I cannot get primus to work on my oldstable system:

$ optirun --debug glxinfo
[ 3844.581458] [DEBUG]optirun version 3.2.1 starting...
[ 3844.581547] [DEBUG]Active configuration:
[ 3844.581575] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[ 3844.581629] [DEBUG] X display: :8
[ 3844.581654] [DEBUG] LD_LIBRARY_PATH: 
/usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia
[ 3844.581698] [DEBUG] Socket path: /var/run/bumblebee.socket
[ 3844.581724] [DEBUG] Accel/display bridge: auto
[ 3844.581763] [DEBUG] VGL Compression: proxy
[ 3844.581788] [DEBUG] VGLrun extra options: 
[ 3844.581814] [DEBUG] Primus LD Path: 
/usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus
[ 3844.581924] [DEBUG]Using auto-detected bridge primus
[ 3846.758561] [INFO]Response: Yes. X is active.

[ 3846.758614] [INFO]Running application using primus.
[ 3846.758787] [DEBUG]Process glxinfo started, PID 13828.
primus: fatal: failed to load PRIMUS_LOAD_GLOBAL
[ 3846.783385] [DEBUG]SIGCHILD received, but wait failed with No child processes
[ 3846.783446] [DEBUG]Socket closed.
[ 3846.783481] [DEBUG]Killing all remaining processes.


Thanks for comments


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

Bug#664482: #664482 more fixes

[Christoph Martin]

Hi Oliver,

there are some more occurences of this bug which lead to cron warnings
and device.html not anymore working. Here are patches:

> --- /usr/share/perl5/netdisco.pm~   2012-09-24 11:16:52.0 +0200
> +++ /usr/share/perl5/netdisco.pm2013-06-18 14:26:08.345011648 +0200
> @@ -334,7 +334,7 @@
>  my @hash_refs_mult = qw/v3_user/;
>  
>  # Add custom types from caller outside netdisco
> -foreach my $type qw(booleans array_refs hash_refs array_refs_mult 
> hash_refs_mult) {
> +foreach my $type (qw(booleans array_refs hash_refs array_refs_mult 
> hash_refs_mult)) {
>  eval "push(\@$type, \@{\$args{config}{\$type}});";
>  }
>  
> --- /usr/share/netdisco/html/device.html~   2009-09-08 23:19:51.0 
> +0200
> +++ /usr/share/netdisco/html/device.html2013-06-18 14:26:21.737066601 
> +0200
> @@ -567,7 +567,7 @@
>  %  if ($mod->{port}) {
>  (<% $mod->{port} %>)
>  %  }
> -%  for my $f qw(fw hw sw) {
> +%  for my $f (qw(fw hw sw)) {
>  %if ($mod->{"${f}_ver"}) {
>  [<%$f%>: <%$mod->{"${f}_ver"}%>]
>  %}

Christoph
-- 

Christoph Martin, Zentrum für Datenverarbeitung, Uni-Mainz, Germany
 Anselm Franz von Bentzel-Weg 12, 55128 Mainz
 Telefon: +49(6131)3926337
 Instant-Messaging: Jabber: mar...@uni-mainz.de
  (Siehe http://www.zdv.uni-mainz.de/4010.php)
<>

signature.asc
Description: OpenPGP digital signature

Bug#712667: phpunit: Known bug of not expect generic exception for 3.6 series

[Nicolas Blanc]

Package: phpunit
Version: 3.6.10-1
Severity: important
Tags: patch

Dear maintainer,

In fact i do not have a patch... But a recommendation from S. Bergmann himself:
https://github.com/sebastianbergmann/phpunit/issues/579

It's needed to switch to 3.7 . But i don't know if it's a good way of doing for 
the stable part of the package...

Have a good day, dear maintainer,

-- 
Nicolas Blanc.  


-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages phpunit depends on:
ii  pear-phpunit-channel  1.1-1
ii  php-codecoverage  1.1.2+dfsg1-3
ii  php-file-iterator 1.3.1-2
ii  php-pear  5.4.4-14
ii  php-symfony-yaml  1.0.6-1
ii  php-text-template 1.1.1-2
ii  php-timer 1.0.2-2
ii  php5-cli  5.4.4-14
ii  phpunit-mock-object   1.1.1-2

Versions of packages phpunit recommends:
ii  php-invoker   1.1.0-1
ii  php-token-stream  1.1.3-2
ii  phpunit-story 1.0.0-3

Versions of packages phpunit suggests:
pn  phpunit-dbunit
pn  phpunit-selenium  

-- 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#693432: psgml: Doesn't work with emacs24

[Roland Mas]

Roland Mas, 2013-06-18 14:15:33 +0200 :

[...]

>   May I humbly request that the psgml package in Sid be updated to use
> that version?  I'd like to keep only one version of Emacs installed if
> possible, but I still use much PSGML so I'm currently forced to keep
> Emacs 23.

  For the record: I built a local package based on that 1.4.0 version
(with a simple uupdate and change in debian/emacsen.*), and it seems to
be working fine based on some quick testing.

Roland.
-- 
Roland Mas

La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire
  -- Signatures à collectionner, série n°2, partie 1/3.


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

Bug#712666: primus: fatal: failed to load PRIMUS_LOAD_GLOBAL

[Mathieu Malaterre]

If I try [*]. It looks just as if libglapi.so.0 is missing from my
system. For some reason this is never triggered during the Depends:
checks. I guess primus will be hard to get working on oldstable...

[*]
$ LD_DEBUG=libs primusrun glxgears
 13969: find library=libncurses.so.5 [0]; searching
 13969: search cache=/etc/ld.so.cache
 13969:  trying file=/lib/libncurses.so.5
 13969:
 13969: find library=libdl.so.2 [0]; searching
 13969: search cache=/etc/ld.so.cache
 13969:  trying file=/lib/libdl.so.2
 13969:
 13969: find library=libc.so.6 [0]; searching
 13969: search cache=/etc/ld.so.cache
 13969:  trying file=/lib/libc.so.6
 13969:
 13969:
 13969: calling init: /lib/libc.so.6
 13969:
 13969:
 13969: calling init: /lib/libdl.so.2
 13969:
 13969:
 13969: calling init: /lib/libncurses.so.5
 13969:
 13969:
 13969: initialize program: /bin/bash
 13969:
 13969:
 13969: transferring control: /bin/bash
 13969:
 13971:
 13971: calling fini: /bin/bash [0]
 13971:
 13971:
 13971: calling fini: /lib/libncurses.so.5 [0]
 13971:
 13971:
 13971: calling fini: /lib/libdl.so.2 [0]
 13971:
 13971:
 13971: calling fini: /lib/libc.so.6 [0]
 13971:
 13972: find library=libwrap.so.0 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libwrap.so.0
 13973: find library=libselinux.so.1 [0]; searching
 13973: search cache=/etc/ld.so.cache
 13973:  trying file=/lib/libselinux.so.1
 13972: find library=libutil.so.1 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13973:
 13972:  trying file=/lib/libutil.so.1
 13972:
 13972: find library=libreadline.so.5 [0]; sea 13 13972:
search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libreadline.so.5
 13972:
 13973: find library=libdl.so.2 [0]; searching
 13973: search cache=/etc/ld.so.cache
 13972: find library=libssl.so.0.9.8 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/usr/lib/libssl.so.0.9.8
 13972:
 13972: find library=libc.so.6 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libc.so.6
 13972:
 13972: find library=libcrypto.so.0.9.8 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/usr/lib/libcrypto.so.0.9.8
 13972:
 13972: find library=libnsl.so.1 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libnsl.so.1
 13973:
 13973: calling init: /lib/libdl.so.2
 13973:
 13973:
 13973: calling init: /lib/libselinux.so.1
 13973:
 13972: find library=libncurses.so.5 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libncurses.so.5
 13972:
 13972: find library=libdl.so.2 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/lib/libdl.so.2
 13972:
 13972: find library=libz.so.1 [0]; searching
 13972: search cache=/etc/ld.so.cache
 13972:  trying file=/usr/lib/libz.so.1
 13972:
 13973:
 13973: initialize program: sed
 13973:
 13973:
 13973: transferring control: sed
 13973:
 13972:
 13972: calling init: /lib/libc.so.6
 13972:
 13972:
 13972: calling init: /usr/lib/libz.so.1
 13972:
 13972:
 13972: calling init: /lib/libdl.so.2
 13972:
 13972:
 13972: calling init: /lib/libncurses.so.5
 13972:
 13972:
 13972: calling init: /lib/libnsl.so.1
 13972:
 13972:
 13972: calling init: /usr/lib/libcrypto.so.0.9.8
 13972:
 13972:
 13972: calling init: /usr/lib/libssl.so.0.9.8
 13972:
 13972:
 13972: calling init: /lib/libreadline.so.5
 13972:
 13972:
 13972: calling init: /lib/libutil.so.1
 13972:
 13972:
 13972: calling init: /lib/libwrap.so.0
 13972:
 13972:
 13972: initialize program: socat
 13972:
 13972:
 13972: transferring control: socat
 13972:
 13972:
 13972: calling fini: socat [0]
 13972:
 13972:
 13972: calling fini: /lib/libwrap.so.0 [0]
 13972:
 13972:
 13972: calling fini: /lib/libutil.so.1 [0]
 13972:
 13972:
 13972: calling fini: /lib/libreadline.so.5 [0]
 13972:
 13972:
 13972: calling fini: /usr/lib/libssl.so.0.9.8 [0]
 13972:
 13972:
 13972: calling fini: /usr/lib/libcrypto.so.0.9.8 [0]
 13972:
 13972:
 13972: calling fini: /lib/libnsl.so.1 [0]
 13972:
 13972:
 13972: calling fini: /lib/libncurses.so.5 [0]
 13972:
 13972:
 13972: calling fini: /lib/libdl.so.2 [0]
 13972:
 13972:
 13972: calling fini: /usr/lib/libz.so.1 [0]
 13972:
 13972:
 13972: calling fini: /lib/libc.so.6 [0]
 13972:
 13970:
 13970: calling fini: /bin/bash [0]
 13970:

Bug#712669: New API version does not work with old one

[Anton Gladky]

Package: python-sip
Version: 4.14.7-1
Severity: grave

Dear maintainer,

the new python-sip version is not compatible at least with
python-qt4_4.10.1-1.

python -c "from PyQt4.QtCore import QThread"
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: the sip module implements API v10.0 but the PyQt4.QtCore
module requires API v9.2

Thanks,

Anton


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

Kernel: Linux 3.8-2-amd64 (SMP w/6 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-sip depends on:
ii  libc6   2.17-5
ii  libgcc1 1:4.8.1-3
ii  libstdc++6  4.8.1-3
ii  python  2.7.5-2

python-sip recommends no packages.

python-sip 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#712668: initramfs-tools broken with latest move to jessie

[Brent S. Elmer]

Package: initramfs-tools
Version: 0.112
Severity: normal

When I upgraded my jessie box on Monday, I started getting this error in
Synaptic:

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.2.21.120712
cp: cannot stat `/usr/lib/i386-linux-gnu/pango/1.6.0/module-
files.d/libpango1.0-0.modules': No such file or directory
E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1.
update-initramfs: failed for /boot/initrd.img-3.2.21.120712 with 1.
dpkg: error processing initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initramfs-tools

Not all changes and updates succeeded. For further details of the failure,
please expand the 'Details' panel below.


I noticed that a new version of initramfs-tools hit testing the day before the
problem started.  When I try and do a reinstall of initramfs-tools in synaptic,
I get the following error:

E: Internal Error, No file name for initramfs-tools:i386

Something appears to be badly broken.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 7.8M Oct 27  2009 /boot/initrd.img-2.6.30.091027-2.bak
-rw-r--r-- 1 root root 7.6M Jan 15  2010 /boot/initrd.img-2.6.32.091211.bak
-rw-r--r-- 1 root root  15M Jul  6  2012 /boot/initrd.img-3.2.12.120410
-rw-r--r-- 1 root root  15M May 16 08:20 /boot/initrd.img-3.2.21.120712
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.2.21.120712 
root=UUID=0cde8d44-059e-46e1-8e81-1ef15c700b67 ro quiet splash

-- resume
RESUME=UUID=a7c983cf-2752-48fc-a5b7-1a7c83b70074
-- /proc/filesystems
ext4
fuseblk

-- lsmod
Module  Size  Used by
xt_limit1311  8 
xt_tcpudp   1835  29 
ipt_LOG 6390  8 
ipt_MASQUERADE  1158  0 
xt_DSCP 1567  0 
ipt_REJECT  1885  1 
nf_conntrack_irc2599  0 
nf_conntrack_ftp4685  0 
xt_state 891  10 
iptable_nat 3124  0 
nf_nat 11856  2 iptable_nat,ipt_MASQUERADE
nf_conntrack_ipv4   9364  13 nf_nat,iptable_nat
nf_defrag_ipv4   847  1 nf_conntrack_ipv4
nf_conntrack   46218  7 
nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,nf_conntrack_ftp,nf_conntrack_irc,ipt_MASQUERADE
iptable_mangle  1116  0 
openafs   637080  2 
iptable_filter  1020  1 
ip_tables   9474  3 iptable_filter,iptable_mangle,iptable_nat
ebtable_nat 1240  0 
ebtables   14553  1 ebtable_nat
x_tables   10989  12 
ebtables,ip_tables,iptable_filter,iptable_mangle,iptable_nat,xt_state,ipt_REJECT,xt_DSCP,ipt_MASQUERADE,ipt_LOG,xt_tcpudp,xt_limit
cpufreq_powersave634  0 
cpufreq_userspace   1472  0 
cpufreq_stats   2313  0 
cpufreq_conservative 4277  0 
ppdev   4678  0 
lp  6474  0 
tun11524  0 
binfmt_misc 5777  1 
hdaps   7583  1 
thinkpad_ec 4139  1 hdaps
uinput  5816  1 
nfsd  206040  2 
exportfs2965  1 nfsd
nfs   259951  0 
nfs_acl 1891  2 nfs,nfsd
auth_rpcgss29493  2 nfs,nfsd
fscache27432  1 nfs
lockd  59654  2 nfs,nfsd
sunrpc160325  6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd
loop   14459  0 
firewire_sbp2  10781  0 
fuse   57469  1 
kvm_intel 113525  0 
kvm   207346  1 kvm_intel
snd_hda_codec_conexant39005  1 
joydev  7439  0 
snd_hda_intel  19952  2 
snd_hda_codec  67431  2 snd_hda_intel,snd_hda_codec_conexant
snd_hwdep   4674  1 snd_hda_codec
snd_pcm_oss33062  0 
snd_mixer_oss  12409  1 snd_pcm_oss
thinkpad_acpi  53282  0 
nvram   4466  1 thinkpad_acpi
snd_pcm58763  3 snd_pcm_oss,snd_hda_codec,snd_hda_intel
snd_page_alloc  5605  2 snd_pcm,snd_hda_intel
snd_seq_midi4072  0 
snd_seq_midi_event  4376  1 snd_seq_midi
snd_rawmidi14534  1 snd_seq_midi
btusb  10044  2 
arc41078  2 
snd_seq40704  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device  4052  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer  14446  2 snd_seq,snd_pcm
snd41769  16 
snd_timer,snd_seq_device,snd_seq,snd_rawmidi,snd_pcm,thinkpad_acpi,snd_mixer_oss,snd_pcm_oss,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_conexant
pcmcia 30830  0 
uvcvideo   55505  0 
iwlwifi   173244  0 
mac80211  199276  1 iwlwifi
cfg80211  143846  2 mac80211,iwlwifi
soundcore   4442  1 snd
parport_pc 16638  1 
videodev   68729  1 uvcvideo
iTCO_wdt9

Bug#712663: gdb with pid argument doesn't work

[Vincent Lefevre]

On 2013-06-18 14:25:59 +0200, Vincent Lefevre wrote:
> I don't know about ptrace, but I'm using a standard Debian kernel
> (linux-image-3.9-1-amd64 Debian package).

For the ptrace problem, it could be related to that:

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection

and indeed:

ypig:~> cat /proc/sys/kernel/yama/ptrace_scope
1

Setting it to 0 is obviously not the right thing to do. The solution
must be implemented in gdb (e.g. by being suid root and dropping
permissions when possible... or something else...).

Running iceweasel from gdb may be a workaround, but this may be too
late (e.g. to get a backtrace of some frozen process).

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


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

Bug#712666: Info received (Bug#712666: primus: fatal: failed to load PRIMUS_LOAD_GLOBAL)

[Mathieu Malaterre]

I would say that d/control is incomplete, it should read:

Package: primus-libs
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}, libglapi-mesa

Here is what i see:

$ strings /usr/lib/primus/libGL.so.1 | grep glapi
libglapi.so.0


Comments ?


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

Bug#712670: x2goclient: taskbar disappear

[Denis Gottardello]

Package: x2goclient
Version: 4.0.1.0-0~x2go1+wheezy~main~380~build1
Severity: normal

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



I use kde as my preferred desktop environment.
My taskbar has the "automatic disappear" function activated. Using x2go-client,
if you move the mouse at the bottom the taskbar appears but,
you only have 2 or 3 seconds for choice an application to launch because the 
task bar will disappear.


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 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 x2goclient depends on:
ii  libc6   2.13-38
ii  libcups21.5.3-5
ii  libgcc1 1:4.7.2-5
ii  libldap-2.4-2   2.4.31-1+nmu2
ii  libqt4-network  4:4.8.2+dfsg-11
ii  libqt4-svg  4:4.8.2+dfsg-11
ii  libqtcore4  4:4.8.2+dfsg-11
ii  libqtgui4   4:4.8.2+dfsg-11
ii  libssh-40.5.4-1
ii  libstdc++6  4.7.2-5
ii  libx11-62:1.5.0-1+deb7u1
ii  libxpm4 1:3.5.10-1
ii  nxproxy 2:3.5.0.20-0+wheezy~main~405~build1
ii  openssh-client  1:6.0p1-4

Versions of packages x2goclient recommends:
ii  openssh-server  1:6.0p1-4
ii  rdesktop1.7.1-1

Versions of packages x2goclient suggests:
pn  pinentry-x2go  

-- 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#712668: initramfs-tools broken with latest move to jessie

[Ben Hutchings]

Control: reassign -1 plymouth

On Tue, 2013-06-18 at 08:45 -0400, Brent S. Elmer wrote:
> Package: initramfs-tools
> Version: 0.112
> Severity: normal
> 
> When I upgraded my jessie box on Monday, I started getting this error in
> Synaptic:
> 
> Processing triggers for initramfs-tools ...
> update-initramfs: Generating /boot/initrd.img-3.2.21.120712
> cp: cannot stat `/usr/lib/i386-linux-gnu/pango/1.6.0/module-
> files.d/libpango1.0-0.modules': No such file or directory
> E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1.
 ^

This means the error occurred in plymouth's extension to
initramfs-tools, not initramfs-tools itself.  I'm reassigning
accordingly.

[...]
> When I try and do a reinstall of initramfs-tools in synaptic,
> I get the following error:
> 
> E: Internal Error, No file name for initramfs-tools:i386
> 
> Something appears to be badly broken.

That sounds like a bug in synaptic, but you'll have to report that
separately.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Bug#520786: Localicing error

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Di den 18. Jun 2013 um 12:56 schrieb Didier 'OdyX' Raboud:
> Le lundi, 6 avril 2009 17.26:11, Martin Pitt a écrit :
> > UTF-8 works everywhere with every language, and finally gets rid of
> > the entire encoding problem altogether. Non-UTF8 encodings make text
> > unreadable!
> 
> I don't intend to patch cups to support non-UTF8 locales, hereby closing this 
> bug.

Well, it is common sense to use iconv to produce output for every
locale. Non-UTF-8 systems are not that uncommon.

And UTF-8 is introducing new problems that you do not have with latin
charset as there are byte combinations that drives your system cracy if
it is set to UTF-8.

So, no, UTF-8 is no solution for all problems. And just the fact that
"it works" doesn't mean that it works good.

But I cannot force you to solve the bug. But I think, it would be sad if
you ignore the fact that there are other encodings around.

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCgAGBQJRwE47AAoJEKZ8CrGAGfas3YsL/0V3ULW/nDuXuQ3JDqh6uBp4
l4dBWLyX4TOjzQ/C+5MhyHsKcAylXQlt4kdEPF2HmRu/jy47PqPjqUMthGkHjxPh
zbYRnodxpZhKS0fqXos4hqvk2/wnzcSi/hHD1VT7SOOC0DDTLkyEjsk9glZt1mCv
JRMjXbRZ/ZKRXHlbIM/VjbmVhvbQj+aL21phYD8UdLaactaL5THzEhNZRDX6XKun
Mrr7rU3r5wJib9xttZi3KF+6GsNwrGbFGqe4U7CQ7/H/JNLmfGSXHByuq4rGpnow
VtwcpzczhmyGJIaxitP+fEtqmp8dZ6WSbgP0wE3+BI1uA/+K3Ooro3jGftDnmI5R
8ioGXi6M2y9s7TKrgwUQLYBNbgFsntgeM+3gwl0TT6qUfj5brla5tuIi3at6W8rW
Ou8r8c1g+Fcbbsk5IkjfFiF7pEErXBYalCxe/k7jScvr8cDf8vH739NCI/zalsGy
ruMc113GPIMlGva4dRHhuckRE5zF8dvM/QhicLHczA==
=lEeT
-END PGP SIGNATURE-


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

Bug#712663: gdb with pid argument doesn't work

[Vincent Lefevre]

Control: clone -1 -2
Control: retitle -1 gdb with pid argument doesn't work (ptrace: Operation not 
permitted)
Control: retitle -2 gdb: confusing error message "$HOME/pid: No such file or 
directory"
Control: severity -2 wishlist

On 2013-06-18 14:25:59 +0200, Vincent Lefevre wrote:
> I wonder what gdb is trying to do, but the error messages are no clear.
> Does it fail because /home/vlefevre/29743 doesn't exist???

I'm cloning this bug since this is a separate problem.
Error messages should be informative.

Here I think that I shouldn't get

  /home/vlefevre/29743: No such file or directory.

because gdb has *already* considered that 29743 was a PID.

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


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

Bug#712015: cups-filters: cups-pdf produces ugly pdfs through its pixelated font

[王晓林]

Thanks, Brian. I played with TitlePref and cost factor just now. And use

strings pdfoutputfile | grep Title


to see anything interesting. After processing a tmp.c under 4 different
conditions, I got the following results:

   -
   - /Title(tmp.c)   【TitlePref 0, cost factor 65】
   - /Title(tmp.c)   【TitlePref 1, cost factor 65】
   - /Title(\(\(stdin\)\))>>endobj【TitlePref 0, cost factor 66】
   - /Title(\(\(stdin\)\))>>endobj【TitlePref 1, cost factor 66】

It seems as long as cost factor is 66, argv[3]=stdin. Changing TitlePref
apparently can't help me any.

Xiaolin



--
王晓林



On Tue, Jun 18, 2013 at 7:20 PM, Brian Potkin wrote:

> On Mon 17 Jun 2013 at 17:35:19 +0800, 王晓林 wrote:
>
> > Yeah, I just tried 300, 600, 1200, 2400dpi while setting cost factor to
> 66.
> > Higher DPI value indeed results better PDF quality. But I still prefer
> cost
> > factor 65, because
> >
> >1. Size matters. With same dpi value, cost factor 65 results in a much
> >smaller PDF file. Examples:
> >   - 66-2400dpi.pdf is 15523 bytes
> >   - 65-2400dpi.pdf is 8386 bytes
> >2. Name matters. Processing a hello.c file into a PDF,
> >   - With cost factor 65, it give me a hello.pdf
> >   - With cost factor 66, it always give me a _stdin_.pdf. So I have
> to
> >   rename it to something else before it's overwritten by next run.
>
> This is a very sound argument and, after all, you are only reverting to
> the way Squeeze deals with PostScript files sent to cups-pdf.  However,
> I just wanted to tidy up a loose end or two, so thanks for confirming
> that PDF quality does not depend on cost factor. And thank you for the
> level of detail you have provided during discussion.
>
> Always getting _stdin_.pdf results from a combination of a number of
> things. In the first place the name originates from the method used by
> Emacs to send the file to CUPS. Then CUPS simply processes the file in a
> normal and, as far as I can tell, non-buggy, way. We see this in your
> error_log:
>
>D [13/Jun/2013:10:44:42 +0800] [Job 102] argv[3]="(stdin)"
>
> argv[3] is the job title and is used on the command lines of pstopdf,
> pdftopdf and pdftops.  If TitlePref is 1 in /etc/cups/cups-pdf.conf then
> argv[3].pdf becomes the output filename.
>
> For a TitlePref of 0 (the default) the output filename is taken from
> %Title in the PostScript file received from CUPS *after filtering by
> pdftops*. pdftops contructs a %Title from the job title.
>
> Cheers,
>
> Brian.
>
>

Bug#712672: gnome-control-center: wacom tablet hover click/tpc buttons setiing unavailable

[Michal Suchanek]

Source: gnome-control-center
Version: 3.8
Severity: normal
Tags: patch

Hello,

I tried to run gnome and noticed that the gnome settings do not have
option to set up the stylus button click style. Without this setting my
tablet is pretty much unusable.

Please add.

Thanks

Michal


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (910, 'testing'), (900, 'stable'), (610, 'oldstable'), (410, 
'unstable'), (200, 'experimental'), (150, 'precise-updates'), (150, 
'precise-security'), (150, 'precise')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash
Only in gnome-control-center-3.8.3.mod: gnome-control-center-build-deps_1.0_amd64.deb
diff -ur -x debian gnome-control-center-3.8.3/panels/wacom/cc-wacom-page.c gnome-control-center-3.8.3.mod/panels/wacom/cc-wacom-page.c
--- gnome-control-center-3.8.3/panels/wacom/cc-wacom-page.c	2013-06-05 11:27:56.0 +0200
+++ gnome-control-center-3.8.3.mod/panels/wacom/cc-wacom-page.c	2013-06-18 14:52:49.565316000 +0200
@@ -989,6 +989,14 @@
 }
 
 static void
+hover_click_toggled_cb (GtkSwitch *sw, GParamSpec *pspec, gpointer *user_data)
+{
+	CcWacomPagePrivate	*priv = CC_WACOM_PAGE(user_data)->priv;
+
+	g_settings_set_boolean (priv->wacom_settings, "tablet-pc-button", ! gtk_switch_get_active (sw));
+}
+
+static void
 set_left_handed_from_gsettings (CcWacomPage *page)
 {
 	CcWacomPagePrivate	*priv = CC_WACOM_PAGE(page)->priv;
@@ -1003,6 +1011,15 @@
 }
 
 static void
+set_hover_click_from_gsettings (CcWacomPage *page)
+{
+	CcWacomPagePrivate  *priv = page->priv;
+
+	gtk_switch_set_active (GTK_SWITCH (WID ("switch-hover-click")),
+			!g_settings_get_boolean (priv->wacom_settings, "tablet-pc-button"));
+}
+
+static void
 set_mode_from_gsettings (GtkComboBox *combo, CcWacomPage *page)
 {
 	CcWacomPagePrivate	*priv = page->priv;
@@ -1155,6 +1172,10 @@
 	g_signal_connect (G_OBJECT (sw), "notify::active",
 			  G_CALLBACK (left_handed_toggled_cb), self);
 
+	sw = GTK_SWITCH (WID ("switch-hover-click"));
+	g_signal_connect (G_OBJECT (sw), "notify::active",
+			  G_CALLBACK (hover_click_toggled_cb), self);
+
 	g_signal_connect (G_OBJECT (WID ("display-link")), "activate-link",
 			  G_CALLBACK (display_clicked_cb), self);
 
@@ -1379,6 +1400,8 @@
 	if (gsd_wacom_device_reversible (stylus))
 		set_left_handed_from_gsettings (page);
 
+	set_hover_click_from_gsettings (page);
+
 	/* Tablet icon */
 	set_icon_name (page, "image-tablet", gsd_wacom_device_get_icon_name (stylus));
 
diff -ur -x debian gnome-control-center-3.8.3/panels/wacom/gnome-wacom-properties.ui gnome-control-center-3.8.3.mod/panels/wacom/gnome-wacom-properties.ui
--- gnome-control-center-3.8.3/panels/wacom/gnome-wacom-properties.ui	2013-06-05 11:27:56.0 +0200
+++ gnome-control-center-3.8.3.mod/panels/wacom/gnome-wacom-properties.ui	2013-06-18 16:30:40.949316000 +0200
@@ -352,6 +352,39 @@
 1
   
 
+
+  
+True
+False
+end
+center
+Hover Click
+
+  
+
+  
+  
+0
+2
+1
+1
+  
+
+
+  
+True
+True
+start
+center
+False
+  
+  
+1
+2
+1
+1
+  
+
   
   
 1

Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages

[Mathieu Malaterre]

On Sat, Jun 15, 2013 at 6:20 PM, Dmitry Smirnov  wrote:
> Build type is better to leave as "RELWITHDEBINFO". This might be
> useful if you decide to provide -dbg package or just to (re-)build
> with debugging info with command like


Technically RelWithDebInfo should not be used anymore with cmake from sid:

http://lists.debian.org/debian-devel/2013/06/msg00278.html

It now appends -DNDEBUG ... see #701231 for more info

2cts


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

Bug#520786: Localicing error

[Didier 'OdyX' Raboud]

Le mardi, 18 juin 2013 14.10:38, Klaus Ethgen a écrit :
> Am Di den 18. Jun 2013 um 12:56 schrieb Didier 'OdyX' Raboud:
> > I don't intend to patch cups to support non-UTF8 locales, hereby closing
> > this bug.
> 
> Well, it is common sense to use iconv to produce output for every
> locale. Non-UTF-8 systems are not that uncommon.

Common-sense is still not the same as "just review and apply the patch that 
someone provided in the bugreport". Apparently it's not that easy common-
sense: noone produced a patch for this issue yet.

> So, no, UTF-8 is no solution for all problems. And just the fact that
> "it works" doesn't mean that it works good.

Sure. But it works. I am yet to see a bug _in_cups_, that was due to UTF-8.

> But I cannot force you to solve the bug. But I think, it would be sad if
> you ignore the fact that there are other encodings around.

You're putting words in my mouth: I don't ignore that there are other 
encodings around, and didn't write that at all, please re-read my quote above.

Cheers,
OdyX


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

Bug#669712: [freeplane] RE: freeplane: Visual corruption after scrolling mindmap

[Omega Weapon]

On 17/06/13 19:47, Felix Natter wrote:

Omega Weapon  writes:


There is a separate failure where freeplane suddenly ignores all keyboard
input, but I later confirmed this also happened under the normal
graphics


You could try to update to 1.2.23, but I don't know whether that would
fix it (probably not).


OK, will wait till that and its dependencies hit testing. Not looking 
forward to it if this upgrade will visually trash my mindmaps though ;) 
(At work I tried a recent version and they'd changed the way things were 
rendered, making it a lot less space efficient etc - went straight back 
to the 'current' version).


I was imagining I'd need to get C++ and Java progression to fight the 
keyboard issue.



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

Bug#692424: Migration to ibus 1.5

[Osamu Aoki]

Hi,

I am fixing wheezy bug now. So please wait for uploading ibus 1.5 based
(including 1.4.99) packages for next few weeks until new 1.4.1/1.4.2
based package goes to the testing first.

As for the discussion on symbol file, I have opinion as stated in 
 Message #52 : http://bugs.debian.org/692424#52

When uploading new 1.5 based package, it is best done to experimental
since Gnome fixes are still there for now.  But use of the latest
upstream version 1.5.2 is more desirable.

Osamu


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

Bug#666898: icedove: inconsistent spacing between folder icon and folder name

[Klaus]

Package: icedove
Version: 17.0.5-2
Followup-For: Bug #666898

Dear Maintainer,

the mis-alignment is now much more severe, see attached
screenshot. In my experience this effects only folders that have new
un-read mail. Clicking on that folder label once, and subsequently
selecting any other folder, re-draws the "wrongly" labelled folder and
everything is fine.


Klaus 

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

Kernel: Linux 3.9-1-amd64 (SMP w/2 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.4
ii  fontconfig2.9.0-7.1
ii  libasound21.0.27.1-1
ii  libatk1.0-0   2.8.0-2
ii  libc6 2.17-5
ii  libcairo2 1.12.14-5
ii  libdbus-1-3   1.6.12-1
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.21-stable-1
ii  libffi6   3.0.13-4
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.8.1-3
ii  libgdk-pixbuf2.0-02.28.2-1
ii  libglib2.0-0  2.36.3-1
ii  libgtk2.0-0   2.24.18-1
ii  libhunspell-1.3-0 1.3.2-4
ii  libjpeg8  8d-1
ii  libnspr4  2:4.10-1
ii  libnss3   2:3.15-1
ii  libnss3-1d2:3.15-1
ii  libpango1.0-0 1.32.5-5
ii  libpixman-1-0 0.26.0-4
ii  libsqlite3-0  3.7.17-1
ii  libstartup-notification0  0.12-3
ii  libstdc++64.8.1-3
ii  libvpx1   1.2.0-2
ii  libx11-6  2:1.6.0-1
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.20-1
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6

Versions of packages icedove suggests:
ii  fonts-lyx 2.0.6-1
ii  libgssapi-krb5-2  1.10.1+dfsg-6

-- no debconf information
<>