date:20140217

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi release team,

Please bear with me as this is my very first binNMU request.

I need to have the hdf5 source package rebuilt in wheezy in order to fix
#739261. This is because the current hdf5 release in wheezy was built with
a gfortran older than the one currently in wheezy.

nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
(closes: #739261)

Many thanks in advance,

_g.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTAeWrAAoJEO/obGx//s+Dg+QH/jtBfwpXaBGUul3rK8+3f7jx
bqL3T+Kh0zyTZKBDiVJFdCJ5ciu3TJtuEuATGqNgErArnlViVRSpg0FJKchVHvZG
MIQd+/Jj9ywCXX2PdwNTuzAR37/O/KD91b6BcV2yYnIX3WaPYd2snGylgtF8mbjT
YN1nxXkM/tQm08ccE6qWcvD9/2y9w3ust+5dTvaV2xxyiW3m89UOmpM7RIZvzaWN
KBECXzrBqRV1gt9JQfpdudYJPWZ0RCugtjcHXeykjq4jrRl5q0KF56R5l5WuxEHB
gfOPvXL4XTwjky8UwND2jqLU+Hwe932dxfVF5+k9RbaE8+wlz8N7D9GhVrrz4pg=
=gasF
-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#739267: fex: new version available: 20140215

2014-02-17 Thread Matthias Wimmer

Package: fex
Version: 20130805-1
Severity: wishlist

A new version of F*EX has been released. It would be nice, if the package could
get updated to it.

http://fex.rus.uni-stuttgart.de/fex.html



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

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

Versions of packages fex depends on:
ii  adduser 3.113+nmu3
ii  courier-mta [mail-transport-agent]  0.68.2-1+b1
ii  debconf [debconf-2.0]   1.5.52
ii  libdigest-md5-file-perl 0.08-1
ii  libjs-jquery1.7.2+dfsg-3
ii  perl5.18.2-2
ii  ucf 3.0027+nmu1
ii  xinetd [inet-superserver]   1:2.3.15-3

Versions of packages fex recommends:
ii  fex-utils20130805-1
ii  libnet-dns-perl  0.68-1.2
ii  perl-modules 5.18.2-2

fex suggests no packages.

-- Configuration Files:
/etc/fex/fup.pl [Errno 13] Keine Berechtigung: u'/etc/fex/fup.pl'

-- debconf information:
  fex/lastver: 0


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

Bug#739268: gogglesmm: new version available 0.13.0

2014-02-17 Thread Cord Beermann

Package: gogglesmm
Severity: wishlist
Tags: upstream

Hallo,

Upstream changed development address. It is now at
https://github.com/gogglesmm/gogglesmm/releases

There is also a new version 0.13.0

Cord


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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-17 Thread Thomas Orgis

Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio riku.voi...@iki.fi: 

 Thanks Peter for explaining, this was how I ended up the suggestion
 in the bug.
 
  I see. In that case, I'll have to leave the package as it until
  something along those lines is implemented.
 
 Yes. The ideal solution is for the upstream to implement cpu runtime
 detection that:
 
 1) uses neon if it is available
 2) falls back to fixed point if app requested 16-bit playback
 3) finally falls back to generic fpu code if neither of above applies
 
 Any packaging level workaround is going to be suboptimal for someone.

Isn't the approach for the linker to select libraries like libavcodec
on the table anymore? I see that I'll have to add that float conversion
code to keep the features along all builds, but selecting a vfp and
non-vfp variant for fixed point or floating point via the linker seems
like the most clean approach you are going to get.

NEON detection may come... but if we have linker selection, that would
be covered right now.

So ... can I get away with adding that stupid float conversion, so
folks have reasonable performance in likely applications of debian on
ARM, please? ;-)


Alrighty then,

Thomas

PS: I'll have to remove those experimental markings from the nofpu
variants in configure help. They are getting old.



signature.asc
Description: PGP signature

Bug#739266: nmu: hdf5_1.8.8-9

Gilles Filippini wrote, On 17/02/2014 11:34:
 Please bear with me as this is my very first binNMU request.
 
 I need to have the hdf5 source package rebuilt in wheezy in order to fix
 #739261. This is because the current hdf5 release in wheezy was built with
 a gfortran older than the one currently in wheezy.
 
 nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

Ah sorry, I've seen a syntax mistake just after pushing send  (missing '.').
The nmu line should read:

nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in wheezy 
(closes: #739261)

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#739270: task-british-kde-desktop: Include Print-manager package in KDE desktop on install

2014-02-17 Thread Nick

Package: task-british-kde-desktop
Version: 3.20
Severity: normal
Tags: d-i

Dear Maintainer,

I've got the task-british-kde-desktop installed though i suspect this applies
to the default kde desktop task too.

Basically, I think the print-manager package which puts the printing icon in
the system tray for management of that, should be installed by default with the
kde task - or should certainly be installed when a print-server is included in
that.

Cheers.



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

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

Versions of packages task-british-kde-desktop depends on:
ii  tasksel  3.20

Versions of packages task-british-kde-desktop recommends:
ii  kde-l10n-engb  4:4.11.3-1

task-british-kde-desktop 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#738101: RFS: awstats/7.3+dfsg-1

2014-02-17 Thread Sergey B Kirpichev

On Mon, Feb 17, 2014 at 09:36:12AM +0800, Paul Wise wrote:
On Sun, 2014-02-16 at 15:19 +0400, Sergey Kirpichev wrote:

I hope, that's fixed in:
http://anonscm.debian.org/gitweb/?p=collab-maint/awstats.git;a=commit;h=9c8f27ceb7f9490387a32b9fb2f45b21f69f853d

It doesn't have any privacy issues, but:

It is utterly pointless to include a 1x1 tracking gif in a source
package. The whole point of 1x1 GIFs is privacy violation

Yeah, probably it's so. Removed. Package on m.d.n was updated.

I was under impression what this is to workaround some formatting issues with
some ancient browsers.

Not sure if it makes sense to have input type=image without the
image in it. Please replace that with type=submit and drop the border.

Could you kindly provide a more detailed *technical*
suggestion in this case (facebook patch)?

This has PHP code for computing the URL but it should be easy to replace
that part with a link to the page @ http://awstats.sourceforge.net/docs/

https://stackoverflow.com/questions/10988815/facebook-twitter-and-google-1-buttons-using-only-html-no-javascript

I don't sure if that does exactly what removed js is supposed to do.

https://developers.facebook.com/docs/plugins/like-button
asks to login, so I'll wait for a while, until this will not change...

btw, I doubt that this whole idea is working for urls like
file:///usr/share/doc/...

It's not reasonable to believe, that every maintainer would read all
provided in the package *.html files in a regular way to find and fix
such problems. Without automation - it's just a waste of time.

I didn't mention detection at all.

If not all - that's mostly useless.

My objection was that your message
implied you wouldn't fix these issues I detected and informed you about
until lintian was fixed to detect the issues I detected manually.
Sorry if I wasn't clear enough about that.

No, that was very clear.

I see that index.html has a privacy violation in the form of a Google
SiteSearch JavaScript. Lintian doesn't detect it, filing a bug about it.

But it's removed in the last patch, isn't?

BTW, it might be appropriate to forward your patches upstream too since
having them online is also a privacy violation because browsers load
JavaScript and images by default.

I will try to do this.

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

Bug#739269: Please move libwayland-egl out of libegl1-mesa-drivers

2014-02-17 Thread Emilio Pozuelo Monfort

On 17/02/14 11:48, Sjoerd Simons wrote:
 Package: libegl1-mesa-drivers
 Severity: normal
 
 libwayland-egl has been included in the libegl1-mesa-drivers, which seems a 
 bit
 odd as it's an application library not a driver.
 
 Practically this causes an issue on systems where wayland is used but the
 EGL/GL stack isn't provided by mesa as applications using libwayland-egl 
 depend
 on libegl1-mesa-drivers which almost forcibly pulls in mesa.

How would alternative implementations satisfy the dependency? Should we name the
package libwayland-egl1-mesa, and have the shlibs force a dependency on
libwayland-egl1-mesa | libwayland-egl1-provider (or similar) ?

Emilio


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

Bug#739266: nmu: hdf5_1.8.8-9

2014-02-17 Thread Steffen Grunewald

On Mon, Feb 17, 2014 at 11:46:39AM +0100, Gilles Filippini wrote:
 Gilles Filippini wrote, On 17/02/2014 11:34:
  Please bear with me as this is my very first binNMU request.
  
  I need to have the hdf5 source package rebuilt in wheezy in order to fix
  #739261. This is because the current hdf5 release in wheezy was built with
  a gfortran older than the one currently in wheezy.
  
  nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
  (closes: #739261)
 
 Ah sorry, I've seen a syntax mistake just after pushing send  (missing '.').
 The nmu line should read:
 
 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

Are there plans to make libhdf5-serial-dev work again, aka #706044?

- S


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

Bug#739245: conky-std: fails to upgrade lenny - squeeze - wheezy - trying to overwrite /etc/conky/conky.conf

On 2014-02-17 09:57, Vincent Cheng wrote:
 There actually was a conky package in squeeze, but it got moved into
 contrib by the previous maintainer, whereas conky in lenny and wheezy
 (and later) is in main (#579102). Without contrib enabled though,
 piuparts wouldn't know this.

And that's the reason I didn't notice this earlier: testing packages
from main with only main enabled is a fairly recent change.

Andreas


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

Bug#736422: Is crc32 needed

2014-02-17 Thread Thomas Lange

I'm wondering if the kernel driver crc32 is really needed? But first, please
check if dracut 034-2 (from testing, and it also works in stable)
already fixes your problem. 

-- 
regards Thomas


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

Bug#613484: /usr/bin/ecl is not installed

2014-02-17 Thread Ph. Marek

Package: ecl
Version: 13.5.1+dfsg2-4
Followup-For: Bug #613484

This is still an issue:


$ apt-get install --reinstall ecl
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded.
Need to get 0 B/3182 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 404956 files and directories currently installed.)
Preparing to unpack .../ecl_13.5.1+dfsg2-4_amd64.deb ...
Unpacking ecl (13.5.1+dfsg2-4) over (13.5.1+dfsg2-4) ...
Processing triggers for man-db (2.6.6-1) ...
Setting up ecl (13.5.1+dfsg2-4) ...
Processing triggers for libc-bin (2.17-97) ...
$ ls -la /usr/bin/ecl
ls: cannot access /usr/bin/ecl: No such file or directory



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

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

Versions of packages ecl depends on:
ii  gcc  4:4.8.2-2
ii  libc62.17-97
ii  libffi6  3.0.13-12
ii  libgc-dev1:7.2d-6
ii  libgc1c2 1:7.2d-6
ii  libgmp10 2:5.1.3+dfsg-1
ii  libgmp3-dev  2:5.1.3+dfsg-1
ii  libncurses5-dev  5.9+20140118-1

ecl recommends no packages.

Versions of packages ecl suggests:
pn  ecl-doc  none
pn  slimenone

-- 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#739271: xpdf: 3.03-12 onwards does not process key bindings in ~/.xpdfrc

2014-02-17 Thread Kaustuv Chaudhuri

Package: xpdf
Version: 3.03-16+experimental2
Severity: important

From 3.03-12 (50c3fa13d) onwards, after GlobalParams was changed to
XPDFParams, it appears that key binding directives in the configuration
file (~/.xpdfrc) are being ignored.

This is obviously a pretty severe loss of functionality.

To fix this, please just copy-and-paste the following functions from
GlobalParams to XPDFParams: parseBind, parseUnbind, parseKey. Also add
the corresponding else if cases in parseLine.

I have tested this and it seems to work for me for key bindings. I have
attached a patch below for XPDFParams.{h,cc}, but I am not familiar
enough with Debian's oackaging system to submit it as a git-pullable
patch. My apologies, but it should be easy enough to adapt it.


--- xpdf/XPDFParams.h.orig  2014-02-17 12:20:41.0 +0100
+++ xpdf/XPDFParams.h   2014-02-17 12:30:07.475615604 +0100
@@ -87,12 +87,18 @@
   GString *getInitialZoom();
   GBool getContinuousView();
   int getPSPaperWidth();
   int getPSPaperHeight();
 
 private:
+  void parseBind(GList *tokens, GString *fileName, int line);
+  void parseUnbind(GList *tokens, GString *fileName, int line);
+  GBool parseKey(GString *modKeyStr, GString *contextStr,
+int *code, int *mods, int *context,
+const char *cmdName,
+GList *tokens, GString *fileName, int line);
   void parseCommand(const char *cmdName, GString **val,
 GList *tokens, GString *fileName, int line);
   void parseYesNo(const char *cmdName, GBool *flag,
   GList *tokens, GString *fileName, int line);
   GBool parseYesNo2(char *token, GBool *flag);
   void parsePSFile(GList *tokens, GString *fileName, int line);
--- xpdf/XPDFParams.cc.orig 2014-02-17 12:20:41.0 +0100
+++ xpdf/XPDFParams.cc  2014-02-17 12:30:07.475615604 +0100
@@ -163,12 +163,206 @@
 }
   }
   unlockXpdfParams;
   return cmds;
 }
 
+void XpdfParams::parseBind(GList *tokens, GString *fileName, int line) {
+  KeyBinding *binding;
+  GList *cmds;
+  int code, mods, context, i;
+
+  if (tokens-getLength()  4) {
+error(errConfig, -1, Bad 'bind' config file command ({0:t}:{1:d}),
+ fileName, line);
+return;
+  }
+  if (!parseKey((GString *)tokens-get(1), (GString *)tokens-get(2),
+   code, mods, context,
+   bind, tokens, fileName, line)) {
+return;
+  }
+  for (i = 0; i  keyBindings-getLength(); ++i) {
+binding = (KeyBinding *)keyBindings-get(i);
+if (binding-code == code 
+   binding-mods == mods 
+   binding-context == context) {
+  delete (KeyBinding *)keyBindings-del(i);
+  break;
+}
+  }
+  cmds = new GList();
+  for (i = 3; i  tokens-getLength(); ++i) {
+cmds-append(((GString *)tokens-get(i))-copy());
+  }
+  keyBindings-append(new KeyBinding(code, mods, context, cmds));
+}
+
+void XpdfParams::parseUnbind(GList *tokens, GString *fileName, int line) {
+  KeyBinding *binding;
+  int code, mods, context, i;
+
+  if (tokens-getLength() != 3) {
+error(errConfig, -1, Bad 'unbind' config file command ({0:t}:{1:d}),
+ fileName, line);
+return;
+  }
+  if (!parseKey((GString *)tokens-get(1), (GString *)tokens-get(2),
+   code, mods, context,
+   unbind, tokens, fileName, line)) {
+return;
+  }
+  for (i = 0; i  keyBindings-getLength(); ++i) {
+binding = (KeyBinding *)keyBindings-get(i);
+if (binding-code == code 
+   binding-mods == mods 
+   binding-context == context) {
+  delete (KeyBinding *)keyBindings-del(i);
+  break;
+}
+  }
+}
+
+GBool XpdfParams::parseKey(GString *modKeyStr, GString *contextStr,
+int *code, int *mods, int *context,
+const char *cmdName,
+GList *tokens, GString *fileName, int line) {
+  char *p0;
+  int btn;
+
+  *mods = xpdfKeyModNone;
+  p0 = modKeyStr-getCString();
+  while (1) {
+if (!strncmp(p0, shift-, 6)) {
+  *mods |= xpdfKeyModShift;
+  p0 += 6;
+} else if (!strncmp(p0, ctrl-, 5)) {
+  *mods |= xpdfKeyModCtrl;
+  p0 += 5;
+} else if (!strncmp(p0, alt-, 4)) {
+  *mods |= xpdfKeyModAlt;
+  p0 += 4;
+} else {
+  break;
+}
+  }
+
+  if (!strcmp(p0, space)) {
+*code = ' ';
+  } else if (!strcmp(p0, tab)) {
+*code = xpdfKeyCodeTab;
+  } else if (!strcmp(p0, return)) {
+*code = xpdfKeyCodeReturn;
+  } else if (!strcmp(p0, enter)) {
+*code = xpdfKeyCodeEnter;
+  } else if (!strcmp(p0, backspace)) {
+*code = xpdfKeyCodeBackspace;
+  } else if (!strcmp(p0, insert)) {
+*code = xpdfKeyCodeInsert;
+  } else if (!strcmp(p0, delete)) {
+*code = xpdfKeyCodeDelete;
+  } else if (!strcmp(p0, home)) {
+*code = xpdfKeyCodeHome;
+  } else if (!strcmp(p0, end)) {
+*code = xpdfKeyCodeEnd;
+  } else if (!strcmp(p0, pgup)) {
+*code = xpdfKeyCodePgUp;
+  } else if (!strcmp(p0, pgdn)) {
+*code = xpdfKeyCodePgDn;
+  }

Bug#739273: dibbler-client: segfaults in TAddrAddr::getValid

2014-02-17 Thread Yann Droneaud

Package: dibbler-client
Version: 0.8.2-1
Severity: normal

Dear Maintainer,

I'm no more able to restart dibbler-client, as soon as it start
configuring the interface it segfault:

dibbler-client[47071]: segfault at 10 ip 0045ac00 sp 7fff78ba4348 
error 4 in dibbler-client[40+d8000]

When ran under valgrind, here's the report:

# valgrind --log-file=dibbler.valgrind.log --track-origins=yes  
/usr/sbin/dibbler-client run
| Dibbler - a portable DHCPv6, version 0.8.2 (CLIENT, Linux port)
| Authors : Tomasz Mrugalskithomson(at)klub.com.pl,Marek 
Senderskimsend(at)o2.pl
| Licence : GNU GPL v2 only. Developed at Gdansk University of Technology.
| Homepage: http://klub.com.pl/dhcpv6/
2014.02.17 12:07:24 Client Warning   Pid file found (pid=48245, file 
/var/lib/dibbler/client.pid), but process 48245 does not exist.
2014.02.17 12:07:24 Client NoticeMy pid (48295) is stored in 
/var/lib/dibbler/client.pid
2014.02.17 12:07:24 Client NoticeDetected iface dummy0/4, 
MAC=xx:xx:xx:xx:xx:xx.
2014.02.17 12:07:24 Client NoticeDetected iface eth1/3, 
MAC=yy:yy:yy:yy:yy:yy.
2014.02.17 12:07:24 Client NoticeDetected iface eth0/2, 
MAC=zz:zz:zz:zz:zz:zz.
2014.02.17 12:07:24 Client NoticeDetected iface lo/1, MAC=00:00:00:00:00:00.
2014.02.17 12:07:24 Client NoticeParsing /etc/dibbler/client.conf config 
file...
2014.02.17 12:07:25 Client Debug Prefix delegation option found.
2014.02.17 12:07:25 Client Debug Parsing /etc/dibbler/client.conf done, 
result=0
2014.02.17 12:07:25 Client Debug 1 interface(s) specified in 
/etc/dibbler/client.conf
2014.02.17 12:07:25 Client Info  Interface eth0/2 configuation has been 
loaded.
2014.02.17 12:07:25 Client Debug DUID's value = 
aa:bb:cc:dd:ee:ff:gg:hh:ii:jj was loaded from client-duid file.
2014.02.17 12:07:25 Client Info  My DUID is aa:bb:cc:dd:ee:ff:gg:hh:ii:jj.
2014.02.17 12:07:25 Client Info  Loading old address database 
(client-AddrMgr.xml), using built-in routines.
2014.02.17 12:07:25 Client Info  DB timestamp:1392635071, now()=1392635245, 
db is 174 second(s) old.
2014.02.17 12:07:25 Client Debug Loaded IA from a file: t1=3600, 
t2=7200,iaid=1, iface=2
2014.02.17 12:07:25 Client Debug Parsed IA, iaid=1, 
unicast=b80e:3ed1:f27f:0:b80e:3ed1:f27f:0
2014.02.17 12:07:25 Client Debug Loaded PD from a file: t1=3600, t2=7200, 
iaid=1, iface=2
2014.02.17 12:07:25 Client Debug Parsed prefix 2001:dead:beef:cafe::/56, 
pref=3800, valid=3800,ts=1392480252
2014.02.17 12:07:25 Client Debug Parsed PD, pdid=1, t1=3600, t2=7200
2014.02.17 12:07:25 Client Debug Client 
aa:aa:aa:aa:aa:aa:aa:aa:zz:zz:zz:zz:zz:zz loaded from disk successfuly (1/1/0 
ia/pd/ta).
2014.02.17 12:07:25 Client Debug Bind reuse enabled (multiple instances 
allowed).
2014.02.17 12:07:25 Client NoticeCreating control (::) socket on the lo/1 
interface.
2014.02.17 12:07:25 Client NoticeCreating socket 
(addr=fe80:::::) on eth0/2 interface.
2014.02.17 12:07:25 Client Debug Initialising link-state detection for 
interfaces: eth0/2
2014.02.17 12:07:25 Client NoticeCONFIRM support compiled in.
2014.02.17 12:07:25 Client Info  Creating CONFIRM: 1 IA(s) on eth0/2
2014.02.17 12:07:25 Client Debug Authentication is disabled, not including 
auth options in message.
2014.02.17 12:07:25 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:25 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:25 Client Info  Creating SOLICIT message with 0 IA(s), no 
TA and 1 PD(s) on eth0/2 interface.
2014.02.17 12:07:25 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:25 Client Debug Sleeping for 1 second(s).
2014.02.17 12:07:26 Client Info  Processing msg 
(CONFIRM,transID=0xd58839,opts: 1 3 8 6)
2014.02.17 12:07:26 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:26 Client Info  Processing msg 
(SOLICIT,transID=0x234345,opts: 1 25 8 6)
2014.02.17 12:07:26 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:26 Client Debug Sleeping for 1 second(s).
2014.02.17 12:07:27 Client Info  Processing msg 
(CONFIRM,transID=0xd58839,opts: 1 3 8 6)
2014.02.17 12:07:27 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:27 Client Debug Sleeping for 1 second(s).
2014.02.17 12:07:28 Client Info  Processing msg 
(CONFIRM,transID=0xd58839,opts: 1 3 8 6)
2014.02.17 12:07:28 Client Debug Sending CONFIRM(opts:1 3 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:28 Client Info  Processing msg 
(SOLICIT,transID=0x234345,opts: 1 25 8 6)
2014.02.17 12:07:28 Client Debug Sending SOLICIT(opts:1 25 8 6 ) on eth0/2 
to multicast.
2014.02.17 12:07:28 Client Debug Sleeping for 1 second(s).
2014.02.17 12:07:29 Client Info  Processing msg

Bug#739249: dh_perl support for packages embedding perl

2014-02-17 Thread Brendan O'Dea

On 17 February 2014 13:20, Marco d'Itri m...@linux.it wrote:
 Package: debhelper
 The inn and inn2 packages, which use an embedded perl interpreter,
 currently do this to express a proper dependency on perlapi-* (see
 #182089):

 dh_gencontrol -u-VPERLAPI=$$(perl -MConfig -e 'print perlapi- . 
 ($$Config{debian_abi} || $$Config{version})')

 dh_perl adds a perlapi dependency only to packages which contain XS
 modules, so it would be nice if it could either recognize packages which
 have an embedded perl interpreter or have a flag to force this
 behaviour.

It has been some time since I looked at this, but according to policy
you should not need a dependency on perlapi* at all:

  
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-embed.html#s-embedded_deps

The only required dependency is on libperl5.X, which should be added
automatically by dpkg-shlibdeps.  This will add, for the current
unstable version of perl, a dependency on libperl5.18 (= 5.18.2),
which transitively depends on the current (exact) version of
perl-base.

 (I see that it also would add a versioned dependency on perl, is it
 actually needed in my case?)

If the inn packages require anything from /usr/{lib,share}/perl
however which is not part of perl-base, you need to declare an
explicit dependency on perl.  It need not be versioned, since the
implicit perl-base dependency will handle that.

Note that the perlapi* dependencies were added for XS modules (which
is why dh_perl adds them only in that case).  They were added to
reduce the necessity of rebuilding XS modules with every minor Perl
revision when the newer revision is ABI compatible and to manage an
unversioned /usr/lib/perl5 directory, ensuring that everything in
there is compatible with the current /usr/bin/perl (not something
which is typically an issue for embedding programs).

I can see an argument however for also adding a perlapi* dependency
for packages which embed Perl, given that a non-trivial implementation
will be using just as much of the Perl internals as a typical XS
module.  This would require both a policy change, and an update to
dh_perl.

Niko: have there been cases where a dependency on both libperl5.x and
perlapi-5.X.y would have been different that just having the first
dependency?  I can imagine cases where ABI compatibility was broken by
minor versions, but don't recall an instance myself.

--bod


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

Bug#739275: /usr/bin/dh_python2: debian/pyversions silently overrides X-Python-Version field

2014-02-17 Thread Sam Morris

Package: python2.7
Version: 2.7.3-6
Severity: normal
File: /usr/bin/dh_python2

I was asked to help debug a package that kept being built with a
dependency on Python 2.6, even though X-Python-Version was set to '=
2.7'. It turned out that there was a left-over debian/pyversions file
containing '2.5-'.

While I appreciate the backwards-compatibility with the older
python-central/python-support packaging metadata, IMO dh_python2 should
abort with an error if information is supplied in two places; or at
least the information from the deprecated source should not override the
information from the control file.

Regards,

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages python2.7 depends on:
ii  libbz2-1.0 1.0.6-4
ii  libc6  2.17-97
ii  libdb5.1   5.1.29-5
ii  libexpat1  2.1.0-1+deb7u1
ii  libgcc11:4.7.2-5
ii  libncursesw5   5.9-10
ii  libreadline6   6.2+dfsg-0.1
ii  libsqlite3-0   3.7.13-1+deb7u1
ii  libssl1.0.01.0.1e-2+deb7u4
ii  libtinfo5  5.9-10
ii  mime-support   3.52-1
ii  python2.7-minimal  2.7.3-6

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.22-8
pn  python2.7-doc  none

-- 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#739274: libpam-tacplus: leaves modified pam configuration after install in wheezy, distupgrade to sid, purge

Package: libpam-tacplus
Version: 1.3.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package leaves a modified pam
configuration after upgrading from wheezy to sid and purging the
package.

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

0m53.0s ERROR: FAIL: After purging files have been modified:
  /etc/pam.d/common-account  not owned
  /etc/pam.d/common-auth not owned
  /etc/pam.d/common-password not owned
  /etc/pam.d/common-session  not owned
  /etc/pam.d/common-session-noninteractive   not owned
  /var/lib/pam/account   not owned
  /var/lib/pam/auth  not owned
  /var/lib/pam/password  not owned
  /var/lib/pam/seen  not owned
  /var/lib/pam/session   not owned
  /var/lib/pam/session-noninteractivenot owned


This looks like a missing pam-auth-update call somewhere ...


Cheers,

Andreas


libpam-tacplus_1.3.8-1.log.gz
Description: GNU Zip compressed data

Bug#673225: doh!

2014-02-17 Thread Marcel Partap

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry, missed this entirely..
just to recap: back in 2011 I took the stale par2 code from
http://parchive.sourceforge.net/, merged the patches various distros
had shipped with, and put it all on github. BlackIkeEagle contributed
several more improvements (including unicode-compatibility and
directory tree recursion), and I encouraged him to become the new
maintainer. So https://github.com/BlackIkeEagle/par2cmdline should in
fact be considered the new upstream of par2cmdline.
#BestRegards.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTAfyUAAoJEGXGsEqKOfvab3MP/R4acauPZGKLsiszaHHBHgE0
boWujsliJawzRCKrq7pOaHvV84oeGODKd91gat0jwKkft4d2OFDt2FmVBrigwKvv
xR+kOdvlBxL6KaksswkBwedyqc58Z81RNGcHeplGBdc71D+UFsi3GNoUYnKAJlsr
lhTodtAxc/5DEOJ4F3ncsjDL2wZzB/eDDRaWaGOLpuvcXJC5hBvAhY+cLQPKc3Fx
zVFNevnivoNijcG8OISEsxXrUMA0mr6oVEMqGEm2gEkqSNLUrkjSGcJca6KYT8fM
4s+D5W6jEH2Ge7m7iYVu7xG9/o7o3VJIjgGcti9G94LOjA9+1S1NACClc5xGFqe4
+ycxnviWQhstsM99iMMf/75GoapdyOj6E6CtUoKs1smhvrFLoz69FqZ+p6SE+1uT
fOsBvSEgkTBmWfxPUNsJwTyXhFEkUsGN1KBUMWB3fGMfgKCCFpkhT39IRCzZ4i8b
fE+1Z2hHi7AClDZOobYzJWKYEVtWc2GePXOT4dd9WVQWuvAan3K6P/zXD0qLYMPr
lIcrpPrIShKGcMbq0zDPqe9BOL3EeZFzocOSQVgwpgzYHTrDT7D1/kXW1FLbQSlI
WC8SWvhsUR9JqP5qYp65Q6BHlu8zH7vJDQ5jCWbypWI4gk9bV6yN2EjVaqE3vyIr
G9joh0NurbiGDV4wtZBJ
=n4I7
-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#738915: pd-aubio: FTBFS on non-linux

2014-02-17 Thread Steven Chamberlain

severity 738915 wishlist
user debian-...@lists.debian.org
usertags + kfreebsd
thanks

Hi,

On Thu, 13 Feb 2014 22:27:56 +0100, Julien Cristau wrote:
 Please either get this to build or reassign (and downgrade) this bug to
 ftp.debian.org to get the out of date pd-aubio binaries removed.

Out-of-date binaries have been removed as per #736431, downgrading this
accordingly.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


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

Bug#735814: ossim: FTBFS: configure: error: libtiff support required!

2014-02-17 Thread Francesco P. Lovergine

On Sun, Feb 16, 2014 at 12:23:31AM -0800, Hamish wrote:
 Hi,
 
 I thought I'd do an info drop.
 
 So in the past years Frankie maintained the package from DebianGIS
 git on Alioth (now the git repo on spawn-of-Alioth).
 
 http://anonscm.debian.org/gitweb/?p=pkg-grass/ossim.git;a=summary
 
 and you'll see there that he started on packaging the newer 1.8
 version, with libtiff updated, but I think he found the build system
 too much of a mess so stopped working on it in favour of letting
 someone else on the DebianGIS team try.
 

Yep, I can confirm that. Also, my main interest at the time
was about packaging orfeotoolbox, which still has issues (currently almost
solved) in using external stuff. So I stopped the upgrading of the ossim
library and tools.

 Since then OSSIM has moved to cmake and the build system is much
 improved. A fine Google of Code student named M. Rashad worked on
 OSSIM last summer, and after the summer was over started on
 new-generation OSSIM deb packages. Hopefully me  Massimo can
 convince him to join DebianGIS and continue the work there. :-)
 
 Anyway it is his packages you'll find in UbuntuGIS's ppa, and yes,
 they'll be a good starting point for the Mk III version of the OSSIM
 package in Debian.  (see also ancient ossim-old/ in alioth pkg-grass
 svn repo for MkI)
 

That could be possibily a good target for next orfeo package.

-- 
Francesco P. Lovergine


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

Bug#625278: Prioritization of broken symlink issues

2014-02-17 Thread Agustin Martin

On Sun, Feb 16, 2014 at 01:40:18PM -0500, Dave Steele wrote:
 On Sun, Feb 16, 2014 at 11:14 AM, Agustin Martin
  Sorry again if I look unpolite, I am just after lunch and a bit
  overheated. Debian policy must be stated directly by Debian policy,
  not indirectly by whatever package requirements. pipuarts is not
  Debian policy, so I'd personally consider this a bug in piuparts
  itself.
 
 I've come to the conclusion that the Policy is Debian's version of
 Godwin's Law. It can be a driving principle, more of just a guideline,
 or not important, dependent on the needs of the argument. Invoking it
 diverts discussion. So, no more about that from me.

Hi,

Sorry about my first reaction. Had a bad night and was really tired after
lunch, so overreacted at anything altering my planning. My apologies.

 If and when the test is elevated, the thousand packages will await
 resolution of the bug owner.

This is what made me angry. I think this is the wrong approach and indeed
can cause some really unneeded noise. 

Anyway, I think this will be fixed before we reach that point. But something
like

stage a) lintian warning + piuparts warning
stage b) lintian error   + piuparts error

would have IMHO be a better approach, even if the time between a) and b) is
not long. Being suddenly told that piuparts will soon fail with no previous
lintian complaint may be annoying. And lintian should provide a rationale
for this. I now see that this is provided as an experimental check in
lintian, but is not yet shown in normal lintian use.

Most of the work I wanted to do before getting rid of symlinks is already
done. Since symlinks will no longer be shipped I was pending to decide if
I should honour any change by sysadmins in the /usr/lib, /usr/share/dict
default symlinks or not. I am getting convinced that I should do this
exactly as update-alternatives do, hardcoding those links. This has the
additional advantage that is easier to implement and results in the same
behavior as before.

Regards,

-- 
Agustin


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

Bug#739275: /usr/bin/dh_python2: debian/pyversions silently overrides X-Python-Version field

2014-02-17 Thread Matthias Klose

Control: reassign -1 src:python-defaults

Am 17.02.2014 13:06, schrieb Sam Morris:
 Package: python2.7
 File: /usr/bin/dh_python2

no, was never part of python2.7.


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

Bug#725422: marked as done (systemd set kernel.sysrq=16)

2014-02-17 Thread Michael Biebl

Ben, you just closed the bug again. I assume this was by accident?

Am 17.02.2014 11:45, schrieb Debian Bug Tracking System:
 On Wed, 2013-11-27 at 20:19 +0100, Michael Stapelberg wrote:
  Hi Goffredo,
  
  Goffredo Baroncelli kreij...@gmail.com writes:
   Solved, the configuration file should be processed *before* the 
   default
   file.
   So I named the file /etc/sysctl.d/01-sysrq.conf.
  
   Unfortunately the things are even more complex. Recently systemd changed
   behaviour: with the latest version (207) the configuration must be
   processed after the systemd default file: so the file will must be named
   /etc/sysctl.d/99-sysrq.conf.
  Thanks for the heads-up.
  
  From the discussion I take it that there is no actual bug here, so I’m
  closing this report.
 There is a bug.  You should not ship /usr/lib/sysctl.d/50-default.conf .
 
 The default sysrq mask was reviewed some years ago by the kernel
 maintainers and a sensible default (not 1) is set in official kernel
 packages.  This should not be overridden just because people switch to
 systemd; nor should anyone else's customisation in /etc/sysctl.conf or
 kernel build config.

The downside of this approach obviously is, that as soon as you switch
kernels (e.g. use a self-compiled one), this setting changes.
So explicitly setting the sysrq key imho has benefits.

Do you remember, why you decided against using a sysctl.d snippet?

Let me also add, that custom modifications, if done via /etc/sysctl.conf
should be preserved, i.e. once [1] is fixed

Do you also happen to remember where this discussion happened so we have
some reference for this bug report.

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737184
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#739266: nmu: hdf5_1.8.8-9

Hi Steffen,

Steffen Grunewald wrote, On 17/02/2014 12:15:
 On Mon, Feb 17, 2014 at 11:46:39AM +0100, Gilles Filippini wrote:
 Gilles Filippini wrote, On 17/02/2014 11:34:
 Please bear with me as this is my very first binNMU request.

 I need to have the hdf5 source package rebuilt in wheezy in order to fix
 #739261. This is because the current hdf5 release in wheezy was built with
 a gfortran older than the one currently in wheezy.

 nmu hdf5_1.8.8-9 . ALL . stable -m Rebuild with current gfortran in wheezy 
 (closes: #739261)

 Ah sorry, I've seen a syntax mistake just after pushing send  (missing 
 '.').
 The nmu line should read:

 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in 
 wheezy (closes: #739261)
 
 Are there plans to make libhdf5-serial-dev work again, aka #706044?

I hadn't. But this is indeed a good opportunity to fix it as well. So
the plan would be to upload to stable a fix for #706044 which would
close #739266 by the way. Am I reading you correctly?

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#553035: willing to help

2014-02-17 Thread Alexandre Detiste

Hi,

For me, game-data-packager is the way to go to keep everything uniform.
Here is a patch adding tyrian to game-data-packager version 37.

It currently only recommends opentyrian,
so this can be compiled manually.


 Makefile  |2 
 lib/tyrian-mirrors|1 
 supported/tyrian  |  126 
++
 tyrian-data/README.Debian |4 +
 tyrian-data/control.in|   13 
 tyrian-data/copyright |   20 +++
 tyrian.mk |   34 
 7 files changed, 200 insertions(+)


Sample output:

tchet@legacy:~$ game-data-packager tyrian
game-data-packager tyrian arguments:
game-data-packager tyrian [ -f path ] | [ -w ]
-f path path to your existing copy of tyrian21.zip
-w  fetch tyrian21.zip from the World Wide Web
tchet@legacy:~$ 
tchet@legacy:~/game-data-packager-tyrian$ ./game-data-packager tyrian -f 
../tyrian21.zip 
generated /home/tchet/game-data-packager-tyrian/tyrian-data_37_all.deb.


Alexandre Detiste


Le jeudi 13 février 2014, 19:46:35 Etienne Millon a écrit :
 * Alexandre Detiste alexandre.deti...@gmail.com [140129 09:24]:
  I use this game and I'm willing to help.
 
 Hi,
 
 Unfortunately not a lot has changed since my last message. Due to the
 non-redistributability of opentyrian-data, it's impossible to create a
 source package for it. 

This is precisely the role of game-data-packager.

 For the moment I created an open-tyrian binary
 package that installs the data files to
 /usr/share/games/opentyrian/data. The zip can be found at the
 following URL:
 
 http://www.camanis.net/tyrian/tyrian21.zip
 
 However it's not possible as is. This zip file should be downloaded
 and unpacked during postinst to somewhere in /var (cache or lib). It
 is also possible to do this before launching the game somewhere in
 $HOME. The latter is probably better as it avoids to download as root.
 
 In the meantime, if you want to test, you can remove the dependency
 and launch the game in a directory where data/ contains game data (see
 src/file.c).
 
 For the actual download code, I don't know if it's possible to use
 game-data-packager, but it's always possible to roll our own solution,
 à la flashplugin-nonfree.
 
 In the meantime, I refreshed my packaging, fixed a few
 warnings and pushed my package to the following URL:
 
 git+ssh://git.debian.org/git/pkg-games/opentyrian.git

I got the code form elsewhere, but it works 
fine the data .deb from G-D-P.

#!/bin/sh
#hg clone https://code.google.com/p/opentyrian/
cd /home/tchet/bin/opentyrian
hg update

 
 As you can see your help is welcome :)
 
 You can add yourself to Uploaders and help fix the remaining lintian
 warnings, do the copyright review (should be OK), and/or of course
 find a solution for the data files :)
 
 If it's your first package I'll be happy to help you.
 
 Please let me know what you're interested in.
diff -rupN game-data-packager-37/lib/tyrian-mirrors game-data-packager-tyrian/lib/tyrian-mirrors
--- game-data-packager-37/lib/tyrian-mirrors	1970-01-01 01:00:00.0 +0100
+++ game-data-packager-tyrian/lib/tyrian-mirrors	2014-02-17 11:43:45.0 +0100
@@ -0,0 +1 @@
+http://www.camanis.net/tyrian/tyrian21.zip
diff -rupN game-data-packager-37/Makefile game-data-packager-tyrian/Makefile
--- game-data-packager-37/Makefile	2013-11-18 20:32:13.0 +0100
+++ game-data-packager-tyrian/Makefile	2014-02-17 12:38:51.577924881 +0100
@@ -42,6 +42,7 @@ default: $(DIRS)
 	make -f rott.mk VERSION=$(VERSION)
 	make -f wolf3d.mk VERSION=$(VERSION)
 	make -f lgeneral.mk LONG=LGeneral VERSION=$(VERSION)
+	make -f tyrian.mk VERSION=$(VERSION)
 
 $(DIRS):
 	mkdir -p $@
@@ -88,6 +89,7 @@ clean:
 	make -f rott.mk VERSION=$(VERSION) clean
 	make -f wolf3d.mk VERSION=$(VERSION) clean
 	make -f lgeneral.mk LONG=LGeneral VERSION=$(VERSION) clean
+	make -f tyrian.mk VERSION=$(VERSION) clean
 	for d in $(DIRS); do [ ! -d $$d ]  || rmdir $$d; done
 
 check:
diff -rupN game-data-packager-37/supported/tyrian game-data-packager-tyrian/supported/tyrian
--- game-data-packager-37/supported/tyrian	1970-01-01 01:00:00.0 +0100
+++ game-data-packager-tyrian/supported/tyrian	2014-02-17 12:57:14.445970699 +0100
@@ -0,0 +1,126 @@
+SHORTNAME=tyrian
+LONGNAME=Tyrian
+
+ZIPSUM=2a3b206a6de25ed4b771af073f8ca904
+
+tyrian_usage() {
+	echo game-data-packager ${SHORTNAME} arguments:
+	printf \tgame-data-packager ${SHORTNAME} [ -f path ] | [ -w ]
+\t\t-f path\t\tpath to your existing copy of tyrian21.zip\n\
+\t\t-w\t\tfetch tyrian21.zip from the World Wide Web\n
+}
+
+verify_args() {
+case $# in
+0)
+tyrian_usage
+exit 0
+;;
+1)
+if [ $1 != -w ]; then
+usage 2
+tyrian_usage 2
+exit 1
+fi
+downloadzip
+;;
+2)
+if [ $1 != -f ]; then
+

Bug#738962: [Debian-med-packaging] Bug#738962: python-csb: More issues with the tests

2014-02-17 Thread Tomas Di Domenico

Hi Dmitry,

On 15/02/14 10:13, Dmitry Shachnev wrote:
 Hi Tomas,
 
 Alternatively, you can make binary packages suggest/recommend
 them, but then you will need to add those packages as dependencies
 in debian/tests/control.

I understand, thank you for the explanation.

 The Git looks out of date (it does not even include the latest
 release), where did you update the code?

I'm sorry, I was working locally while trying to understand what's
going on. I've now updated the sources.

 Note: this failure seems to only happen on i386 and not amd64.

I'll contact upstream and see if they can take care of the i386 failure

 For running the tests, I personally use just adt-virt-null runner 
 in a clean environment, but probably using something like 
 adt-virt-schroot will be an easier solution. See this message for
 some instructions:
 
 https://lists.debian.org/debian-devel/2014/01/msg00507.html

I've successfully set up the schroot. When running the command as follows

adt-run python-csb_1.2.3+dfsg-1_all.deb --- adt-virt-schroot csb-amd64

I get a very short output from adt-run saying that the build and the
tests are done. I have my doubts about it though, because it returns
almost immediately.

 I am attaching a patch that addresses 1), 2) and 5), and also adds 
 a dependency on python3-all to ensure that tests are run for all 
 supported Python 3 versions. That patch will make the tests green 
 on ci.debian.net, but will not fix the real failure (3).

Thank you for the patch, I've applied it to the sources. I didn't know
about ci.debian.net, that's a great resource to have handy.

Cheers,
Tomás


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

Bug#739277: hikisetup throws an exception

2014-02-17 Thread IOhannes m zmoelnig

Package: hiki
Version: 1.0.0-0.2
Severity: important

Dear Maintainer,

running `hikisetup` i get:

$ hikisetup myhiki
/usr/bin/hikisetup:175:in `+': can't convert Errno::ENOENT into String
(TypeError)
from /usr/bin/hikisetup:175:in `rescue in main'
from /usr/bin/hikisetup:152:in `main'
from /usr/bin/hikisetup:180:in `main'

also note, that `man hiki` mentions a `--copy` flag, but

$ hikisetup --copy myhiki
/usr/bin/hikisetup: unrecognized option `--copy'
/usr/bin/hikisetup:175:in `+': can't convert GetoptLong::InvalidOption into 
String (TypeError)
from /usr/bin/hikisetup:175:in `rescue in main'
from /usr/bin/hikisetup:152:in `main'
from /usr/bin/hikisetup:180:in `main'

thus there is currently no way to create a new hiki site :-(

fgamsdr
IOhannes


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

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

Versions of packages hiki depends on:
ii  docdiff   0.4.0-2
ii  ruby  1:1.9.3.3
ii  ruby-hikidoc  0.0.6-1
ii  ruby-uconv0.6.1-1+b1
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2

hiki recommends no packages.

Versions of packages hiki suggests:
pn  apache2 | httpd  none
pn  ruby-imagesize   none
pn  ruby-rd  none
pn  ruby-rt  none
pn  tdiary-theme none

-- 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#657116: libtar: FTBFS on hurd-i386

2014-02-17 Thread Petter Reinholdtsen

[Magnus Holmgren]
 I have not forwarded the patch eliminating MAXPATHLEN yet, if that is
 what you mean. I did ask on the mailing list about releasing a new
 version with what's currently in git though.

Thank you for fixing libtar on Hurd and follow up on the issues with
upstream.  :)

I hope the testsuite patch also make it upstream, to make it easier to
ensure that libtar work after build. :)

-- 
Happy hacking
Petter Reinholdtsen


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

Bug#739278: subversion: E175013 svn diff -rN:M failure (access forbidden)

2014-02-17 Thread Vincent Lefevre

Package: subversion
Version: 1.8.5-2
Severity: normal

With the 1.8.5-2 client and some remote server, I get an error

svn: E175013: Access to '/svn/' forbidden

when I do svn diff -r118:119 https://host//subdir;, but
svn diff -r118:119 https://host//subdir/file; (where file
corresponds to the file that has changed in the diff) is OK.

If I'm in a working copy of https://host//subdir, then
svn diff -r118 is OK too (it seems that what makes the failure
disappear is that the diff is against BASE, which is local).

As a summary, to make the failure occur, one needs:
  * diffing between two *remote* revisions;
  * the URL corresponds to the subdir on which permissions have been
given.

The revisions don't seem to matter. I even get the same error for
-r118:118.

There's no such problem with svn 1.6.12 (r955767) on some other
Debian machine and svn 1.7.9 (r1462340) on an Ubuntu machine.
So, that's a regression.

I've reported the problem in the Subversion dev list, but there
were no conclusive comments. It might be a Debian specific bug.
URL's:

http://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/browser
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/145515

-- 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.12-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 subversion depends on:
ii  libapr11.5.0-1
ii  libaprutil11.5.3-1
ii  libc6  2.17-97
ii  libldap-2.4-2  2.4.31-1+nmu2+b1
ii  libsasl2-2 2.1.26.dfsg1-8
ii  libsvn11.8.5-2

subversion recommends no packages.

Versions of packages subversion suggests:
ii  db5.1-util5.1.29-7
ii  patch 2.7.1-4
ii  subversion-tools  1.8.5-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#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-17 Thread Steve McIntyre

On Mon, Feb 17, 2014 at 11:43:16AM +0100, Thomas Orgis wrote:
Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio riku.voi...@iki.fi: 

 Thanks Peter for explaining, this was how I ended up the suggestion
 in the bug.
 
  I see. In that case, I'll have to leave the package as it until
  something along those lines is implemented.
 
 Yes. The ideal solution is for the upstream to implement cpu runtime
 detection that:
 
 1) uses neon if it is available
 2) falls back to fixed point if app requested 16-bit playback
 3) finally falls back to generic fpu code if neither of above applies
 
 Any packaging level workaround is going to be suboptimal for someone.

Isn't the approach for the linker to select libraries like libavcodec
on the table anymore? I see that I'll have to add that float conversion
code to keep the features along all builds, but selecting a vfp and
non-vfp variant for fixed point or floating point via the linker seems
like the most clean approach you are going to get.

Yes, you can do that - build several copies of the library and use the
hwcaps / auxv approach to pick the best one for the hardware at link
time.

NEON detection may come... but if we have linker selection, that would
be covered right now.

Yup.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?


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

Bug#723773: certs and config checked OK

2014-02-17 Thread Mark Pavlichuk

Just to assure anyone working on this that my certs and config are OK, I 
copied this as a .ldaprc to a CentOS box (with openssl-linked 
ldapsearch), and it worked fine:


TLS_CACERT /root/.pki/ssl-cert-local-ca.pem
TLS_CERT /root/.pki/dhcpd.pem
TLS_KEY /root/.pki/dhcpd.key
#TLS_CERT /root/.pki/ldap-client.pem
#TLS_KEY /root/.pki/ldap-client.key

BASEdc=strategicit,dc=linuxoz,dc=net
URIldap://fusion.strategicit.linuxoz.net

TLS_REQCERT demand
#TLS_CIPHER_SUITE 256SECURE
TLS_CIPHER_SUITE TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH;

--
Mark Pavlichuk


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

Bug#720376: workaround: gvfs-open

2014-02-17 Thread Alad Wenter

I've applied the patch and it didn't work (for me). I haven't tried the 
latest version from git, however.


As a workaround, you can replace exo-open with gvfs-open which does work 
correctly. The required package for this is gvfs-bin. For example, 
Google Chrome uses /usr/bin/xdg-email, so you'd change exo-open to 
gvfs-open there.


Cheers,

Alad


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

Bug#739234: RM: elib -- ROM; Unmaintained upstream, useful functions long included in Emacs directly

On Sunday, 16. February 2014 22:10:48 Joerg Jaspert wrote:
 the subject says it. The package is basically unmaintained and by now
 no longer needed, so should go away. There are no rdeps either.

That implies #689773 needs to be fixed in wheezy, otherwise elib can't be 
removed after an upgrade to jessie.


Andreas


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

Bug#739280: packages.debian.orgh: changelog/copyright link results in 404 on package wheezy/file

2014-02-17 Thread Andreas Schwarz

Package: packages.debian.orgh
Version: packages.debian.org
Severity: minor

Dear Maintainer,

on https://packages.debian.org/wheezy/file the links Debian Changelog /
Copyright File results in 404 and Debian Patch Tracker produces an error

There was an error processing ur request

can't find any package named or containing 'file'

best wishes
A. Schwarz



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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#739279: tor: AppArmor profile prevents tor from starting obfsproxy

2014-02-17 Thread intrigeri

Package: tor
Version: 0.2.4.20-1
Severity: normal
Tags: patch

Hi,

as reported on Tor's ticket tracker (#9460, #6996), the AppArmor
profile we ship in the tor package prevents obfsproxy from starting.

This is fixed by the attached patch (against the debian-0.2.4 branch
in your packaging repository), that allows running obfsproxy under its
own profile if available, else unconfined. Successfully tested on
a Wheezy system with tor 0.2.4.x from deb.t.o and obfsproxy from
wheezy-backports.

My next step will be to write an AppArmor profile for obfsproxy, and
have it shipped with the obfsproxy package.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

From 59cbd65d849f8254957682a6875a51157141d681 Mon Sep 17 00:00:00 2001
From: intrigeri intrig...@boum.org
Date: Mon, 17 Feb 2014 12:40:11 +
Subject: [PATCH] AppArmor: allow running obfsproxy under its own profile if
 available, else unconfined.

---
 debian/tor.apparmor-profile.abstraction | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/tor.apparmor-profile.abstraction b/debian/tor.apparmor-profile.abstraction
index d680215..f3aef3c 100644
--- a/debian/tor.apparmor-profile.abstraction
+++ b/debian/tor.apparmor-profile.abstraction
@@ -22,3 +22,5 @@
 
   /etc/tor/* r,
   /usr/share/tor/** r,
+
+  /usr/bin/obfsproxy PUx,
-- 
1.9.0.rc3

Bug#737938: BUG: unable to handle kernel paging request at 000008000000001c

2014-02-17 Thread Stephen Powell

After replacing the bad memory and reinstalling Debian from scratch, I have had 
no further
problems.  I am assuming that the symptoms of this bug report were caused by 
the bad
memory.  You may close this bug report at your convenience.

I've made a new friend: memtest86+, which I will use on all systems with 
non-ECC memory
from now on.  Thanks for the tip!

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


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

Bug#738909: More on this Problem

2014-02-17 Thread Debian Live user

This was the second time apt-get upgrade placed packages from
experimental (when I am using Sid). The first time, I noticed in time
and stopped it (always run -s  first!). This time, I did not notice.

So it placed several experimental packages include libc6-2.18.

System was bootable with this. A terminal session had 3.5.4 instead of
machine name/path but worked fine. KDE konsole sessions functioned
normally.

Network was not working, suspected this package, attempted to force
downgrade an accidentally installed the lib6-2.17-udeb (normal packages
was on lintian or something). This killed any bash or sh. The 2.18
package had nothing to do with the network. System was now unbootable.

Went to rescue CD, removed the udeb files from /lib/. Pointed
the /lib/ld-linux.so.2 to the   2.18 package on i386-gnu folder (this is
shown as on file list for the package but is not actually in its .gz!).
Results are the same, with or without this:

Attempt to chroot to the target could not run /bin/sh--bash
Reboot attempt could not run /sbin/init and oopsed out.

As everything appears in order, I am at whits end on how to restore my
system. Any help (email off list) would be greatly appreciated.

Title of the bug might be changed to Sporadic Update Attempted to
Experimental, Should be Sid.

Happened twice but no consistent way to reproduce. This was sent from
the live CD, no way to really test anything else.


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

Bug#699781: kFreeBSD/18 ?

retitle 699781 Support of firefox under Kfreebsd
thanks

Hello,

Is this bug still relevant or already fixed ?

Thanks
Sylvestre


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

Bug#739273: dibbler-client: segfaults in TAddrAddr::getValid

2014-02-17 Thread Tomasz Mrugalski

On 17.02.2014 12:33, Yann Droneaud wrote:
 Package: dibbler-client
 Version: 0.8.2-1
 Severity: normal
 
 Dear Maintainer,
 
 I'm no more able to restart dibbler-client, as soon as it start
 configuring the interface it segfault:
Thanks for this bug report. Although I'm no longer Debian package
maintainer, I'm author of the upstream software.

Can you please download the latest sources from github
(git clone git://github.com/tomaszmrugalski/dibbler.git)
and check if the bug is still there?

If possible, please build it with debugging enabled:
./configure --enable-debug
make

I'm planning on releasing 1.0.0RC2 very soon. If the bug is still
present, I can fix before RC2.

Thanks.

Tomek Mrugalski
Dibbler author


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

Bug#739282: RM: cameleon -- ROM; obsolete, RC-buggy

2014-02-17 Thread Stéphane Glondu

Package: ftp.debian.org
Severity: normal

According to http://home.gna.org/cameleon/news.en.html :
 Cameleon is not maintained any more. It has been splitted in various
 parts. Have a look at these separated projects:
  * Chamo
  * DBForge
  * Gtktop
  * OCamldiff
  * OCamldot
  * OCamlrss
  * OCamltop-Gtk

Cheers,

-- 
Stéphane


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

Bug#739281: provides sendfile() prototype (in sys/sendfile.h) but no sendfile symbol

2014-02-17 Thread Robert Millan

Package: libc0.1-dev
Severity: normal

Perhaps we could use emulated Linux-like sendfile() from Eric Wong. See:

On 17/02/2014 09:12, Eric Wong wrote:
 Robert Millan r...@debian.org wrote:
 If you can write a Linux-compatible sendfile() which uses BSD-ish 
 SYS_sendfile
 as backend, I guess they'll have no problem exporting a new symbol in glibc?
 After all, it's glibc who claims to provide it (via sys/sendfile.h).
 
 I emulate Linux sendfile on (non-Debian) FreeBSD that way in cmogstored.
 Feel free to grab the linux_sendfile() wrapper from cmogstored:
   http://bogomips.org/cmogstored.git/plain/http_get.c
 The linux_sendfile wrapper is trivial and I'm OK with relicensing from
 the existing GPLv3+ to any DFSG-approved license

-- 
Robert Millan


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

Bug#738975: libconfig-model-dpkg-perl: FTBFS with libev-perl and libtest-harness-perl

2014-02-17 Thread Dominique Dumont


Ack. I've already faced similar bugs with Config::Model. 

Currently, I cannot reproduce this issue on my system (even with 
libtest-harness-perl installed)

IIRC this problem was fixed in libconfig-model-perl 2.042 [1]. 
Could you check the version you're using ?

All the best

[1] 
https://github.com/dod38fr/config-model/commit/93f5df752629c2dc45653ecf9db8e5d0430580fb
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


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

Bug#726418: advi: Builds broken package from source: /usr/share/texmf/tex/latex/advi - /advi

2014-02-17 Thread Moritz Mühlenhoff

 Source: advi
 Version: 1.10.2-1
 Severity: serious
 
 When I rebuild advi from source using pbuilder, the resulting advi package
 has the TeX support files in /advi instead of
 /usr/share/texmf/tex/latex/advi.

This bug also affects stable. Rebuilding advi in stable breaks the builds of 
other packages. I think that would be a suitable fix for a Wheezy point update.

Proposed patch attached. Note that rebuilding the package with the fix also 
drops these two files from advi:

-/usr/share/texmf/tex/latex/advi/advi.hva
-/usr/share/texmf/tex/latex/advi/pgfsys-dvips.def

I'm not sure what's causing this, though.

Cheers,
Moritz
-- 
Moritz Mühlenhoff
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0 [.]
Fax : +49 421 22232-99

muehlenh...@univention.de
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876 
If the advi in Wheezy is rebuilt from source the package paths are
broken. Example: 

Before a rebuild: /usr/share/texmf/tex/latex/advi/superpose.sty
After a rebuild: ./advi/superpose.sty

This results in build failures in other packages, e.g. in
whizzytex which uses advi-annot.sty during build time.

Changed extracted from the 1.10.2-1 - 1.10.2-2 interdiff

diff -aur advi-1.10.2.orig/debian/advi.dirs advi-1.10.2/debian/advi.dirs
--- advi-1.10.2.orig/debian/advi.dirs	2011-10-21 16:44:45.0 +0200
+++ advi-1.10.2/debian/advi.dirs	2014-02-17 13:15:00.502285128 +0100
@@ -1,7 +1,7 @@
 etc/advi
 usr/bin
 usr/share/man/man1
-usr/share/texmf/tex
+usr/share/texmf/tex/latex/advi
 usr/share/lintian/overrides
 usr/share/doc/advi/manual
 
diff -aur advi-1.10.2.orig/debian/advi.install advi-1.10.2/debian/advi.install
--- advi-1.10.2.orig/debian/advi.install	2011-10-21 16:44:45.0 +0200
+++ advi-1.10.2/debian/advi.install	2014-02-17 13:15:00.502285128 +0100
@@ -4,4 +4,5 @@
 doc/scratch_write_splash.dvi	/usr/share/doc/advi
 doc/*.gif doc/pngs		/usr/share/doc/advi/manual
 doc/*.html doc/*.ps doc/*.pdf 	/usr/share/doc/advi/manual
 debian/lintian-overrides/advi	/usr/share/lintian/overrides
+tex/*.sty tex/*.eps 		/usr/share/texmf/tex/latex/advi
\ Kein Zeilenumbruch am Dateiende.
diff -aur advi-1.10.2.orig/debian/rules advi-1.10.2/debian/rules
--- advi-1.10.2.orig/debian/rules	2011-10-21 16:44:45.0 +0200
+++ advi-1.10.2/debian/rules	2014-02-17 13:03:24.430906573 +0100
@@ -24,6 +24,7 @@
 else
 	cd $(CURDIR)/debian/advi/usr/bin  mv -f advi.byt advi
 endif
+	rm -rf $(CURDIR)/debian/advi/advi
 
 override_dh_compress:
 	dh_compress --exclude=usr/share/doc/advi/splash.dvi

Bug#739283: live-build: uploading http://ftp.debian.org/debian//dists/jessie/main/installer-i386/current/images//netboot/debian-installer/i386/linux fails

2014-02-17 Thread Bernard Maynadier

Package: live-build
Version: 4.0~alpha31-1
Severity: important

The lb_build works fine with wheezy and sid; but fail whith jessie.

I can't make a live image with live installer or netinst

The problem is the same with live-build 3.0

May be not a bug of live-build but a file missing on ftp.debian.org !


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

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


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

Bug#739284: obfsproxy: Please include an AppArmor profile for confining obfsproxy

2014-02-17 Thread intrigeri

Package: obfsproxy
Version: 0.2.1-2
Severity: wishlist
Control: blocked -1 by 739279
Control: owner -1 intrig...@debian.org

Hi,

once the tor package is able to run obfsproxy even when AppArmor is
enabled (#739279), it will be running obfsproxy unconfined.

Adding an AppArmor profile for obfsproxy should be pretty easy.
https://trac.torproject.org/projects/tor/ticket/6996#comment:22 has
a draft one.

I'll probably take care of this some day.

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


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

Bug#739285: cmake is missing findlua 5.2

2014-02-17 Thread Mathieu Malaterre

Package: cmake
Version: 2.8.9-1

cmake is wheezy only provide the following two find packages:

$ dpkg -L cmake-data | grep -i lua
/usr/share/cmake-2.8/Modules/FindLua50.cmake
/usr/share/cmake-2.8/Modules/FindLua51.cmake

However lua5.2 is also present in debian wheezy.

Please add a findlua52.cmake;

ref:http://public.kitware.com/Bug/view.php?id=14224


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

Bug#712936: iceweasel: can't print to file in the $HOME folder

Hello Vincent,

I cannot reproduce this issue. Do you have more information on the bug ?
(error in the terminal for example) ?

Are you sure this is not trigger by one of your extensions ?

Thanks
S


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

Bug#439266: openbox: ToggleMaximizeHorz + ToggleMaximizeFull and gnome-terminal gets stuck maximized

Hey,

Could you please try to reproduce this issue with newer version of
gnome-terminal like 3.4.1.1-2 or 3.10.1-1 ?

thanks
regards
althaser

Bug#739287: remove gzio from compilation

2014-02-17 Thread Mathieu Malaterre

Package: imagevis3d

gzio should not be compiled:



gcc -c -fopenmp -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -fno-strict-aliasing -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -D_REENTRANT -Wall
-W -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL
-I/usr/include/qt4 -I. -I3rdParty/GLEW -IIO/3rdParty/boost
-IIO/3rdParty/zlib -IBasics -IIO/exception -I/usr/include/lua5.2
-I/usr/X11R6/include -I. -o Build/objects/gzio.o IO/gzio.c


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

Bug#739266: nmu: hdf5_1.8.8-9

Steffen Grunewald wrote, On 17/02/2014 14:03:
 Hi Gilles,
 
 nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran in 
 wheezy (closes: #739261)

 Are there plans to make libhdf5-serial-dev work again, aka #706044?

 I hadn't. But this is indeed a good opportunity to fix it as well. So
 the plan would be to upload to stable a fix for #706044 which would
 close #739266 by the way. Am I reading you correctly?
 
 If that could be done, we'd get rid of a quite nasty issue, indeed.
 (I still have no idea how #706044 could slip through during Wheezy
 freeze.)
 
 Thanks,
 
 Thank you - there are quite some people around who would be very happy!

Let's go this way then. It is currently building on my box. Then would
retitling this bug as pu: ... be sufficient?

_g.




signature.asc
Description: OpenPGP digital signature

Bug#738625: Bug #738625: wget: Unable to establish SSL connection.

2014-02-17 Thread Florian Zavatzki

Hi,

we ran into the same problem after the upgrade.
It seems to me as it is the same problem as described in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686837

When a --no-check-certificate call is done to a side where the hostname
mismatch the certificate name, the above error is produced. Doing the
request against the IP address instead of the hostname, everything works
without problems.

I have tested the behavior against our Apache servers. A workaround on
the Apache side is to add the requested hostname as ServerAlias to the
configuration.

Bye,
Florian





signature.asc
Description: OpenPGP digital signature

Bug#739292: RM: acfax [kfreebsd-amd64 kfreebsd-i386] -- ROM; ANAIS

2014-02-17 Thread Colin Tuckley

Package: ftp.debian.org
Severity: normal

The build dependancies for acfax have changed, it can now only be built on 
linux based systems not BSD based systems.


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

Bug#707851: Proposed changes on menu systems

2014-02-17 Thread Bill Allombert

On Sun, Feb 02, 2014 at 10:00:17PM +0900, Charles Plessy wrote:
 We should assume people's good faith on both sides.  Because a 
 counter-argument
 to yours would be that people will use the presence of the Debian menu in the
 Debian policy as a justification to file serious bugs on packages and bully
 maintainers to do a work that they do not want to contribute by themselves.

Filling such bugs with severity serious would be against policy with or without
the change, so this hypothetical is not particularly enlightening except to
disparage the effort of the people trying to keep a coherent menu in Debian.

In any case, it does not answer the objection.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


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

Bug#739266: nmu: hdf5_1.8.8-9

2014-02-17 Thread Adam D. Barratt


On 2014-02-17 13:27, Gilles Filippini wrote:

Steffen Grunewald wrote, On 17/02/2014 14:03:

Hi Gilles,

nmu hdf5_1.8.8-9 . ALL . stable . -m Rebuild with current gfortran 
in wheezy (closes: #739261)


Are there plans to make libhdf5-serial-dev work again, aka #706044?


I hadn't. But this is indeed a good opportunity to fix it as well. So
the plan would be to upload to stable a fix for #706044 which would
close #739266 by the way. Am I reading you correctly?


If that could be done, we'd get rid of a quite nasty issue, indeed.
(I still have no idea how #706044 could slip through during Wheezy
freeze.)


Thanks,


Thank you - there are quite some people around who would be very 
happy!


Let's go this way then.


I've not looked at the detail of the bug, but the metadata for #706044 
indicates that it affects the package in unstable as well. If that's 
correct then it needs to be fixed in unstable before considering a 
stable fix.


Regards,

Adam


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

Bug#739269: Please move libwayland-egl out of libegl1-mesa-drivers

2014-02-17 Thread Sjoerd Simons

On Mon, 2014-02-17 at 12:17 +0100, Emilio Pozuelo Monfort wrote:
 On 17/02/14 11:48, Sjoerd Simons wrote:
  Package: libegl1-mesa-drivers
  Severity: normal
  
  libwayland-egl has been included in the libegl1-mesa-drivers, which seems a 
  bit
  odd as it's an application library not a driver.
  
  Practically this causes an issue on systems where wayland is used but the
  EGL/GL stack isn't provided by mesa as applications using libwayland-egl 
  depend
  on libegl1-mesa-drivers which almost forcibly pulls in mesa.
 
 How would alternative implementations satisfy the dependency? Should we name 
 the
 package libwayland-egl1-mesa, and have the shlibs force a dependency on
 libwayland-egl1-mesa | libwayland-egl1-provider (or similar) ?

Yeah same as libegl1-mesa has | libegl1-x11 by its symbols file.
Attached is a patch that splits out the library in that way, but keeps
the library  pkg-config files as part of libegl1-mesa-dev 

-- 
Sjoerd Simons sjo...@debian.org
From 1eee70da2ea48d844fb09695b33a9391b043ff3b Mon Sep 17 00:00:00 2001
From: Sjoerd Simons sjo...@luon.net
Date: Mon, 17 Feb 2014 12:47:53 +0100
Subject: [PATCH] Install libwayland-egl in a seperate library package

---
 debian/changelog |  7 ++
 debian/control   | 36 
 debian/libegl1-mesa-drivers.install.linux.in |  4 
 debian/libwayland-egl1-mesa.install.in   |  4 
 debian/libwayland-egl1-mesa.symbols  |  5 
 5 files changed, 52 insertions(+), 4 deletions(-)
 create mode 100644 debian/libwayland-egl1-mesa.install.in
 create mode 100644 debian/libwayland-egl1-mesa.symbols

diff --git a/debian/changelog b/debian/changelog
index 94224fd..eb18369 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mesa (10.0.2-2) UNRELEASED; urgency=medium
+
+  * Install libwayland-egl in a seperate library package (libwayland-egl1-mesa)
+and provide a virtual libwayland-egl1 package (Closes: #739269).
+
+ -- Sjoerd Simons sjo...@debian.org  Mon, 17 Feb 2014 12:43:29 +0100
+
 mesa (10.0.2-1) experimental; urgency=low
 
   [ Maarten Lankhorst ]
diff --git a/debian/control b/debian/control
index 4577639..de02e96 100644
--- a/debian/control
+++ b/debian/control
@@ -308,6 +308,7 @@ Depends:
  ${misc:Depends},
  libegl1-mesa (= ${binary:Version}),
  libglapi-mesa (= ${binary:Version}),
+ libwayland-egl1-mesa (= ${binary:Version}),
 # for libllvmradeon
  libgl1-mesa-dri (= ${binary:Version}) [any-i386 any-amd64],
 Pre-Depends: ${misc:Pre-Depends}
@@ -320,6 +321,41 @@ Description: free implementation of the EGL API -- hardware drivers
  This package contains the drivers required for hardware accelerated rendering
  of EGL-based graphics libraries, such as OpenGL|ES and OpenVG.
 
+Package: libwayland-egl1-mesa
+Section: libs
+Architecture: linux-any
+Depends:
+ ${shlibs:Depends},
+ ${misc:Depends},
+ libegl1-mesa (= ${binary:Version})
+Recommends: libegl1-mesa-drivers
+Provides: libwayland-egl
+Conflicts: libwayland-egl1
+Replaces: libwayland-egl1
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
+Description: free implementation of the EGL API -- runtime
+ This package contains the EGL native platform graphics interface library.
+ EGL provides a platform-agnostic mechanism for creating rendering surfaces
+ for use with other graphics libraries, such as OpenGL|ES and OpenVG.
+ .
+ This package contains wayland specific interface for use with EGL.
+
+Package: libwayland-egl1-mesa-dbg
+Section: debug
+Priority: extra
+Architecture: linux-any
+Depends:
+ libwayland-egl1-mesa (= ${binary:Version}),
+ ${misc:Depends},
+Multi-Arch: same
+Description: free implementation of the EGL API -- debugging symbols
+ This package contains the EGL native platform graphics interface library.
+ EGL provides a platform-agnostic mechanism for creating rendering surfaces
+ for use with other graphics libraries, such as OpenGL|ES and OpenVG.
+ .
+ This package contains the debugging symbols for the wayland EGL library.
+
 Package: libegl1-mesa-drivers-dbg
 Section: debug
 Priority: extra
diff --git a/debian/libegl1-mesa-drivers.install.linux.in b/debian/libegl1-mesa-drivers.install.linux.in
index 2c4c266..741f962 100644
--- a/debian/libegl1-mesa-drivers.install.linux.in
+++ b/debian/libegl1-mesa-drivers.install.linux.in
@@ -1,6 +1,2 @@
 # OS-independent part (from libegl1-mesa-drivers.install.in):
 dri/usr/lib/${DEB_HOST_MULTIARCH}/egl/egl_gallium.so usr/lib/${DEB_HOST_MULTIARCH}/egl
-
-# Wayland support, only on Linux:
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libwayland-egl.so.1 usr/lib/${DEB_HOST_MULTIARCH}
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libwayland-egl.so.1.0.0 usr/lib/${DEB_HOST_MULTIARCH}
diff --git a/debian/libwayland-egl1-mesa.install.in b/debian/libwayland-egl1-mesa.install.in
new file mode 100644
index 000..1937dc6
--- /dev/null
+++ b/debian/libwayland-egl1-mesa.install.in
@@ -0,0 +1,4 @@
+# Wayland support, only on Linux:

Bug#445513: interesting race condition with mutex logins

Hey Trent,

Could you please try to reproduce this issue with newer version of
gnome-terminal like 3.4.1.1-2 or 3.10.1-1 ?

thanks
regards
althaser

Bug#739085: systemd: run update-binfmts --disable via ExecStop=

2014-02-17 Thread Michael Biebl

Am 15.02.2014 21:13, schrieb Colin Watson:
 On Sat, Feb 15, 2014 at 08:12:45PM +0100, Michael Biebl wrote:
 I noticed that the SysV init script runs
 update-binfmts --disable on stop
 
 The systemd service doesn't though.
 Is this difference in behaviour deliberate or should we
 also run disable on stop in the service file?
 
 This could be done via

 ExecStop=/usr/sbin/update-binfmts --disable
 
 It's an interesting question.  If you look closely at the sysvinit
 script, you'll see that it does define a stop action, but there's no
 Default-Stop; that means you can stop it manually if you want to, but it
 doesn't slow down shutdown by doing unnecessary work.
 
 Is there a way to achieve a similar effect with systemd?  I haven't been
 able to find one by looking through the manual pages.

Yeah, this is possible.
binfmt-support.service uses DefaultDependencies=yes (the default value).

Aside from a set of orderings and dependencies this also adds
Conflicts=shutdown.target. See

# systemctl -p Conflicts show binfmt-support.service

This ensures, whenever the shutdown.target is activated, that unit is
stopped.

If you want to see which units will be stopped if you enter the shutdown
target, run

# systemctl -p ConflictedBy show shutdown.target

By using DefaultDependencies=no, you have more fine-grained control over
which dependencies and orderings are added to your service.
Usually, that property should only be used for early boot services,
though [1].

You also need to make sure to specify your dependencies/orderings
explictly now.

Untested:

[Unit]
Description=Enable support for additional executable binary formats
Documentation=man:update-binfmts(8)
DefaultDependencies=no
After=local-fs.target proc-sys-fs-binfmt_misc.automount

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/update-binfmts --enable
ExecStop=/usr/sbin/update-binfmts --disable
Restart=no

[Install]
WantedBy=multi-user.target

 (The stop action is mostly a nicety, so if this isn't achieveable, I
 think it would be better to omit ExecStop rather than slowing down
 shutdown.)

The combination of multi-user.target and DefaultDependencies=no is a bit
odd and if it's worth adding that, I'll leave to your discretion.


I've CCed the pkg-systemd-maintainers mailing list since I think this
issue is interesting enough for a wider audience.

Regards,
Michael


[1] man 5 systemd.unit
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#549553: closing 549553 bug

Version: 3.10.1-1

I'm closing this bug since now its called hidden already.

thanks
regards
althaser

Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch

2014-02-17 Thread GCS

Hi Markus,

On Fri, Jan 31, 2014 at 11:20 AM, Markus Hoenicka
markus.hoeni...@mhoenicka.de wrote:
 Am 2014-01-31 10:48, schrieb László Böszörményi:
 On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka
 markus.hoeni...@mhoenicka.de wrote:
 Problem is that I'm not aware of similar limits for floats. Do you
 know where to get this info from at compile time?
  Attached a sample. Basically those are: FLT_MAX, DBL_MAX and LDBL_MAX.
 Ah, I see. I'll see if I can come up with a fixed testkit.
 Any progress? More than two weeks passed. I may just disable those
problematic tests as libdbi-drivers itself works as expected.

Regards,
Laszlo/GCS


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

Bug#736618: [ia64][patch] iceweasel-24.2.0esr-1 Web browsing simply doesn't work

Hello,

As you probably know, ia64 is no longer part of the maintained
architecture in Debian.
So, I am not sure we want to put too much effort in the ia64 package.

However, I see two solutions:
* you prepare the patch for the 24 package and the maintainer might
include it.
* you use a more recent version of firefox:
http://mozilla.debian.net/

Sorry,
Sylvestre


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

Bug#739293: RFP: dudle -- privacy-enhanced web-based event scheduling

2014-02-17 Thread IOhannes m zmoelnig

Package: wnpp
Severity: wishlist

* Package name: dudle
  Upstream Author : Benjamin Kellermann benjamin.kellerm...@gmx.de
* URL : https://dudle.inf.tu-dresden.de
* License : AGPL
  Programming Lang: Ruby
  Description : privacy-enhanced web-based event scheduling

 Dudle is an online scheduling application. It allows to schedule events (e.g.
 schedule a TelCo, meeting etc.) or to conduct small polls (e.g. find out which
 sort of coffee some people like the most).
 .
 Unlike most other similar applications, Dudle offers enhanced access control
 settings, which minimizes trust assumptions into the polling server. Users can
 configure their poll, depending on whom they trust. Trust scenarios, which are
 covered by the prototype are:
  + trust in all participants of the group
  + trust in the poll initiator only
  + minimal trust in all parties


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

Bug#738915: pd-aubio: FTBFS on non-linux

2014-02-17 Thread Paul Brossier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tags 738915 patch
thanks
- --

attached is a patch to fix this. i will upload it in a few days. please
NMU if need be.

thanks, Paul

On 13/02/2014 18:27, Julien Cristau wrote:
 Source: pd-aubio Version: 0.4-1 Severity: serious Justification: 
 fails to build from source
 
 The pd-aubio package used to be built from aubio source on all 
 architectures.  Now it's moved to its own source package, which 
 FTBFS on non-linux: 
 https://buildd.debian.org/status/package.php?p=pd-aubio
 
 Please either get this to build or reassign (and downgrade) this
 bug to ftp.debian.org to get the out of date pd-aubio binaries
 removed.
 
 Thanks, Julien
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMCE/EACgkQkuC958YALL3dqwCfVHROyXmWw44C7ZqG1clI9pSY
MTEAoLLD/ngJ8aaH/f7zHKDQr1KmmS2K
=mpn5
-END PGP SIGNATURE-
diff --git a/wscript b/wscript
index 51124f6..186d408 100644
--- a/wscript
+++ b/wscript
@@ -36,7 +36,11 @@ def configure(ctx):
 ctx.env.CFLAGS_cshlib = []
 ctx.env.LINKFLAGS_cshlib +=  ['-export_dynamic', '-lpd']
 else:
-ctx.fatal(Sorry, i don't know how to build for %s yet % 
ctx.env['DEST_OS'])
+ctx.start_msg(Checking for platform)
+ctx.end_msg(no idea how to build for %s yet, assuming linux
+% ctx.env['DEST_OS'], 'YELLOW')
+ctx.env.cshlib_PATTERN = '%s.pd_linux'
+ctx.env.LINKFLAGS_cshlib += ['--export_dynamic']
 
 # check for puredata header
 ctx.check(header_name='m_pd.h')


assume_linux.patch.sig
Description: Binary data

Bug#559238: gnome-terminal: Scrollback buffer size miscalculated.

Hey Philipp,

Could you please try to reproduce this issue with newer gnome-terminal
version ?

thanks
regards
althaser

Bug#739294: pulseaudio: should ship a bug script to collect system and config information

Package: pulseaudio
Version: 4.0-6
Severity: normal

Since reporting bugs about pulseaudio being silent seems to be
problematic due to lack of reproducability (may require same hardware
and software setup) and lack of other information, I'd suggest to add a
bug-script to the pulseaudio packages that tries to collect as much
information as possible about the system and configuration to help the
maintainers debug these problems.

As I'm absolutely clueless about sound (so far it works, I don't care
whether I'm using alsa or pulseaudio or whatever), I don't know at all
what this information could be.

See /usr/share/doc/reportbug/README.developers.gz and dh_bugfiles(1) for
more information.


Andreas


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

Bug#712936: iceweasel: can't print to file in the $HOME folder

2014-02-17 Thread Vincent Lefevre

Control: retitle -1 iceweasel: when printing to file to latest (default) Save 
folder, tmp PDF file is unlinked without being copied to this folder

On 2014-02-17 14:08:15 +0100, Sylvestre Ledru wrote:
 I cannot reproduce this issue. Do you have more information on the bug ?
 (error in the terminal for example) ?

No errors in the terminal, but the behavior has slightly changed:
the last Save folder is now remembered. If I print to file without
changing the Save folder, everything seems fine, but the PDF file
doesn't appear in this folder. For instance:

0. Default Save folder is A.
1. I print to file, without changing the Save folder.
   - The file doesn't appear in A.
2. I print to file, changing the Save folder to B.
   - The file appears in B. OK.
3. I remove the file from B.
4. I print to file, without changing the Save folder.
   - The file doesn't appear in B.
5. I print to file, changing the Save folder to A.
   - The file appears in A. OK.
6. I remove the file from A.
7. I print to file, without changing the Save folder.
   - The file doesn't appear in A.

I'm wondering whether this is a bug in iceweasel, because there
was no major upgrade recently. Perhaps a bug in some gtk library
(the one that provides the print feature?). I'm wondering whether
I could test with another gtk2 application that uses the print
feature.

This may be a problem related to how the Save folder is remembered.
Perhaps it is OK in the dialog box, but it is not remembered
correctly for the save operation.

 Are you sure this is not trigger by one of your extensions ?

I've just done the test with a new profile (so, no extensions except
DOM Inspector), and I can still reproduce the bug.

I can see a difference in the strace -f output. Below, the write
corresponds to the generation of the PDF file, apparently in some
temporary file under /tmp (see 3rd line of each trace).

When I changed the Save folder to home:

[...]
1551  write(77, %EOF\n, 5)= 5
1551  close(77) = 0
1551  open(/tmp/G2KGBX.tmp, O_RDONLY) = 77
1551  fstat(77, {st_mode=S_IFREG|0600, st_size=68049, ...}) = 0
1551  lseek(77, 0, SEEK_SET)= 0
1551  open(/home/vlefevre/mozilla.pdf, O_WRONLY|O_CREAT|O_EXCL, 0666) = 78
[...]

When I do not change the Save folder:

[...]
1476  write(42, %EOF\n, 5)= 5
1476  close(42) = 0
1476  open(/tmp/CCRDBX.tmp, O_RDONLY) = 42
1476  fstat(42, {st_mode=S_IFREG|0600, st_size=70156, ...}) = 0
1476  lseek(42, 0, SEEK_SET)= 0
1476  stat(/tmp/CCRDBX.tmp, {st_mode=S_IFREG|0600, st_size=70156, ...}) = 0
1476  lstat(/tmp/CCRDBX.tmp, {st_mode=S_IFREG|0600, st_size=70156, ...}) = 0
1476  unlink(/tmp/CCRDBX.tmp) = 0
1476  close(42) = 0
[...]

i.e. the temporary PDF file is removed without an attempt to copy
it to the Save folder first!

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/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#683464: iceweasel: FTBFS on m68k due to invalid alignment assumptions

Hello Thorsten,

Did you had the chance to refresh this patch against the current release
of Iceweasel ?

Thanks,
Sylvestre


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

Bug#717484: alternative workaround for Akregator does not update feeds, reports Networking is not available

2014-02-17 Thread Mathieu ROY

Hello,

I have the same issue with Akregator.
 
  $ qdbus org.kde.kded /modules/networkstatus networks 
ntrack
  $ qdbus org.kde.kded /modules/networkstatus status
1

With current testing version, I tried the workaround
  $ qdbus org.kde.kded /modules/networkstatus setNetworkStatus SolidNetwork 
4

but Akregator still reported Network is not available and
   $ qdbus org.kde.kded /modules/networkstatus status
1

Reading https://bugs.archlinux.org/task/28850 I found an alternative command 
that actually works:

  $ qdbus org.kde.kded /modules/networkstatus 
org.kde.Solid.Networking.setNetworkStatus ntrack 4
  $ qdbus org.kde.kded /modules/networkstatus status
4


https://bugs.kde.org/show_bug.cgi?id=226022#c11 provides some insights about 
it and a general web search about org.kde.kded /modules/networkstatus ntrack 
does not look so good (many KDE apps having the same problem that all seems to 
pinpoint to this ntrack). Let's hope they'll fix that upstream.

Regards,


-- 
http://yeupou.wordpress.com/


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

Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch

2014-02-17 Thread Markus Hoenicka


Am 2014-02-17 15:13, schrieb László Böszörményi:

Hi Markus,

On Fri, Jan 31, 2014 at 11:20 AM, Markus Hoenicka
markus.hoeni...@mhoenicka.de wrote:

Am 2014-01-31 10:48, schrieb László Böszörményi:

On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka
markus.hoeni...@mhoenicka.de wrote:

Problem is that I'm not aware of similar limits for floats. Do you
know where to get this info from at compile time?
 Attached a sample. Basically those are: FLT_MAX, DBL_MAX and 
LDBL_MAX.

Ah, I see. I'll see if I can come up with a fixed testkit.

 Any progress? More than two weeks passed. I may just disable those
problematic tests as libdbi-drivers itself works as expected.

Regards,
Laszlo/GCS


Hi,

there is some progress, but it's not suitable for general use yet. The 
revised testkit works ok on Debian including valgrind checks but still 
shows some differences between values returned from the drivers and 
expected values. This just takes some more time to fix. Problem is that 
it causes a bus error on FreeBSD which I cannot reproduce using 
valgrind, and gdb couldn't enlighten me about what is wrong. Therefore I 
suggest to disable the tests for the time being. As you mentioned, these 
are not libdbi or libdbi-drivers problems, but testkit problems.


regards,
Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


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

Bug#739295: python3-dbus: rebuild required for python 3.4

2014-02-17 Thread Tom Marble

Package: python3-dbus
Version: 1.2.0-2+b1
Severity: wishlist

Dear Maintainer,

The recent upload of python 3.4 to experimental causes
this library to fail with _dbus_bindings not found.

Please consider rebuilding this library before
python 3.4 hits unstable.

--Tom

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

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

Versions of packages python3-dbus depends on:
ii  libc6 2.17-97
ii  libdbus-1-3   1.8.0-1
ii  libdbus-glib-1-2  0.102-1
ii  libglib2.0-0  2.38.2-5
ii  python3   3.4~rc1-1
pn  python3:any   none

Versions of packages python3-dbus recommends:
ii  python3-gi  3.10.2-2

Versions of packages python3-dbus suggests:
pn  python-dbus-doc   none
pn  python3-dbus-dbg  none

-- 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#739296: python3-gi: rebuild required for python 3.4

2014-02-17 Thread Tom Marble

Package: python3-gi
Version: 3.10.2-2
Severity: wishlist

Dear Maintainer,

The recent upload of python 3.4 to experimental causes
this library to fail with ImportError: No module named 'gi._gi'.

Please consider rebuilding this library before
python 3.4 hits unstable.

--Tom

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

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

Versions of packages python3-gi depends on:
ii  gir1.2-glib-2.01.36.0-2+b1
ii  libc6  2.17-97
ii  libffi63.0.13-12
ii  libgirepository-1.0-1  1.36.0-2+b1
ii  libglib2.0-0   2.38.2-5
ii  multiarch-support  2.17-97
ii  python33.4~rc1-1
pn  python3:anynone

python3-gi recommends no packages.

python3-gi 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#625762: --geometry causes additional characters in terminal

Hey,

Could you please try to reproduce this with newer version of gnome-terminal
like 3.4.1.1-2 or 3.10.1-1 ?

I couldn't reproduce it with 3.10.1-1.

thanks
regards
althaser

Bug#738774: doublecmd-common: often sigsegv after changing theme/window decorations in xfce

2014-02-17 Thread Graham Inggs


Hi Svein

I haven't been able to reproduce your problem yet.

Can you attach a backtrace from the doublecmd-gtk package as well please?
Also, please install the doublecmd-*-dbg package, as appropriate.

Regards
Graham


On 12/02/2014 22:29, Svein Engelsgjerd wrote:

Package: doublecmd-common
Version: 0.5.8-1
Severity: important

Dear Maintainer,

After updating debian jessie with the latest doublecmd I more often than before 
experience that doublecmd exits without warning.
I run xfce configured on three monitors (each monitor is a separate x screen).

After starting doublecmd and changing themes in xfce or even just the window 
decorations doublecmd sigsegv's sometimes.
Not very hard to reproduce, will eventually crash after some time e.g. the 
crash can be repeated.
I tried both the gtk and qt version of doublecmd but I can't tell any 
difference. Same thing happens.
Restarting doublecmd resolves the issue.




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

Bug#739297: python-glpk: import glpk does not work: shared library cannot be found

2014-02-17 Thread Ralf Jung

Package: python-glpk
Version: 0.4.52-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

the glpk module does not work. If I run import glpk, I get

$ python
Python 2.7.6 (default, Jan 11 2014, 14:34:26) 
[GCC 4.8.2] on linux2
Type help, copyright, credits or license for more information.
 import glpk
Traceback (most recent call last):
  File stdin, line 1, in module
ImportError: libglpk.so.0: cannot open shared object file: No such file or 
directory

I tried re-building the package locally, to no avail.

Kind regards
Ralf

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

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

Versions of packages python-glpk depends on:
ii  libc6   2.17-97
ii  libglpk36   4.52.1-2
ii  python  2.7.5-5
ii  python-ply  3.4-3

python-glpk recommends no packages.

python-glpk 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#712936: iceweasel: can't print to file in the $HOME folder

On 17/02/2014 15:32, Vincent Lefevre wrote:
 Control: retitle -1 iceweasel: when printing to file to latest (default) Save 
 folder, tmp PDF file is unlinked without being copied to this folder

 On 2014-02-17 14:08:15 +0100, Sylvestre Ledru wrote:
 I cannot reproduce this issue. Do you have more information on the bug ?
 (error in the terminal for example) ?
 I'm wondering whether this is a bug in iceweasel, because there
 was no major upgrade recently. Perhaps a bug in some gtk library
 (the one that provides the print feature?). I'm wondering whether
 I could test with another gtk2 application that uses the print
 feature.
OK. Your guess is probably right.
Trying with both upstream 29 (currently, aurora: an  'alpha' release)
and iceweasel 24

29 does not show the bug, 24 shows it.

Mike, correct me if I am wrong but, AFAIK, iceweasel is using the
libraries provided by Debian while
upstream ships patched versions of upstream libraries.

Sylvestre


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

Bug#739183: R: Bug#739183: spring: suggested package libtxc-dxtn0 is now recommended by libgl1-mesa-dri

2014-02-17 Thread Fabio Pedretti

Messaggio originale
Da: vch...@debian.org
Data: 17/02/2014 8.28
A: Markus Koschanya...@gambaru.de
Cc: 739...@bugs.debian.org
Ogg: Bug#739183: spring: suggested package libtxc-dxtn0 is now recommended by 
libgl1-mesa-dri

On Sun, Feb 16, 2014 at 7:43 AM, Markus Koschany a...@gambaru.de wrote:
 Package: spring
 Version: 96.0+dfsg-1
 Severity: normal


 I have received a private e-mail about this issue. Just so that it
 won't get lost, I'm quoting the original e-mail here as a reminder for
 the next revision.

 Hi, thanks for updating debian spring package!

 Can you remove the suggest of libtxc-dxtn0 ? It was already
 recommended by libgl1-mesa-dri in the meantime, and it's useful only with 
mesa
 drivers, not the proprietary ones. Also no other game needing it suggests 
it, since
 it's already implied by mesa.

libtxc-dxtn0 isn't even in Debian proper (patent-encumbered by an
active patent, and thus only available on marillat's deb-multimedia
repo); closest thing we have in Debian is libtxc-dxtn-s2tc0
(src:s2tc), but I digress...spring shouldn't be directly suggesting
either package.


libtxc-dxtn0 is a virtual package provided by libtxc-dxtn-s2tc0.

I am the original reporter, BTW.

Fabio


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

Bug#724282: New release 2.1.5

2014-02-17 Thread Cedric Jeanneret

Hello,

It would be great if the new release 2.1.5 could be included in some backports 
(at least)… It would prevent people to get some personal repository with 
possible old release… As sphinxsearch provides packages for stable and 
old-stable, it shouldn't be long to insert them (though I'm pretty sure other 
arch would also be glad to get the newest release).

Cheers,

C.


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

Bug#739266: nmu: hdf5_1.8.8-9