Bug#722055: python-openssl: CVE-2013-4314: hostname check bypassing vulnerability
Package: python-openssl Version: 0.13-2+b2 Severity: important Tags: security, fixed-upstream https://mail.python.org/pipermail/pyopenssl-users/2013-September/000478.html In all prior releases, the string formatting of subjectAltName X509Extension instances incorrectly truncated fields of the name when encountering NUL. String formatting of this extension will now include the NUL byte (escaped) and any following bytes. Additionally, a bug causing memory to be leaked for each call to X509.get_extension has been fixed. References: https://bugzilla.redhat.com/show_bug.cgi?id=1005325 Please adjust affected version numbers accordingly. --- Henri Salo signature.asc Description: Digital signature
Bug#100808: This is for your Information.
This is for your Information. We wish to notify you again that you were listed as a beneficiary in the intent of the deceased . Please provide your contact details while replying to enable us process the release of the Inheritance in your name. Full details will be sent in our next email to you. Yours faithfully, Jude McKinney. -- Esta mensagem foi verificada pelo sistema de antivirus e acredita-se estar livre de perigo. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722056: mricron: Render Save as bitmap does not work in the current version
Package: mricron Severity: normal Dear Michael, just got one of my users to report that mricron Render-Save as bitmap does not work properly anymore in the neurodebian mricron. There is however, a new mricron available in which all seeems well again: http://www.nitrc.org/frs/download.php/5627/lx64.zip/?i_agree=1 That would be the 06/2013 version as opposed to the 05/2012 version. BTW this problem started to happen when we moved from deb. squeeze to wheezy. Best regards and have a nice weekend, Vincent -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mricron depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libpango1.0-0 1.30.0-1 ii libx11-62:1.5.0-1+deb7u1 ii mricron-data0.20120505.1~dfsg.1-1 mricron recommends no packages. Versions of packages mricron suggests: ii fsl 5.0.4-3~nd70+1 ii fsl-5.0-core [fsl] 5.0.4-3~nd70+1 ii mricron-doc 0.20120505.1~dfsg.1-1 -- De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. Het Universitair Medisch Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W. (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197. Denk s.v.p aan het milieu voor u deze e-mail afdrukt. -- This message may contain confidential information and is intended exclusively for the addressee. If you receive this message unintentionally, please do not use the contents but notify the sender immediately by return e-mail. University Medical Center Utrecht is a legal person by public law and is registered at the Chamber of Commerce for Midden-Nederland under no. 30244197. Please consider the environment before printing this e-mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721582: transition: xbae
On 09/06/2013 06:37 PM, Nicholas Breen wrote: On Thu, Sep 05, 2013 at 11:42:55PM +0200, Julien Cristau wrote: On Sun, Sep 1, 2013 at 20:16:20 -0700, Nicholas Breen wrote: I'd like to launch a very small transition for an ABI bump in src:xbae, which does have a renamed package (libxbae4 - libxbae4m). This is a sub-dependency of the openmotif transition, #708462. It should affect only three leaf packages: * paw and geant321 will need binNMUs [...] That sounds fine. Please ping this bug when xbae is built everywhere and the binNMUs have to be scheduled. xbae is now built and installed on all architectures. binNMUs are scheduled. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706798: transition: Libav 9
On 09/06/2013 02:37 PM, Sebastian Ramacher wrote: On 2013-09-04 18:57:17, Julien Cristau wrote: On Wed, Sep 4, 2013 at 17:31:34 +0200, Moritz Mühlenhoff wrote: I've successfully rebuild acoustid-fingerprinter 0.6-1 against libav9. Can you trigger a binNMU? On Wed, Sep 4, 2013 at 17:47:29 +0200, Sebastian Ramacher wrote: kid3 also builds successfully. Could binNMUs for it be scheduled too? Both scheduled. Thank you. Could you also schedule binNMUs for vdr-plugin-xineliboutput please? Scheduled. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721356: transition: telepathy-logger
On 09/07/2013 01:04 AM, Laurent Bigonville wrote: Hi, Hi I've just uploaded telepathy-logger 0.8.0-2 in unstable. Could you please start the binNMU for the level 1 (empathy, gnome-shell and telepathy-logger-qt). They have been scheduled. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706798: transition: Libav 9
On 09/06/2013 04:03 PM, Sebastian Ramacher wrote: The binNMUs for performous failed on ia64, mips(el) and s390(x) due to #721577. Could they be given back please? On mips(el) boost 1.54.0-3 is not yet installed, so a dep-wait is needed there. given back and dep-wait set. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720814: Bug#706798: transition: Libav 9
On 09/06/2013 05:06 PM, Moritz Mühlenhoff wrote: Sebastian Ramacher sramac...@debian.org schrieb: #720814 motion Scheduled for removal from testing. Since libav dropped the (transitional?) ffmpeg package, we have some more packages that need to be ported / fixed: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=3Dffmpeg-removal;users=3Dp= kg-multimedia-maintain...@lists.alioth.debian.org avbin should be removed from testing as well. Only a single maintainer upload back in 2009 and only driven by NMUs since then. Also no revdeps and marginal popcon. As avbin is in the deferred queue fixing its RC bugs, it can stay for now. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716994: transition: kdevelop 4.5
Hi, all four sources have been successfully uploaded to unstable. Greetings, Andreas
Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]
Package: libdspam7-drv-hash Version: 3.10.1+dfsg-11 Severity: grave Justification: causes non-serious data loss Sample of dmesg: [1701173.909095] dspam[15582]: segfault at 7f8c2197acf8 ip 7f8c1ea8f69a sp 7f8c1cbe9048 error 4 in libhash_drv.so.7.0.0[7f8c1ea8b000+6000] [1775508.341567] cssclean[25298]: segfault at 7f9b7086a000 ip 00403b5b sp 7fff7d456130 error 7 in cssclean[40+c000] [1785820.256253] dspam[8177]: segfault at 7ff586ffe2f8 ip 7ff58dd4169a sp 7ff58cd35048 error 4 in libhash_drv.so.7.0.0[7ff58dd3d000+6000] [1785862.479249] dspam[8243]: segfault at 7fa456fa62f8 ip 7fa457fac69a sp 7fa4577a1048 error 4 in libhash_drv.so.7.0.0[7fa457fa8000+6000] [1785888.517082] dspam[8281]: segfault at 7fef8160c2f8 ip 7fef8261269a sp 7fef81e07048 error 4 in libhash_drv.so.7.0.0[7fef8260e000+6000] [1786011.902307] dspam[8760]: segfault at 7f8a051752f8 ip 7f8a0617b69a sp 7f8a06171048 error 4 in libhash_drv.so.7.0.0[7f8a06177000+6000] I happened to be in a situation where I can't even fully flush the postfix queue without having Dspam to segfault. I end up installing dspam-dbg and gdb and attach to the process [I wasn't able to run the process without the init-script]. Here is a stack trace, but sadly libdspam7-drv-hash does not provide debug symbols. (gdb) bt #0 0x7ff5afdc369a in _hash_drv_seek () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so #1 0x7ff5afdc3a19 in _hash_drv_get_spamrecord () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so #2 0x7ff5afdc3a90 in _ds_get_spamrecord () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so #3 0x7ff5afdc3cfd in _ds_getall_spamrecords () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so #4 0x7ff5b28422f6 in _ds_operate () from /usr/lib/x86_64-linux-gnu/libdspam.so.7 #5 0x7ff5b2842e90 in dspam_process () from /usr/lib/x86_64-linux-gnu/libdspam.so.7 #6 0x0040bad7 in process_message (ATX=ATX@entry=0xd58e90, message=message@entry=0xd5aa10, username=username@entry=0xd584e0 testabcd...@orange.fr, result_string=result_string@entry=0x7ff5afdbc348) at dspam.c:540 #7 0x0040ce4d in process_users (ATX=ATX@entry=0xd58e90, message=message@entry=0xd5af10) at dspam.c:1882 #8 0x0040faa0 in process_connection (ptr=0xd56f80) at daemon.c:738 #9 0x7ff5b2621b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x7ff5b236ba7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x in ?? () (gdb) bt full #0 0x7ff5afdc369a in _hash_drv_seek () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so No symbol table info available. #1 0x7ff5afdc3a19 in _hash_drv_get_spamrecord () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so No symbol table info available. #2 0x7ff5afdc3a90 in _ds_get_spamrecord () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so No symbol table info available. #3 0x7ff5afdc3cfd in _ds_getall_spamrecords () from /usr/lib/x86_64-linux-gnu/dspam/libhash_drv.so No symbol table info available. #4 0x7ff5b28422f6 in _ds_operate () from /usr/lib/x86_64-linux-gnu/libdspam.so.7 No symbol table info available. #5 0x7ff5b2842e90 in dspam_process () from /usr/lib/x86_64-linux-gnu/libdspam.so.7 No symbol table info available. #6 0x0040bad7 in process_message (ATX=ATX@entry=0xd58e90, message=message@entry=0xd5aa10, username=username@entry=0xd584e0 testabcd...@orange.fr, result_string=result_string@entry=0x7ff5afdbc348) at dspam.c:540 CTX = 0xd96700 components = optimized out copyback = optimized out have_signature = optimized out result = optimized out i = optimized out internally_canned = 0 -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdspam7-drv-hash depends on: ii libc6 2.13-38 ii libdspam7 3.10.1+dfsg-11 libdspam7-drv-hash recommends no packages. libdspam7-drv-hash 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#712956: marked as done (0ad: seems to use CPU features not available everywhere)
reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721696: closed by Michael Biebl bi...@debian.org (Bug#721696: fixed in gedit-plugins 3.8.3-2)
Thanks, Michael. Confirmed fixed in 3.8.3-2 amd64 on sid. Much appreciated. Kind regards, -- Ben Caradoc-Davies b...@wintersun.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] Regards, Vincent [1] http://trac.wildfiregames.com/ticket/1994#comment:5 [2] https://code.google.com/p/nvidia-texture-tools/issues/detail?id=188 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722058: kde-config-touchpad: reports errors and tapping doesn't work with xserver-xorg-input-synaptics 1.7.1 in unstable
Package: kde-config-touchpad
Version: 0.8.1-1
Severity: important
Tapping doesn't work any longer, the kcm-module segfaults, .xsessions-errors
contains the following lines:
Traceback (most recent call last):
File /usr/bin/synaptikscfg, line 9, in module
load_entry_point('synaptiks==0.8.1', 'console_scripts', 'synaptikscfg')()
File /usr/lib/python2.7/dist-packages/synaptiks/config.py, line 460, in main
driver_defaults.save(get_touchpad_defaults_file_path())
File /usr/lib/python2.7/dist-packages/synaptiks/config.py, line 281, in save
save_json(filename, dict(self))
File /usr/lib/python2.7/dist-packages/synaptiks/config.py, line 248, in
__getitem__
value = getattr(self.touchpad, key)
File /usr/lib/python2.7/dist-packages/synaptiks/touchpad.py, line 106, in
__get__
values = obj[self.property_name]
File /usr/lib/python2.7/dist-packages/synaptiks/x11/input.py, line 552, in
__getitem__
atom = _get_property_atom(self.display, name)
File /usr/lib/python2.7/dist-packages/synaptiks/x11/input.py, line 180, in
_get_property_atom
raise UndefinedPropertyError(name)
synaptiks.x11.input.UndefinedPropertyError: u'Synaptics Circular Pad'
Reinhard
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11.0 (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/bash
Versions of packages kde-config-touchpad depends on:
ii libpython2.7-stdlib [python-argparse] 2.7.5-7
ii libxi6 2:1.7.2-1
ii python 2.7.5-4
ii python-kde44:4.10.5-1+b1
ii python-pkg-resources 0.6.49-2
ii python-pyudev 0.13-1
ii python-qt4 4.10.2-2
ii python2.7 2.7.5-7
Versions of packages kde-config-touchpad recommends:
ii libxtst6 2:1.2.2-1
ii python-dbus 1.2.0-2+b1
ii upower 0.9.21-3
kde-config-touchpad 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#711943: transition: openmpi
On Thu, Aug 15, 2013 at 09:56:07 +0200, Sylvestre Ledru wrote: On 13/08/2013 10:44, Julien Cristau wrote: Control: tag -1 confirmed On Tue, Jun 11, 2013 at 12:14:25 +0200, Sylvestre Ledru wrote: I would like to propose the transition of openmpi from version 1.4 = 1.6. Please go ahead. Excellent! It has just been uploaded! It doesn't seem to work on ia64, causing a number of build failures. Is there a way this can be resolved quickly? Cheers, Julien signature.asc Description: Digital signature
Bug#722060: non-free RFC material included in upstream tarball
Source: tarantool Version: 1.4.9+20130611.2012-1 Severity: serious Tags: sid jessie third_party/lua-cjson/rfc4627.txt is a RFC manual, bound to the following terms: http://trustee.ietf.org/license-info/ It is explicitly stated that it is not allowed to modify it, this fails DFSG #3. Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722059: Missing copyright holders
Source: tarantool Version: 1.4.9+20130611.2012-1 Severity: serious Tags: sid jessie Some copyright holders are not listed in copyright file: * third_party/memrchr.c: * Copyright (c) 2008 The NetBSD Foundation, Inc. * third_party/memmem.c: * Copyright (c) 2005 The NetBSD Foundation, Inc. * third_party/lua-cjson/g_fmt.c: * Copyright (c) 1991, 1996 by Lucent Technologies. * third_party/lua-cjson/g_fmt.c: * The author of this software is David M. Gay. * third_party/lua-cjson/rfc4627.txt: Copyright (C) The Internet Society (2006). * third_party/libeio/eio.c: * Copyright (c) 2007,2008,2009,2010,2011,2012 Marc Alexander Lehmann lib...@schmorp.de * third_party/libev/event_compat.h: * Copyright (c) 2000-2004 Niels Provos pro...@citi.umich.edu * third_party/libev/ev.c: * Copyright (C2A9) 2011 Emanuele Giaquinta * third_party/coro/conftest.c: * Copyright (c) 1999-2001 Ralf S. Engelschall r...@engelschall.com * src/rope.c: * Copyright (c) 1993-1994 by Xerox Corporation. All rights reserved. * test/lib/yapps/runtime.py:# Copyright 1999-2003 by Amit J. Patel am...@cs.stanford.edu * test/lib/yapps/runtime.py:# Enhancements copyright 2003-2004 by Matthias Urlichs sm...@debian.org * test/lib/yapps/runtime.py:# Copyright 1999-2003 by Amit J. Patel am...@cs.stanford.edu * test/lib/yapps/runtime.py:# Enhancements copyright 2003-2004 by Matthias Urlichs sm...@debian.org There can be more, of course. A full source scan would be preferred to list them all. Cheers, Luca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716713: Re: Bug#716713: libtxc-dxtn-s2tc0: S2TC_REFINE_COLORS=ALWAYS (default) creates broken edges
On Friday 06 September 2013 23:42:44 Lennart Weller wrote: Coming back to this issue as it appearantly won't be fixed upstream anytime soon, does the LOOP fix the issue? Or does it produce new issues? If it works out I could just temporarily set the default to LOOP for the debian package. Yes, it fixes it because the algorithm detects the degeneration of the image and reverts to the previous step (without this refinment). It makes it slightly slower when compressing textures. But this is the only thing I've noticed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]
I found that a Dspam CSS file was always corrupted and I think it may be
related.
# find /var/spool/dspam/data -name *.css -print -exec cssclean {} \;
[...]
/var/spool/dspam/data/orange.fr/bernard/bernard.css
/var/spool/dspam/data/orange.fr/testabcdefg/.dspam25298.css
/var/spool/dspam/data/orange.fr/testabcdefg/.dspam19441.css
/var/spool/dspam/data/orange.fr/testabcdefg/testabcdefg.css
find: cssclean terminate on signal 11
/var/spool/dspam/data/orange.fr/testabcdefg/.dspam20088.css
/var/spool/dspam/data/orange.fr/rene/rene.css
[...]
* I removed testabcdefg.css but after a postqueue -f it was then
recreated corrupted again
* I removed the whole directory of this user (including .dspam* files) but
after a postqueue -f, the file was then recreated corrupted again.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. Err, sorry, should have linked to comment #7 instead in that ticket. [1] We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully. To me that sounds reasonable enough as to why we should be building 0ad with -march=i686. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Yes, should be fixed now, but again, since I don't have any hardware where I can reproduce this locally, I suppose the only way to prove that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber. Regards, Vincent [1] http://trac.wildfiregames.com/ticket/1994#comment:7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719612: minissdpd: README in docs dir is in french
I translated the README file minissdpd-1.2.20130907.tar.gz http://miniupnp.free.fr/files/download.php?file=minissdpd-1.2.20130907.tar.gz Le 13/08/2013 16:52, Daniel Stensnes a écrit : Package: minissdpd Version: 1.1.20120121-1 Severity: minor Tags: l10n /usr/share/doc/minissdpd/README is in french. French is not a supported encryption in my brain. $ apt-cache showpkg minissdpd Package: minissdpd Versions: 1.1.20120121-1 (/var/lib/apt/lists/ftp.no.debian .org_debian_dists_wheezy_main_binary-amd64_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/ftp.no.debian .org_debian_dists_wheezy_main_binary-amd64_Packages MD5: 3dd0e4ad410068e63a26f5f00889c896 Description Language: en File: /var/lib/apt/lists/ftp.no.debian .org_debian_dists_wheezy_main_i18n_Translation-en MD5: 3dd0e4ad410068e63a26f5f00889c896 Reverse Depends: minissdpd:i386,minissdpd miniupnpc,minissdpd libminiupnpc5,minissdpd libminiupnpc-dev,minissdpd libnatpmp1,minissdpd Dependencies: 1.1.20120121-1 - libc6 (2 2.3) minissdpd:i386 (0 (null)) Provides: 1.1.20120121-1 - Reverse Provides: $ -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minissdpd depends on: ii libc6 2.13-38 minissdpd recommends no packages. minissdpd 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#712956: marked as done (0ad: seems to use CPU features not available everywhere)
On Sat, Sep 07, 2013 at 01:53:26AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote: On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx k...@roeckx.be wrote: reopen 712956 thanks nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low . [ Fabio Pedretti ] * Add armel and armhf build support (Closes: #721972) * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956) This is clealy the wrong bug you're closing. It's assigned to 0ad. 0.0.14-2 is still using -msse -march=i686 on i386 See explanation by upstream here [1]. If compiling with -march=i686 is strictly not allowed on Debian i386, I can just simply stop building 0ad for i386, although I'm not sure if that's necessary at all; the package has been sitting in the archive for over a year and I still haven't gotten any complaints about 0ad not running on any Debian user's i386 machine. I don't know if having i686 is acceptable or not. But I currently see no good reason for it. [1] is my own comment. The only reply to that is that they still use the legacy functions, and no reply as to why they need to keep using it and can't move to the new ones. Err, sorry, should have linked to comment #7 instead in that ticket. [1] We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully. CAS being a compare and swap? Which is the atomic function they want to use? To me that sounds reasonable enough as to why we should be building 0ad with -march=i686. Anyway, I have no idea if g++ supports those new atomic functions without -march=i686, but I at least hope so. It wasn't using -march=athlon64 on amd64 before either as far as I know but had problem running on at least one of the buildds. The original issue was that nvidia-texture-tools was compiled with -march=athlon64, which caused one of the amd64 buildds to complain about an Illegal instruction when trying to run 0ad's test suite when building 0ad. There's a relevant issue filed against upstream nvidia-texture-tools about this as well. [2] So that was #713966 and that was fixed in 0ad with the 0.0.14-2 uploaded? Yes, should be fixed now, but again, since I don't have any hardware where I can reproduce this locally, I suppose the only way to prove that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber. I've triggerd that it gets build on barber, you should have a log about that in half an hour I guess. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722061: [calibre] Calibre fails to detect connected Kindle
Package: calibre Version: 1.0.0+dfsg-1 Severity: important Calibre does not detect the USB connected Amazon Kindle device and the options to export to the device are greyed out even though the device is mounted properly. --- System information. --- Architecture: amd64 Kernel: Linux 3.10-2-amd64 Debian Release: jessie/sid 500 unstableftp.us.debian.org 500 unstableftp.sunet.se 500 testing security.debian.org 500 testing ftp.us.debian.org --- Package information. --- Depends(Version) | Installed -+- python2.7| 2.7.5-7 python-dbus | 1.2.0-2+b1 python-imaging | 1.1.7-4 python-lxml | 3.2.0-1+b1 python-mechanize (= 0.2.5) | 1:0.2.5-3 python-beautifulsoup | 3.2.1-1 python-pkg-resources | 0.6.49-2 python-cssutils (= 0.9.9~) | 0.9.10~b1-2 python-cssselect | 0.8-1 python-cherrypy3 (= 3.1.1) | 3.2.2-2 python-dateutil | 1.5+dfsg-0.1 python-feedparser| 5.1.2-2 python-markdown | 2.3.1-1 python-qt4 (= 4.10.2-2) | 4.10.2-2 python-pyparsing | 1.5.7+dfsg1-2 python-routes| 1.13-2 python-chardet | 2.0.1-2 python-netifaces | 0.8-2 python-apsw | 3.7.17-r1-1.1 xdg-utils| 1.1.0~rc1+git20111210-7 imagemagick | 8:6.7.7.10-6 poppler-utils| 0.18.4-8 fonts-liberation | 1.07.3-2 libjs-mathjax(= 2.1+20121028-1) | 2.2-1 calibre-bin(= 1.0.0+dfsg-1) | 1.0.0+dfsg-1 Recommends(Version) | Installed ===-+-=== python-dnspython| Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721125: gitolite: info command does not work.
David Bremner brem...@debian.org writes: I can't duplicate your bug here. 1) Do you have a file /usr/share/gitolite/gitolite/conf/VERSION ? Yes (/usr/share/gitolite/conf/VERSION). 2) does it work if you explicitely say ssh goo@bar info ? No. About your last point, the file doesn't actually live in /etc. It could well be the error message is wrong. No, it looks in /etc. However ~git/.gitolite.rc starts with $GL_PACKAGE_CONF=/etc/gitolite; $GL_PACKAGE_HOOKS=/usr/share/gitolite/hooks; here. Changing it to /usr/share/gitolite/conf makes it work again. The changelog also mentions * Change conf directory from /etc/gitolite to /usr/share/gitolite/conf, these files aren't meant to get edited directly (closes: #611857) so it looks like this change breaks older configurations without notice? I've seen the problem also on other installations besides mine that I know use Debian. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722062: linux-image-3.10-2-amd64: Please enable CONFIG_SENSORS_JC42=m and CONFIG_SENSORS_NCT6775=m
Package: src:linux Version: 3.10.7-1 Severity: wishlist Dear Maintainer, New C226-based SuperMicro X10SAE motherboards use Nuvoton NCT6775 super-I/O chips and JC42 sensors for DIMMs; it would be great if the kernel included the appropriate modules! Thanks, Stephen -- Package-specific info: ** Version: Linux version 3.10-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.7-1 (2013-08-17) ** Command line: BOOT_IMAGE=/vmlinuz-3.10-2-amd64 root=/dev/mapper/vg--fast-root ro quiet ** Not tainted ** Kernel log: [5.887445] IR MCE Keyboard/mouse protocol handler initialized [5.887665] lirc_dev: IR Remote Control driver registered, major 246 [5.887922] cx88[0]/0: registered device video1 [v4l2] [5.887939] cx88[0]/0: registered device vbi0 [5.887956] cx88[0]/0: registered device radio0 [5.888010] cx88[0]/2: cx2388x 8802 Driver Manager [5.888080] cx88[0]/2: found at :04:00.2, rev: 5, irq: 17, latency: 32, mmio: 0xf100 [5.888220] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards [5.888224] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [5.888226] IR LIRC bridge handler initialized [5.891957] cx88/2: cx2388x dvb driver version 0.0.9 loaded [5.891959] cx88/2: registering cx8802 driver, type: dvb access: shared [5.891960] cx88[0]/2: subsystem: 0070:9402, board: Hauppauge WinTV-HVR1100 DVB-T/Hybrid [card=40] [5.891961] cx88[0]/2: cx2388x based DVB/ATSC card [5.891962] cx8802_alloc_frontends() allocating 1 frontend(s) [5.897921] tuner-simple 10-0061: attaching existing instance [5.897922] tuner-simple 10-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner) [5.902246] DVB: registering new adapter (cx88[0]) [5.902248] cx88-mpeg driver manager :04:00.2: DVB: registering adapter 0 frontend 0 (Conexant CX22702 DVB-T)... [5.916494] usbcore: registered new interface driver snd-usb-audio [5.985582] fbcon: inteldrmfb (fb0) is primary device [6.171296] Console: switching to colour frame buffer device 240x75 [6.188466] i915 :00:02.0: fb0: inteldrmfb frame buffer device [6.188471] i915 :00:02.0: registered panic notifier [6.189641] i915 :00:02.0: More than 8 outputs detected [6.706785] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [6.706982] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input8 [6.707239] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [6.707710] snd_hda_intel :00:03.0: irq 61 for MSI/MSI-X [6.719966] hda_codec: invalid CONNECT_LIST verb 5[1]:0 [6.720056] hda_codec: invalid CONNECT_LIST verb 6[1]:0 [6.720114] hda_codec: invalid CONNECT_LIST verb 7[1]:0 [6.720626] input: HDA Intel MID HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/sound/card0/input9 [6.720796] input: HDA Intel MID HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card0/input10 [6.720943] input: HDA Intel MID HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card0/input11 [6.721681] snd_hda_intel :00:1b.0: irq 62 for MSI/MSI-X [6.733733] hda_codec: ALC1150: SKU not ready 0x [6.736963] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input12 [6.746012] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input13 [6.746225] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card1/input14 [6.746391] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card1/input15 [6.746537] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card1/input16 [6.746682] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card1/input17 [6.746818] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input18 [6.746983] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input19 [7.223339] EXT4-fs (dm-0): re-mounted. Opts: (null) [7.346322] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro [7.480842] fuse init (API version 7.22) [7.541744] loop: module loaded [7.832836] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [7.983533] Adding 1959924k swap on /dev/mapper/cswap2. Priority:-1 extents:1 across:1959924k [ 13.412897] kjournald starting. Commit interval 5 seconds [ 13.454595] EXT3-fs (md4): using internal journal [ 13.454604] EXT3-fs (md4): mounted filesystem with ordered data mode [ 13.457980] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null) [ 13.460409] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null) [ 13.489411] kjournald starting. Commit interval 5 seconds [ 13.546670] EXT3-fs (dm-3): using internal journal [ 13.546681] EXT3-fs (dm-3): mounted filesystem with ordered data
Bug#722063: xserver-xorg-input-evdev: Please package 2.8.1 for experimental with xorg 1.14 abi support
Package: xserver-xorg-input-evdev Version: 1:2.8.1-1 Severity: wishlist Works as you can see and is needed to install xorg 1.14 from experimental... -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Mar 30 20:07 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2285840 Aug 30 09:10 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 670] [10de:1189] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 275 Mar 30 23:32 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 310.19 (pbuilder@cake) Fri Nov 23 18:06:37 UTC 2012 Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation EndSection /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 3.10.10 (valette@tri-yann4) (gcc version 4.8.1 (Debian 4.8.1-9) ) #18 SMP PREEMPT Sat Aug 31 19:19:21 CEST 2013 Xorg X server log files on system: -- -rw-r--r-- 1 root root 21671 Sep 7 11:27 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [16.887] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [16.887] _XSERVTransOpen: transport open failed for inet6/tri-yann4:0 [16.887] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [16.889] X.Org X Server 1.14.2.901 (1.14.3 RC 1) Release Date: 2013-07-25 [16.889] X Protocol Version 11, Revision 0 [16.889] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian [16.890] Current Operating System: Linux tri-yann4 3.10.10 #18 SMP PREEMPT Sat Aug 31 19:19:21 CEST 2013 x86_64 [16.890] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.10 root=/dev/sdb5 ro rootfstype=ext4 memmap=4K$0x00031db35000 quiet [16.890] Build Date: 30 August 2013 07:05:47AM [16.890] xorg-server 2:1.14.2.901-2+b1 (amd64 Build Daemon (binet) buildd-bi...@buildd.debian.org) [16.890] Current version of pixman: 0.30.2 [16.890]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [16.890] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [16.890] (==) Log file: /var/log/Xorg.0.log, Time: Sat Sep 7 10:08:02 2013 [16.891] (==) Using config file: /etc/X11/xorg.conf [16.891] (==) Using system config directory /usr/share/X11/xorg.conf.d [16.891] (==) No Layout section.
Bug#722064: start and stop actions are no longer supported
Package: keyboard-configuration Version: 1.97 Setting up keyboard-configuration (1.97) ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721678:
control: retitle -1 ITP: liblenskit-java -- toolkit for building, researching, and studying recommender systems control: owner -1 !
Bug#722065: Problems with LC_ALL set to other than C
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: facter Version: 1.7.2-1 Severity: normal On one system I have the locales set to de_DE; even for root. With that settings I get the following from facter: ~ facter ipaddress eth0 Link encap:Ethernet Hardware Adresse xx:xx:xx:xx:xx:xx inet Adresse:xxx.xx.1.1 Bcast:xxx.xx.1.255 Maske:255.255.255.0 inet6-Adresse: fe80:::xxff:fexx:/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1 RX packets:3381852 errors:0 dropped:72557 overruns:0 frame:0 TX packets:2139666 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000 RX bytes:3092954832 (2.8 GiB) TX bytes:298711674 (284.8 MiB) Interrupt:20 Speicher:d470-d472 loLink encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:65536 Metrik:1 RX packets:196835 errors:0 dropped:0 overruns:0 frame:0 TX packets:196835 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:13036012 (12.4 MiB) TX bytes:13036012 (12.4 MiB) tun0 Link encap:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet Adresse:192.168.xx.xx P-z-P:192.168.xx.xx Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metrik:1 RX packets:93334 errors:0 dropped:0 overruns:0 frame:0 TX packets:111285 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:25497972 (24.3 MiB) TX bytes:51608834 (49.2 MiB) Setting it to C gives the following: ~ LC_ALL=C facter ipaddress xxx.xx.1.1 This is a regression as the version before didn't has this bug. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7.5 (SMP w/4 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages facter depends on: ii bind9-host [host] 1:9.9.3.dfsg.P2-4 ii net-tools 1.60-25 ii ruby 1:1.9.3 ii ruby-json 1.8.0-1 ii ruby1.8 [ruby-interpreter]1.8.7.358-7.1 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.2 Versions of packages facter recommends: ii dmidecode 2.12-2 ii pciutils 1:3.2.0-3 pn virt-what none facter suggests no packages. - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSKvyTAAoJEKZ8CrGAGfasF8UL/1GwkUX97lgVH3ZDa9OOR5cb IGWgU3Z9Jrz8n5ZoPQaPe+tcd4zi3mRPDfYA/mmQwCiRDA5wfEHJ9+KOq5t785yp QJah71m52ZPlagNAh5Ag2ThCqnPR1+NRjK2OaB8Svz87sTzM5dx8jBWxvbiW/zNN vnTWDwEU7QjdgNoFBSUnNmXvNrVw7jAK+Yx92wH4TowVDTWyXhH80MGvep0JO435 E5vOHw+elHBGjsVGz9Xavg0GWtmU0PlN3VKE535NFqHqp8g5srWVW7cpvhiTfcg0 XUgdWjPsmxZ8UEIvujHNkS5B2+LVYdwg9bk/qArVs8t4harKAclhzYOQvBDmz6lw u+/XPzyUr3szIHBesUvjEPGskD3SiGp+CajV0mKE2s5WUywMEM66BXG+yiEzQLWI QwbKhutWZjAiSIBevI4lt1rDQwwASS4dgxL6CL9GY22ZHfA+2SUAhBdoSa9Z0Q62 G4iwnMvYLz2pdE2Ee+AMZPtcvivgyFFbwKv5Nh696A== =Hrrx -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#719763: QT4 FTBFS on mips64(el) and mipsn32(el)
Hi, this patch has been accepted by upstream to qt4 and qt5. On Wed, Aug 28, 2013 at 12:18 AM, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: On Tuesday 27 August 2013 11:43:49 YunQiang Su wrote: hi, I forward this bug to upstream as https://bugreports.qt-project.org/browse/QTBUG-33187 Just saw it. I saddly forgot that upstream can't take patches from the bug tracker but from gerrit. Would you mind pushing your changes there? Gerrit uses the same login info as the bugtracker. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697191:
reopen 697191 tags 697191 wontfix thanks I believe #697191 is a wontfix as far as I understand. I'd rather have it open to prevent duplicate. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534641: mendex bug
Dear all,
I hope there is still someone listening.
Since quite some time there is a bug in mendex.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534641
Easy to reproduce:
With the following idx file:
\indexentry{foo|(}{1}
\indexentry{foo|mac}{1}
\indexentry{foo|)}{1}
mendex produces
...
\item foo, 1}, 1
...
instead of
...
\item foo, \mac{1}, 1
...
I looked through the current sources in TeX Live and found that
in fwrite.c, function range_check:
if (strlen(ind.p[j].enc)0) {
sprintf(tmpbuff,%s%s%s,encap_prefix,ind.p[j].enc,encap_infix);
sprintf(tmpbuff,%s%s%s,ind.p[j].page,encap_suffix,delim_n);
linecheck(lbuff,tmpbuff);
}
that looks suspicious. The tmpbuff is overwritten on the second
incantation, and in fact the
encap_prefix(which is \)
ind.p[j].enc(which is the macro name)
encap_infix (which is {)
are missing from the output.
So my guess is that the correct version would be to have
sprintf(tmpbuff,%s%s%s%s%s%s,encap_prefix,ind.p[j].enc,encap_infix,ind.p[j].page,encap_suffix,delim_n);
instead.
And indeed, with that change the output is as expected.
Checking the differences I see that the *reverse change* was introduced
between 2.6c and 2.6d. So till 2.6c the above line was there.
I am not sure who is currently maintaining mendex, but I would
suggest to fix it as lined out above.I attach a patch against
current TeX Live sources (as far as I see).
Norbert
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
diff --git a/texk/mendexk/ChangeLog b/texk/mendexk/ChangeLog
index fe87113..571bc64 100644
--- a/texk/mendexk/ChangeLog
+++ b/texk/mendexk/ChangeLog
@@ -1,3 +1,8 @@
+2013-09-07 Norbert Preining prein...@logic.at
+
+ * fwrite.c: fix missing output when range operators are
+ used with macro definitions
+
2012-11-19 Peter Breitenlohner p...@mppmu.mpg.de
* Makefile.am: Avoid use of deprecated INCLUDES.
diff --git a/texk/mendexk/fwrite.c b/texk/mendexk/fwrite.c
index 8c18782..bc5a0ec 100644
--- a/texk/mendexk/fwrite.c
+++ b/texk/mendexk/fwrite.c
@@ -384,8 +384,7 @@ static int range_check(struct index ind, int count, char *lbuff)
ind.p[j].enc++;
}
if (strlen(ind.p[j].enc)0) {
- sprintf(tmpbuff,%s%s%s,encap_prefix,ind.p[j].enc,encap_infix);
- sprintf(tmpbuff,%s%s%s,ind.p[j].page,encap_suffix,delim_n);
+ sprintf(tmpbuff,%s%s%s%s%s%s,encap_prefix,ind.p[j].enc,encap_infix,ind.p[j].page,encap_suffix,delim_n);
linecheck(lbuff,tmpbuff);
}
}
Bug#711943: transition: openmpi
On 07/09/2013 10:34, Julien Cristau wrote: It doesn't seem to work on ia64, causing a number of build failures. Is there a way this can be resolved quickly? I just check with a rebuild of openmpi on a ia64 porterbox and all upstream unitary tests are working ... (they don't have much). Currently, package builds seem to freeze when displaying this warning: -- A deprecated MCA parameter value was specified in the environment or on the command line. Deprecated MCA parameters should be avoided; they may disappear in future releases. Deprecated parameter: plm_rsh_agent -- Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722066: libnfc: New upstream version 1.7.0 available
Package: libnfc Severity: wishlist Version 1.7.0 of libnfc is now available https://code.google.com/p/libnfc/downloads/list Bye -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599584:
After reading https://launchpad.net/startup-manager/+announcement/8300 should we consider to remove this package from debian? (maybe in favour of grub-customizer as the upstream author suggests?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722067: add as-needed support for mips*
Package: gcc-4.8 The patch attached -- YunQiang Su mips-as-needed.diff Description: Binary data
Bug#722068: when with_deps_on_target_arch_pkgs=yes, build gccbase
Package: gcc-4.8 When not stage 1 and set with_deps_on_target_arch_pkgs=yes, build multiarched gccbase and set the correct dependencies. -- YunQiang Su build-gcc-base-when-with-multiarch-cross.diff Description: Binary data
Bug#711441: liberror-perl: diff for NMU version 0.17-1.1
tags 711441 + patch
thanks
Dear maintainer,
Please find attached the patch for the just uploaded NMU of
liberror-perl (versioned as 0.17-1.1).
It would be nice to know if you are no longer interested in
maintaining this package so that it can be properly orphaned.
Cheers,
dam
diff -u liberror-perl-0.17/debian/changelog liberror-perl-0.17/debian/changelog
--- liberror-perl-0.17/debian/changelog
+++ liberror-perl-0.17/debian/changelog
@@ -1,3 +1,10 @@
+liberror-perl (0.17-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * apply fix for tests from upstream (closes: #711441)
+
+ -- CSILLAG Tamas csta...@cstamas.hu Sat, 07 Sep 2013 10:04:34 +0200
+
liberror-perl (0.17-1) unstable; urgency=low
* New upstream version (closes: #383606)
only in patch2:
unchanged:
--- liberror-perl-0.17.orig/t/08warndie.t
+++ liberror-perl-0.17/t/08warndie.t
@@ -74,9 +74,9 @@
};
my ( $linea, $lineb ) = ( $line + 2, $line + 3 );
-like( $s, qr/^A warning at $file line $linea:
+like( $s, qr/^A warning at $file line $linea\.?:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, warn \\n-terminated STDERR );
is( $felloffcode, 1, warn \\n-terminated felloffcode );
@@ -86,9 +86,9 @@
};
( $linea, $lineb ) = ( $line + 2, $line + 3 );
-like( $s, qr/^A warning at $file line $linea:
+like( $s, qr/^A warning at $file line $linea\.?:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, warn unterminated STDERR );
is( $felloffcode, 1, warn unterminated felloffcode );
@@ -108,7 +108,7 @@
Full stack trace:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, die \\n-terminated STDERR );
is( $felloffcode, 0, die \\n-terminated felloffcode );
@@ -129,7 +129,7 @@
Full stack trace:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, die unterminated STDERR );
is( $felloffcode, 0, die unterminated felloffcode );
@@ -150,7 +150,7 @@
Full stack trace:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, Error STDOUT );
is( $felloffcode, 0, Error felloffcode );
@@ -189,9 +189,9 @@
};
( $linea, $lineb ) = ( $line + 2, $line + 3 );
-like( $s, qr/^My custom warning here: A warning at $file line $linea:
+like( $s, qr/^My custom warning here: A warning at $file line $linea\.?:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, Custom warn STDERR );
is( $felloffcode, 1, Custom warn felloffcode );
@@ -211,7 +211,7 @@
Full stack trace:
\tmain::__ANON__\(\) called at $file line $linekid
-\tmain::run_kid\('CODE\(0x[0-9a-f]+\)'\) called at $file line $lineb
+\tmain::run_kid\('?CODE\(0x[0-9a-f]+\)'?\) called at $file line $lineb
$/, Custom die STDERR );
is( $felloffcode, 0, Custom die felloffcode );
Bug#722069: 1.97 changelog blank
Package: keyboard-configuration Version: 1.97 Severity: normal console-setup (1.97) unstable; urgency=low * - -- Christian Perrier bubu...@debian.org Fri, 06 Sep 2013 22:38:19 +0200 A very dashing changelog indeed, but not a very informative one. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721020: roundcube: Creating default object from empty value when composing new message
❦ 27 août 2013 10:52 CEST, Olaf Zaplinski o...@zaplinski.de : I get a Creating default object from empty value when composing a new message please see http://trac.roundcube.net/ticket/1488404 for details, even the IE8 bug appears here Since there is an easy workaround (setting display_errors to Off), I don't think there will be a stable update for this problem. I mark the bug as fixed for 0.9.2-2. -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c signature.asc Description: PGP signature
Bug#704785: OGRE's FTBFS #713640 affects other packages
2013/9/5 Paul Wise p...@debian.org:
On Thu, 2013-09-05 at 00:32 +0100, Manuel A. Fernandez Montecelo wrote:
As you probably know, if you add -lboost_system (maybe needs also
other boost components after that) to LDFLAGS it will go away. Of
course there should be a better solution for this and I'll try to find
it, but I don't know how yet and it may take a while.
Right. I guess adding -lboost_system to the right pkgconfig files (OGRE
or boost) is probably the correct solution here.
The thing is that if this is indeed the problem, I think that OGRE
itself should add -lboost_thread, since libOgreMain depends on thread
and system. It doesn't emit these flags for any of the .pc files that
it ships.
Do you already have to add this -lboost_thread manually?
Whith this test program:
===
#include OGRE/Ogre.h
int main()
{
return 0;
}
===
Compiling using -lboost_thread fails, but with -lboost_system
succeeds, which I don't really understand.
===
$ g++ -lOgreMain -lboost_thread test.c
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libOgreMain.so:
undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/lib/libboost_system.so.1.54.0: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status
$ g++ -lOgreMain -lboost_system test.c
$
===
It seems that the thread component pulls system since 1.53, and OGRE
1.8.1 was released well before that and people have problems with
this. I don't know if this will be addressed upstream with a new .2
release, doesn't look like it will happen.
Oh, so this is a boost bug? Or do you mean the OGRE thread component?
OGRE only uses boost::thread (the dependency on boost::system comes
from boost::thread, is the only thing that OGRE uses). Since 1.53 it
seems that thread requires system, something that didn't happen before
but it's likely to stay in the future.
OGRE can also be built against POCO or TBB for its threading support.
So I think that either OGRE upstream should emit the correct flags, or
there's something wrong with Boost itself, but can't tell confidently
enough yet for knowing what should be done.
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721537: perl: FTBFS on hppa: lib/locale test fails
On 2-Sep-13, at 7:59 AM, Niko Tyni wrote: If you have the time, upstream would surely appreciate bisecting the upstream commit that broke it. See pod/perlgit.pod in the perl source tree. Based on my testing, upstream fixed the bug with the following commit: commit 1500bd919ffeae0f3252f8d1bb28b03b043d328e Author: Karl Williamson pub...@khwilliamson.com Date: Wed Jun 19 21:00:53 2013 -0600 PATCH: [perl #112208]: Set utf8 flag on $! appropriately This patch sets the utf8 flag on $! if the error string passes utf8 validity tests and has some bytes with the upper bit set. (If none have that bit set, is an ASCII string, and whether or not it is UTF-8 is irrelevant.) This is a heuristic that could fail, but as the reference in the comments points out this is unlikely. One can reasonably assume that a UTF-8 locale will return a UTF-8 result. So another approach would be to look at that (but we wouldn't want to turn the flag on for a purely ASCII string anyway, as that could change the semantics from existing behavior by making the string follow Unicode rules, whereas it didn't necessarily before.) To do this, we could keep track of the utf8ness of the LC_MESSAGES locale. But until the heuristic in this patch is shown to not be good enough, I don't see the need to do this extra work. There were a number of other locale related patches just prior to this one. Upstream bug is perl #119567. Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#397791: Processed: tagging 397791
On 09/07/2013 09:27 AM, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: tags 397791 + patch Bug #397791 [redir] redir: would be nice if it worked as an SSH proxy command Added tag(s) patch. thanks Stopping processing here. hi tobias-- i've orphaned redir (http://bugs.debian.org/619357) -- would you be interested in taking the package over? If not, i intend to ask ftp-masters to remove it from the archive. --dkg signature.asc Description: OpenPGP digital signature
Bug#722071: grsync: Wrong french translation newer files (-u argument)
Package: grsync Version: 1.1.1-1 Severity: normal Tags: l10n msgid Do not update newer files is tranlated in french language wrongly to msgstr Ne pas mettre à jour les fichiers nouveaux This could put the user in trouble. man rsync -u, --update This forces rsync to skip any files which exist on the destination and have a modified time that is newer than the source file. The meaning is Do not update newer files than source files if they are present. So in french it should be : msgstr Ne pas mettre à jour les fichiers plus récents. This issue exists also in wheezy (Version 1.2.0-1). -- System Information: Debian Release: 6.0.7 APT prefers oldstable-proposed-updates APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.4-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grsync depends on: ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-7~bpo60+1 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.9-1.1~bpo60+1 FreeType 2 font engine, shared lib ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii rsync 3.0.7-2 fast remote file copy program (lik Versions of packages grsync recommends: ii ssh-askpass 1:1.2.4.1-9 under X, asks user for a passphras grsync 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#722072: abyss: needs rebuild against current openmpi
Source: abyss Version: 1.3.4-4 Severity: serious Hi, libopenmpi1.3 is being replaced by libopenmpi1.6, abyss needs to be rebuilt against the latter. Cheers, Julien signature.asc Description: Digital signature
Bug#722073: clustalw-mpi: needs rebuild against current openmpi
Source: clustalw-mpi Version: 0.15-2 Severity: serious Tags: jessie sid Hi, openmpi 1.3 is being replaced by 1.6, clustalw-mpi needs to be rebuilt against the latter. Cheers, Julien signature.asc Description: Digital signature
Bug#534641: [ptex:00349] mendex bug
Hi Norbert,
I looked through the current sources in TeX Live and found that
in fwrite.c, function range_check:
if (strlen(ind.p[j].enc)0) {
sprintf(tmpbuff,%s%s%s,encap_prefix,ind.p[j].enc,encap_infix);
sprintf(tmpbuff,%s%s%s,ind.p[j].page,encap_suffix,delim_n);
linecheck(lbuff,tmpbuff);
}
that looks suspicious. The tmpbuff is overwritten on the second
incantation, ...
I searched for similar lines in fwrite.c (see an attached fwrite.c.diff).
I think these are apparently bugs.
If I'm not wrong, please commit them.
Thanks,
Akira
fwrite.c.diff
Description: Binary data
Bug#722074: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Package: lm-sensors Version: 1:3.3.4-2 Severity: normal Dear Maintainer, While upgrading lm-sensors from 1:3.3.4-1 to 1:3.3.4-2 I got this warning : Préparation du remplacement de lm-sensors 1:3.3.4-1 (en utilisant .../lm-sensors_1%3a3.3.4-2_amd64.deb) ... Dépaquetage de la mise à jour de lm-sensors ... Paramétrage de lm-sensors (1:3.3.4-2) ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults -- Nicolas Le Cam -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (700, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lm-sensors depends on: ii init-system-helpers 1.8 ii libc62.17-92+b1 ii libsensors4 1:3.3.4-2 ii lsb-base 4.1+Debian12 ii perl 5.14.2-21 ii sed 4.2.2-2 lm-sensors recommends no packages. Versions of packages lm-sensors suggests: pn fancontrol none pn i2c-tools none pn read-edid none pn sensord 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#534641: [ptex:00349] mendex bug
Hi Norbert, If I'm not wrong, please commit them. I was wrong. I overlooked the macro: #define TAIL(x) (x+strlen(x)) Please ignore my previous mail. Sorry. Thanks, Akira -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722075: libc6: getaddrinfo() sends DNS queries to random file descriptors
Package: libc6
Version: 2.13-38
Severity: normal
Under high load, getaddrinfo() seems to start sending DNS queries to random
file descriptors.
If a process has opened connections to remote servers or clients, getaddrinfo()
may write DNS queries to these connections.
This has been noticed on a real world application written in golang, and the
bug was successfuly reproduced using pure C code.
The attached code reproduces the bug on libc6 packages 2.13-38 (stable),
2.17-92 (testing).
What the code does:
- a thread listens to a local unix socket
- a thread connects to the unix socket, never writes to it, dups the
connection as much as possible (fills the fd space), close the dups, and starts
dup()ing again
- lots of threads call getaddrinfo()
Under less than a minute, the listener starts reading garbage (presumably DNS
queries).
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
// gcc -o bug bug.c -lpthread ./bug
#include sys/types.h
#include sys/stat.h
#include stdio.h
#include sys/socket.h
#include netdb.h
#include errno.h
#include sys/un.h
#include stdlib.h
#include pthread.h
#include unistd.h
#define LOOKUP_THREADS 1000
#define SOCKET_PATH /tmp/test.sock
void* lookup_thread(void *_) {
for (;;) {
struct addrinfo *res;
struct addrinfo hints;
memset(hints, 0, sizeof(hints));
if (0 == getaddrinfo(example.com, NULL, hints, res)) {
freeaddrinfo(res);
}
}
return NULL;
}
void lookup() {
int i;
for (i = 0; i LOOKUP_THREADS; i++) {
pthread_t t;
pthread_attr_t ta;
pthread_attr_init(ta);
pthread_attr_setstacksize(ta, 10010);
if (0 != pthread_create(t, ta, lookup_thread, (void*)(uintptr_t)i)) {
perror(pthread_create lookup thread);
exit(1);
}
pthread_attr_destroy(ta);
}
}
void* server_thread(void *_) {
struct sockaddr_un saddr;
int s = socket(AF_UNIX, SOCK_STREAM, 0);
memset(saddr, 0, sizeof(saddr));
if (s == -1) {
perror(server socket);
return NULL;
}
saddr.sun_family = AF_UNIX;
strncpy(saddr.sun_path, SOCKET_PATH, sizeof(saddr.sun_path)-1);
if (bind(s, (struct sockaddr *)saddr, sizeof(struct sockaddr_un)) == -1) {
perror(bind);
close(s);
return NULL;
}
if (-1 == listen(s, 0)) {
perror(listen);
close(s);
return NULL;
}
for (;;) {
struct sockaddr_un paddr;
socklen_t paddrlen;
int fd = accept(s, (struct sockaddr*) paddr, paddrlen);
if (fd == -1) {
perror(accept);
close(s);
return NULL;
}
for (;;) {
char c;
int n = read(fd, c, 1);
fprintf(stderr, BUG: has read char 0x%02hhx: %c\a\n, (unsigned int) c, c);
if (n == 0) {
break;
}
}
close(fd);
}
return NULL;
}
void sock() {
int s, i, m;
struct sockaddr_un saddr;
// open a client socket to SOCK_STREAM
for (;;) {
s = socket(AF_UNIX, SOCK_STREAM, 0);
if (s == -1) {
perror(socket);
sleep(1);
continue;
}
memset(saddr, 0, sizeof(saddr));
saddr.sun_family = AF_UNIX;
strncpy(saddr.sun_path, SOCKET_PATH, sizeof(saddr.sun_path)-1);
if (connect(s, (struct sockaddr *)saddr, sizeof(struct sockaddr_un)) == -1) {
perror(connect);
close(s);
sleep(1);
continue;
}
break;
}
// repeatedly fill the file descriptor space with dups of the socket, and close the dups
int fds[65536];
for (;;) {
for (i = 0, m = 0; i sizeof(fds)/sizeof(*fds); i++) {
int fd = dup(s);
if (fd == -1) {
if (errno == EMFILE) {
break;
} else {
perror(dup);
}
}
fds[i] = fd;
m = i;
}
for (i = 0; i = m; i++) {
close(fds[i]);
}
continue;
}
}
int main() {
// Listen on SOCKET_PATH; if we receive something on this socket, we have
// successfuly reproduced the bug
unlink(SOCKET_PATH);
pthread_t t;
if (0 != pthread_create(t, NULL, server_thread, NULL)) {
perror(pthread_create server thread);
return 1;
}
// Do many getaddrinfo() in
Bug#719612: minissdpd: README in docs dir is in french
Ah, great! Thanks
Bug#458739: vgrabbj crashes frequently
Hi What did you expect? Regards Op 7 sep. 2013 14:47 schreef Ludovic Rousseau ludovic.rouss...@free.fr het volgende: Hello, You have not sent any new information to this bug report. I am now closing it. If you still have crashes with the latest version 0.9.7-1 then open a new bug. Thanks Le 02/01/08 15:18, Folkert van Heusden a écrit : Package: vgrabbj Version: 0.9.6-3 Severity: normal vgrabbj crashes frequently (multiple times per day): Output in dmesg: vgrabbj[12737]: segfault at 000f rip 2b935ff24020 rsp 7fff4ba30be8 error 4 Startup command-line: /usr/bin/vgrabbj -l 30 -f /home/appel/webcam/lastsnap_**new.jpg -C -d /dev/video0 -a 3 -n -i cif -t /usr/share/ircmarkers/fixed_**01.ttf -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages vgrabbj depends on: ii ftplib3 3.1-1-6 Library of callable ftp routines ii libc6 2.7-3GNU C Library: Shared libraries ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii libpng12-0 1.2.15~beta5-3 PNG library - runtime ii libttf2 1.4pre.cvs20060210-1 Old FreeType 1 TrueType font engin ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime vgrabbj recommends no packages. -- no debconf information -- Dr. Ludovic Rousseau
Bug#534641: [ptex:00350] Re: mendex bug
On Sa, 07 Sep 2013, Akira Kakuto wrote: sprintf(tmpbuff,%s%s%s,encap_prefix,ind.p[j].enc,encap_infix); sprintf(tmpbuff,%s%s%s,ind.p[j].page,encap_suffix,delim_n); that looks suspicious. The tmpbuff is overwritten on the second incantation, ... I searched for similar lines in fwrite.c (see an attached fwrite.c.diff). I think these are apparently bugs. If I'm not wrong, please commit them. Ahh, maybe the intended rewrite was to have sprintf(TAIL(tmpbuff),%s%s%s,encap_prefix,ind.p[j].enc,encap_infix); sprintf(TAIL(tmpbuff),%s%s%s,ind.p[j].page,encap_suffix,delim_n); then it would work I guess that is the better fix. What do you think? Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722076: dmraid: Mapped dmraid block devices are undersized
Package: dmraid
Version: 1.0.0.rc16-4.2
Severity: important
Hello,
Today I replaced a set of aging 1TB drives which were in an ISW raid01
set with new 3TB disks. After creating a new set (in the bios) I was
dismayed to find the new mapper blockdev *smaller* than before.
I tried again using the dmraid utility, rather than setting it up in the
bios, so I had something more concrete to report.
Each disks is indeed 3TB (phew)
# blockdev --getsize64 /dev/sd{c..f}
3000592982016
3000592982016
3000592982016
3000592982016
Creating the array:
# dmraid -f isw --create data --type 01 --disk
/dev/sdc,/dev/sdd,/dev/sde,/dev/sdf
Create a RAID set with ISW metadata format
RAID name: data
RAID type: RAID01 (isw RAID10)
RAID size: 5589G (11721047228 blocks)
DISKS: /dev/sdc, /dev/sdd, /dev/sde, /dev/sdf,
About to create a RAID set with the above settings. Continue ? [y/n] :y
Listing details of the new array. I note that each of the subnet mirrors
has a size of 1565556736 blocks (~746GB) and the superset seems to be
correctly striping these to 3131113472 blocks (~1493GB).
# dmraid -s -s isw_jffegbfhc_data
*** Group superset isw_jffegbfhc
-- Active Superset
name : isw_jffegbfhc_data
size : 3131113472
stride : 128
type : raid01
status : ok
subsets: 2
devs : 4
spares : 0
-- Active Subset
name : isw_jffegbfhc_data-0
size : 1565556736
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
-- Active Subset
name : isw_jffegbfhc_data-1
size : 1565556736
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
dmraid -b reports the appropriate number of blocks available per device:
# dmraid -b | grep WD
/dev/sde: 5860533168 total, WD-WCC1T1097209
/dev/sdf: 5860533168 total, WD-WCC1T1476226
/dev/sdc: 5860533168 total, WD-WCC1T1503861
/dev/sdd: 5860533168 total, WD-WCC1T1080929
For context, this system has one other raid array. The root volume is a
pair of raid1 SSDs:
# dmraid -s isw_deagibdgda_root
*** Group superset isw_deagibdgda
-- Active Subset
name : isw_deagibdgda_root
size : 125040896
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
This size is correct - each SSD is 125045424 blocks long.
Is this related to the lack of GPT support in dmraid?
Thanks,
Nick
-- Package-specific info:
--- dmraid -r -vvv output
WARN: locking /var/lock/dmraid/.lock
NOTICE: /dev/sde: asr discovering
NOTICE: /dev/sde: ddf1discovering
NOTICE: /dev/sde: hpt37x discovering
NOTICE: /dev/sde: hpt45x discovering
NOTICE: /dev/sde: isw discovering
NOTICE: /dev/sde: isw metadata discovered
NOTICE: /dev/sde: jmicron discovering
NOTICE: /dev/sde: lsi discovering
NOTICE: /dev/sde: nvidia discovering
NOTICE: /dev/sde: pdc discovering
NOTICE: /dev/sde: sil discovering
NOTICE: /dev/sde: via discovering
NOTICE: /dev/sdf: asr discovering
NOTICE: /dev/sdf: ddf1discovering
NOTICE: /dev/sdf: hpt37x discovering
NOTICE: /dev/sdf: hpt45x discovering
NOTICE: /dev/sdf: isw discovering
NOTICE: /dev/sdf: isw metadata discovered
NOTICE: /dev/sdf: jmicron discovering
NOTICE: /dev/sdf: lsi discovering
NOTICE: /dev/sdf: nvidia discovering
NOTICE: /dev/sdf: pdc discovering
NOTICE: /dev/sdf: sil discovering
NOTICE: /dev/sdf: via discovering
NOTICE: /dev/sdb: asr discovering
NOTICE: /dev/sdb: ddf1discovering
NOTICE: /dev/sdb: hpt37x discovering
NOTICE: /dev/sdb: hpt45x discovering
NOTICE: /dev/sdb: isw discovering
NOTICE: /dev/sdb: isw metadata discovered
NOTICE: /dev/sdb: jmicron discovering
NOTICE: /dev/sdb: lsi discovering
NOTICE: /dev/sdb: nvidia discovering
NOTICE: /dev/sdb: pdc discovering
NOTICE: /dev/sdb: sil discovering
NOTICE: /dev/sdb: via discovering
NOTICE: /dev/sda: asr discovering
NOTICE: /dev/sda: ddf1discovering
NOTICE: /dev/sda: hpt37x discovering
NOTICE: /dev/sda: hpt45x discovering
NOTICE: /dev/sda: isw discovering
NOTICE: /dev/sda: isw metadata discovered
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi discovering
NOTICE: /dev/sda: nvidia discovering
NOTICE: /dev/sda: pdc discovering
NOTICE: /dev/sda: sil discovering
NOTICE: /dev/sda: via discovering
NOTICE: /dev/sdc: asr discovering
NOTICE: /dev/sdc: ddf1discovering
NOTICE: /dev/sdc: hpt37x discovering
NOTICE: /dev/sdc: hpt45x discovering
NOTICE: /dev/sdc: isw discovering
NOTICE: /dev/sdc: isw metadata discovered
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi discovering
NOTICE: /dev/sdc: nvidia discovering
NOTICE: /dev/sdc: pdc discovering
NOTICE: /dev/sdc: sil discovering
NOTICE: /dev/sdc: via discovering
NOTICE: /dev/sdd: asr discovering
NOTICE: /dev/sdd: ddf1discovering
NOTICE: /dev/sdd: hpt37x discovering
NOTICE: /dev/sdd: hpt45x discovering
NOTICE: /dev/sdd: isw discovering
NOTICE: /dev/sdd: isw metadata discovered
NOTICE:
Bug#722077: calypso: Should refer to homepage of project (not of author)
Package: calypso Severity: minor Hi, Calypso packaging refer to http://keithp.com/ as homepage. I believe that to be wrong - that Homepage: field is describing the _project_, not the author. I.e. that it should instead be http://keithp.com/calypso/. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534641: [ptex:00352] Re: mendex bug
Hi Norbert, Ahh, maybe the intended rewrite was to have sprintf(TAIL(tmpbuff),%s%s%s,encap_prefix,ind.p[j].enc,encap_infix); sprintf(TAIL(tmpbuff),%s%s%s,ind.p[j].page,encap_suffix,delim_n); then it would work I guess that is the better fix. I also think so. Thanks, Akira -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721832: Pending fixes for bugs in the libconfig-model-dpkg-perl package
tag 721832 + pending thanks Some bugs in the libconfig-model-dpkg-perl package are closed in revision 01fbd46d22701923de22326c94396cb524c08476 in branch 'master' by Dominique Dumont The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libconfig-model-dpkg-perl.git;a=commitdiff;h=01fbd46 Commit message: DpkgSyntax: fix white space issue (Closes: #721832) by ... deprecating write_dpkg_section for format_dpkg_section -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722078: frozen-bubble: unable to change graphics to full-screen via GUI
Package: frozen-bubble
Version: 2.212-3
Severity: normal
Dear Maintainer,
I recently installed frozen-bubble. I wanted to change the graphics to
full-screen from window but wasn't able to via the GUI. I saw the
following in ~/.frozen-bubble
~/.frozenbubble$ cat rc
$fullscreen = undef;
$graphics_level = 1;
$mynick = 'shirish';
$music_disabled = undef;
$mixer_enabled = 1;
$mylatitude = undef;
$mylongitude = undef;
$KEYS = {
'p2' = {
'left' = 120,
'right' = 118,
'fire' = 99,
'center' = 100
},
'p1' = {
'left' = 276,
'right' = 275,
'fire' = 273,
'center' = 274
},
'misc' = {
'toggle_music' = 292,
'send_malus_to_rp1' = 282,
'send_malus_to_rp2' = 283,
'chat' = 13,
'lower_volume' = 269,
'send_malus_to_rp3' = 284,
'send_malus_to_all' = 291,
'send_malus_to_rp4' = 285,
'next_playlist_elem' = 9,
'toggle_sound' = 293,
'fs' = 102,
'save_record' = 316,
'raise_volume' = 270
}
};
As can be seen $fullscreen = undef; maybe I just need to change it to
$fullscreen = 1; for it to work .
What I'm unable to understand is why the graphics is not responding
via the GUI ?
Looking forward for answers.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (600, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages frozen-bubble depends on:
ii frozen-bubble-data 2.212-3
ii libalien-sdl-perl 1.440-1
ii libc6 2.17-92+b1
ii libcompress-bzip2-perl 2.16-1
ii libglib2.0-02.36.4-1
ii liblocale-gettext-perl 1.05-7+b1
ii libsdl-mixer1.2 1.2.12-8
ii libsdl-pango1 0.1.2-6
ii libsdl-perl 2.540-2
ii libsdl1.2debian 1.2.15-6
ii perl5.14.2-21
ii perl-base [perlapi-5.14.2] 5.14.2-21
frozen-bubble recommends no packages.
frozen-bubble suggests no packages.
-- no debconf information
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722079: hello: Please provide a deterministic Build ID
Package: hello Version: 2.8-4 Severity: wishlist Tags: patch Hi! In the quest to get deterministic/reproducible builds [1], I have noticed that the result of building hello currently varies according to its build path. The attached patch use the debugedit tool to prevent such variation by relocating the source associated with the debug data to a deterministic path. It also adds `-fno-merge-debug-strings` to the CFLAGS, because the resulting .debug_str section will be different depending on the initial input strings. This behaviour should eventually be fixed at the compiler level. [1] http://wiki.debian.org/ReproducibleBuilds Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Naur a/debian/control b/debian/control --- a/debian/control 2011-08-04 13:07:58.0 +0200 +++ b/debian/control 2013-09-07 15:18:45.29439 +0200 @@ -2,6 +2,7 @@ Section: devel Priority: optional Maintainer: Santiago Vila sanv...@debian.org +Build-Depends: debugedit | rpm (= 4.7.0-3) Standards-Version: 3.9.2 Homepage: http://www.gnu.org/software/hello/ diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2013-08-16 09:36:35.0 +0200 +++ b/debian/rules 2013-09-07 15:09:36.755619230 +0200 @@ -10,7 +10,7 @@ package = hello docdir = debian/tmp/usr/share/doc/$(package) -CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall +CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall -fno-merge-debug-strings LDFLAGS := `dpkg-buildflags --get LDFLAGS` CPPFLAGS := `dpkg-buildflags --get CPPFLAGS` @@ -34,6 +34,8 @@ STRIP = $(stripcmd) --remove-section=.comment --remove-section=.note endif +DEBUGEDIT = /usr/lib/rpm/debugedit + build: ./configure CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) \ LDFLAGS=$(LDFLAGS) $(confflags) --prefix=/usr @@ -54,6 +56,7 @@ rm -rf debian/tmp install -d debian/tmp/DEBIAN $(docdir) $(MAKE) prefix=$$(pwd)/debian/tmp/usr install + $(DEBUGEDIT) -b $(dir $(realpath $(CURDIR))) -d /usr/src/debug -i debian/tmp/usr/bin/hello $(STRIP) debian/tmp/usr/bin/hello cp -a NEWS debian/copyright $(docdir) cp -a debian/changelog $(docdir)/changelog.Debian signature.asc Description: Digital signature
Bug#722080: gtg: Fuzzy dates are no longer kept relative to today
Package: gtg
Version: 0.3-2
Severity: normal
Tags: patch
0.3 introduced a regression where fuzzy dates (mostly now and soon)
are no longer kept relative to the current date, but remain at the value
they were initialized with at startup. (Thus somehow defeating their
purpose, if gtg is left running for long periods.)
Attached is a simple patch restoring the proper behavior.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.10-1-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Bri=C3=A8re?= fbri...@fbriere.net
Date: Tue, 27 Aug 2013 17:58:49 -0400
Subject: Keep fuzzy dates relative to today
This partially reverts a change brought in by revision 1176.2.2.
Apparently, pylint considers these lambdas useless, but they are
necessary to keep fuzzy dates (mostly now/soon) relative to the current
date.
---
GTG/tools/dates.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/GTG/tools/dates.py b/GTG/tools/dates.py
index 5e3dbe7..14270e8 100644
--- a/GTG/tools/dates.py
+++ b/GTG/tools/dates.py
@@ -61,10 +61,10 @@ LOOKUP = {
}
# functions giving absolute dates for fuzzy dates + no date
FUNCS = {
-NOW: datetime.date.today(),
-SOON: datetime.date.today() + datetime.timedelta(15),
-SOMEDAY: datetime.date.max,
-NODATE: datetime.date.max - datetime.timedelta(1),
+NOW: lambda: datetime.date.today(),
+SOON: lambda: datetime.date.today() + datetime.timedelta(15),
+SOMEDAY: lambda: datetime.date.max,
+NODATE: lambda: datetime.date.max - datetime.timedelta(1),
}
# ISO 8601 date format
@@ -121,7 +121,7 @@ class Date(object):
def date(self):
Map date into real date, i.e. convert fuzzy dates
if self.is_fuzzy():
-return FUNCS[self._fuzzy]
+return FUNCS[self._fuzzy]()
else:
return self._real_date
Bug#721670: Pending fixes for bugs in the libconfig-model-dpkg-perl package
tag 721670 + pending thanks Some bugs in the libconfig-model-dpkg-perl package are closed in revision 7b5225cd7abf5c6a8ea69d747989057d0d94cc2a in branch 'master' by Dominique Dumont The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libconfig-model-dpkg-perl.git;a=commitdiff;h=7b5225c Commit message: copyright backend: append second occurrence of a string entry (Closes: #721670) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722079: hello: Please provide a deterministic Build ID
El 07/09/13 17:04, Jérémy Bobbio escribió: Package: hello Version: 2.8-4 Severity: wishlist Tags: patch Hi! In the quest to get deterministic/reproducible builds [1], I have noticed that the result of building hello currently varies according to its build path. The attached patch use the debugedit tool to prevent such variation by relocating the source associated with the debug data to a deterministic path. It also adds `-fno-merge-debug-strings` to the CFLAGS, because the resulting .debug_str section will be different depending on the initial input strings. While I can agree that reproducible builds is a good thing (I added gzip -n recently), the proposed patch makes debugedit to be build-essential and it looks like an awfully horrible hack. This behaviour should eventually be fixed at the compiler level. Or maybe just s/eventually// -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722081: vim 7.4.000 segfaults with syntax on and Ruby file
Package: vim Version: 2:7.4.000-1+b1 Severity: important Procedure for reproducing segmentation fault is following. $ export LANG=ja_JP.UTF-8 $ export LC_MESSAGES=C $ printf %80s /tmp/a.rb ## just create a .rb suffix file, ## which contains 80 spaces, in 1 line $ sha1sum /tmp/a.rb ba2555be6600ef18ab04bfb2406f75313eedeab3 /tmp/a.rb $ vim -u NORC -U NORC -c syntax on -N /tmp/a.rb Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault Without -c syntax on, vim run correctly. This bug is fixed in upstream version 7.4.003, so please apply 7.4.003 patch. * https://groups.google.com/forum/#!topic/vim_dev/OOK6O0oxokA * ftp://ftp.vim.org/pub/vim/patches/7.4/7.4.003 -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk /usr/bin/vim is /usr/bin/vim.gtk /usr/bin/gvim is /usr/bin/vim.gtk -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim depends on: ii libacl1 2.2.52-1 ii libc62.17-92+b1 ii libgpm2 1.20.4-6.1 ii libselinux1 2.1.13-2 ii libtinfo55.9+20130608-1 ii vim-common 2:7.4.000-1+b1 ii vim-runtime 2:7.4.000-1 vim recommends no packages. Versions of packages vim suggests: pn ctagsnone pn vim-doc none pn vim-scripts 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#722082: darktable needs libcolord1, but is not installed by default
Package: darktable Version: 1.2.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, libcolord1 is a required dependency for darktable. However, libcolord1 is not installed automatically by APT in Debian testing. Therefore, a default installation of darktable results in an error message upon launch: darktable: error while loading shared libraries: libcolordprivate.so.1: cannot open shared object file: No such file or directory The solution, is of course, just to install libcolord1: sudo apt-get install libcolord1 and then, there is no issue with using darktable. However, this should be included as a dependency and done automatically. Thank you very much for your contributions! Regards Akarsh -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages darktable depends on: ii gtk2-engines 1:2.20.2-2 ii libatk1.0-0 2.4.0-2 ii libc6 2.17-3 ii libcairo2 1.12.2-3 ii libcolord11.0.2-1 ii libcurl3-gnutls 7.30.0-1 ii libexiv2-12 0.23-1 ii libflickcurl0 1.24-1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 8.0.5-4 ii libglib2.0-0 2.36.4-1 ii libglu1-mesa [libglu1]8.0.5-4 ii libgnome-keyring0 3.4.1-1 ii libgomp1 4.7.2-5 ii libgphoto2-2 2.4.14-2 ii libgphoto2-port0 2.4.14-2 ii libgtk2.0-0 2.24.10-2 ii libice6 2:1.0.8-2 ii libilmbase6 1.0.1-6 ii libjpeg8 8d-1 ii libjs-prototype 1.7.1-3 ii libjs-scriptaculous 1.9.0-2 ii libjson-glib-1.0-00.14.2-1 ii liblcms2-22.2+git20110628-2.2 ii liblensfun0 0.2.5-2 ii libopenexr6 1.6.1-7 ii libpango-1.0-01.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpng12-01.2.49-4 ii librsvg2-22.36.1-1 ii libsdl1.2debian 1.2.15-5 ii libsm62:1.2.1-2 ii libsoup2.4-1 2.38.1-2 ii libsqlite3-0 3.7.16.2-1 ii libstdc++64.7.2-5 ii libtiff5 4.0.2-6 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxml2 2.8.0+dfsg1-7+nmu1 ii zlib1g1:1.2.7.dfsg-13 darktable recommends no packages. darktable suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722079: hello: Please provide a deterministic Build ID
Hi! Santiago Vila: In the quest to get deterministic/reproducible builds [1], I have noticed that the result of building hello currently varies according to its build path. […] While I can agree that reproducible builds is a good thing (I added gzip -n recently), the proposed patch makes debugedit to be build-essential and it looks like an awfully horrible hack. This behaviour should eventually be fixed at the compiler level. Or maybe just s/eventually// Thanks for pushing me to look at other solutions. After poking some more at GCC and its documentation, I came up with the attached patch. It only adds two new switches to the CFLAGS: `-fdebug-prefix-map=` to adjust the source path and `-gno-record-gcc-switches` to prevent the difference in `-fdebug-prefix-map=` values from affecting the output. Does that sound more acceptable to you? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2013-08-16 09:36:35.0 +0200 +++ b/debian/rules 2013-09-07 15:09:36.755619230 +0200 @@ -10,7 +10,7 @@ package = hello docdir = debian/tmp/usr/share/doc/$(package) -CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall +CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall -fdebug-prefix-map=$(dir $(realpath $(CURDIR)))=/usr/src/debug/ -gno-record-gcc-switches LDFLAGS := `dpkg-buildflags --get LDFLAGS` CPPFLAGS := `dpkg-buildflags --get CPPFLAGS` signature.asc Description: Digital signature
Bug#721672: Pending fixes for bugs in the libconfig-model-dpkg-perl package
tag 721672 + pending thanks Some bugs in the libconfig-model-dpkg-perl package are closed in revision 00c92946a76494d02a83bc3f1397ae5e0542d719 in branch 'master' by Dominique Dumont The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libconfig-model-dpkg-perl.git;a=commitdiff;h=00c9294 Commit message: copyright: convert File section into Files (Closes: #721672) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721885: Applied to upstream.
control: tags -1 + fixed-upstream Thank you very much for the patch, pushed it into upstream git. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722083: [libedit2] partial sentences in extended description
Package: libedit2 Version: 3.1-20130712-2 Severity: minor The extended description reads: Command line editor library provides generic line editing, history, and tokenization functions. It slightly resembles GNU readline The last sentence is simply missing a period. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722079: hello: Please provide a deterministic Build ID
El 07/09/13 18:27, Jérémy Bobbio escribió: After poking some more at GCC and its documentation, I came up with the attached patch. It only adds two new switches to the CFLAGS: `-fdebug-prefix-map=` to adjust the source path and `-gno-record-gcc-switches` to prevent the difference in `-fdebug-prefix-map=` values from affecting the output. Does that sound more acceptable to you? It would be more acceptable, yes, but IMHO your target example package should be hello-debhelper, which uses dh, not hello. [ In fact, I'm actually planning to rename hello as hello-traditional and hello-debhelper as just hello at the next upstream release ]. If you have to change *anything* in hello-debhelper to achieve your goal, you can reasonably assume that you will potentially have to change each and every package, which would be insane. Depending on the changes you make to things like gcc and dpkg-dev first, the amount of changes in other packages could be a lot smaller. In other words, I see a great difference between A and B, being: A) You have to change each and every package. B) Ypu only have to change each and every package which does *not* use dh/cdbs/etc. I wish you luck in both cases but I think your goal will be a lot easier to achieve if you avoid A and try B first. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722084: lintian: [checks] Add Ruby pkg team checks to lintian
Package: lintian
Version: 2.5.17
Severity: wishlist
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Lintian-Maintainer,
we the Debian Ruby Team would like to add some lintian checks for the Ruby
packages.
Please see attched patch.
Acknowledgment of Ruby pkg team:
https://lists.debian.org/debian-ruby/2013/09/msg00011.html
Would you please include that checks into the next release of Lintian?
Thanks,
Jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJSK1uhAAoJEPBM7/YBbP/Q/9UQAIIJmBSs8bRylgiBtDIHbTBV
fFIx4izdXftexvXgpOf8SnurNGov69+MD20SaCNzVnDyWojh1D290WJYjogsTUnv
Xv8o6eNxXecgmJW2QYEXRLVF4LcEycscrKvL7o7g0OrPh4cff2CQvbZkMCsDkXrR
6donOzgOneRVAlAUgi7jtMmY2qUOwW3mwUvqIXPYyHHo22eFzZvSIwyTk3ik8viS
ki8YqClfdPioH0S0xq8coBXw5fmc4J7EucNQzD0UjjFflxEQ1HRMw2jSbVyIlrTu
np7ZNMhWx1h+idffwSF4nDQr1clb3iE/xKO00HBvI7ghlvsiFVyeeSbAugWfoDp6
qAGuvmAeDoVd/pqSRwxLp8HiWC7kzRqTCxcealX1QcDkaUPnNiEpPekqAfWzq6H6
H3t+xkeNRcsw3HCzg+3xobv7qOlm9NmPPbm3ocb2hVsUVqtulCovdvLuGfoSGkOK
mPifkrckWd/YvWteeGPSjmEzbof+4YiCLmLYHgf6jEaquu92sBjJBVMqtynU9zaY
saKXVg5Z5mZVbeHbJ4bTGM/GMqR9XQtzK365/MsiFNJl3OaSFjdUTb95EqoDS935
o8+Ad2Qmof354qOwUNn7iyNsYhugYR5RKJ4R6b3k7CpaFrVAtJThnL0BEwnMkPw+
L/EO/GneA+9MAflc8ciq
=BJSu
-END PGP SIGNATURE-
From d7a2bb97de6be5f125cbbd7d72ada75e95fa53be Mon Sep 17 00:00:00 2001
From: Jonas Genannt jo...@brachium-system.net
Date: Sat, 7 Sep 2013 18:52:44 +0200
Subject: [PATCH] added Ruby pkg team checks
---
checks/ruby.desc | 36
checks/ruby.pm | 39 +++
profiles/debian/main.profile |2 +-
3 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 checks/ruby.desc
create mode 100644 checks/ruby.pm
diff --git a/checks/ruby.desc b/checks/ruby.desc
new file mode 100644
index 000..f635090
--- /dev/null
+++ b/checks/ruby.desc
@@ -0,0 +1,36 @@
+Check-Script: ruby
+Author: Jonas Genannt jonas.gena...@capi2name.de
+Type: binary
+Info: Checks various Ruby PKG Team stuff
+Needs-Info: bin-pkg-control, index, scripts, unpacked
+
+Tag: ruby-depends-on-ruby1.8
+Severity: serious
+Certainty: certain
+Info: This package depends on ruby1.8, but ruby 1.8 is at its end of life.
+ Please check your package against newer Ruby versions and update your
+ dependencies to ruby | ruby-interpreter, or in the worst case, to a newer
+ Ruby version.
+ .
+ https://wiki.debian.org/Teams/Ruby/Packaging
+
+Tag: ruby-depends-on-specific-ruby-version
+Severity: normal
+Certainty: certain
+Info: This package depends on a specific ruby version.
+ Packages should not depend on a specific ruby version if possible, because
+ this makes it harder to drop support for obsolete Ruby versions. Ideally
+ packages should declare a dependency on Ruby using a generic
+ ruby | ruby-interpreter.
+ .
+ https://wiki.debian.org/Teams/Ruby/Packaging
+
+Tag: ruby-library-old-package-name-schema
+Severity: serious
+Certainty: certain
+Info: Your ruby library package name does not fit the Debian standards for Ruby.
+ The package name does not fit the current naming scheme for Ruby packages.
+ Ruby libraries should named like `ruby-foo`. Packages named libfoo-ruby* are
+ deprecated.
+ .
+ https://wiki.debian.org/Teams/Ruby/Packaging
diff --git a/checks/ruby.pm b/checks/ruby.pm
new file mode 100644
index 000..89f1987
--- /dev/null
+++ b/checks/ruby.pm
@@ -0,0 +1,39 @@
+package Lintian::ruby;
+
+use strict;
+use warnings;
+
+use Lintian::Collect::Binary ();
+use Lintian::Tags qw(tag);
+
+sub run {
+my $pkg = shift;
+my $type = shift;
+my $info = shift;
+
+if ($type eq 'binary') {
+
+my $pkg_description = $info-field('description');
+if ($pkg_description) {
+ if ($pkg =~ /^lib.*-ruby.*/ and !$info-is_pkg_class('transitional') ) {
+tag 'ruby-library-old-package-name-schema';
+ }
+}
+
+my $str_deps = $info-relation('strong');
+if ($str_deps and $str_deps-implies(ruby1.8)) {
+tag 'ruby-depends-on-ruby1.8';
+}
+
+if ($str_deps and $str_deps-matches(qr/^ruby[0-9.]+$/o) and !$str_deps-implies(ruby1.8)) {
+tag 'ruby-depends-on-specific-ruby-version';
+}
+}
+}
+
+1;
+# Local Variables:
+# indent-tabs-mode: nil
+# cperl-indent-level: 4
+# End:
+# vim: syntax=perl sw=4 sts=4 sr et
diff --git a/profiles/debian/main.profile b/profiles/debian/main.profile
index 336d1f0..2772c6a 100644
--- a/profiles/debian/main.profile
+++ b/profiles/debian/main.profile
@@ -8,6 +8,6 @@ Enable-Tags-From-Check: apache2, automake, binaries, changelog-file, changes-fil
infofiles, init.d, java, lintian, manpages, md5sums, menu-format, menus, nmu,
ocaml, patch-systems, phppear, po-debconf, rules, scripts, shared-libs,
source-copyright, standards-version, symlinks, systemd, testsuite,
- version-substvars, watch-file
+ version-substvars, watch-file, ruby
Disable-Tags:
Bug#722085: Connect to wiki.debian.org using IPv6 failed
Package: wiki.debian.org Severity: normal I can't connect to https://wiki.debian.org using IPv6. DNS record resolved successfully: $ host wiki.archlinux.org wiki.archlinux.org is an alias for alderaan.archlinux.org. alderaan.archlinux.org has address 78.46.78.247 alderaan.archlinux.org has IPv6 address 2a01:4f8:120:34c2::2 But I can't get content using IPv6 (wget freezing): $ wget -6 https://wiki.debian.org -O /dev/null --2013-09-07 20:58:42-- https://wiki.debian.org/ Resolving wiki.debian.org (wiki.debian.org)... 2001:41b8:202:deb:6564:a62:52c3:4b70 Connecting to wiki.debian.org (wiki.debian.org)|2001:41b8:202:deb:6564:a62:52c3:4b70|:443... connected. If I use IPv4: $ wget -4 https://wiki.debian.org -O /dev/null --2013-09-07 21:01:04-- https://wiki.debian.org/ Resolving wiki.debian.org (wiki.debian.org)... 82.195.75.112 Connecting to wiki.debian.org (wiki.debian.org)|82.195.75.112|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: '/dev/null' [ = ] 19,892 --.-K/s in 0.09s 2013-09-07 21:01:05 (226 KB/s) - '/dev/null' saved [19892] But other IPv6 sites works fine: $ wget -6 http://google.com -O /dev/null --2013-09-07 21:03:01-- http://google.com/ Resolving google.com (google.com)... 2404:6800:4006:806::1006 Connecting to google.com (google.com)|2404:6800:4006:806::1006|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.google.com/ [following] --2013-09-07 21:03:02-- http://www.google.com/ Resolving www.google.com (www.google.com)... 2607:f8b0:4000:809::1014 Connecting to www.google.com (www.google.com)|2607:f8b0:4000:809::1014|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.ru/?gws_rd=crei=01wrUtDWFei42wXWnIGAAg [following] --2013-09-07 21:03:03-- http://www.google.ru/?gws_rd=crei=01wrUtDWFei42wXWnIGAAg Resolving www.google.ru (www.google.ru)... 2404:6800:4007:803::101f Connecting to www.google.ru (www.google.ru)|2404:6800:4007:803::101f|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: '/dev/null' [ = ] 10,976 26.9KB/s in 0.4s 2013-09-07 21:03:04 (26.9 KB/s) - '/dev/null' saved [10976] -- System Information: Debian Release: 6.0.7 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722058: [kde-config-touchpad] kde-config-touchpad: reports errors and tapping doesn't work with xserver-xorg-input-synaptics 1.7.1 in unstable
Package: kde-config-touchpad Version: 0.8.1-1 --- Please enter the report below this line. --- Same behaviour here, but normal tapping works if are configured in /etc/X11/xorg.conf.d/50-synaptiks.conf If I try to execute from a console using synaptiks command, it starts and seems to work, except when try to go to configure synaptiks from systray icon, it shows a slightly different error message: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/synaptiks/kde/trayapplication.py, line 241, in show_configuration_dialog self.touchpad, self.touchpad_manager, self._config) File /usr/lib/python2.7/dist-packages/synaptiks/kde/trayapplication.py, line 74, in __init__ self.touchpad_config, self) File /usr/lib/python2.7/dist-packages/synaptiks/kde/widgets/touchpad.py, line 226, in __init__ self._setup(self.touchpad_config) File /usr/lib/python2.7/dist-packages/synaptiks/kde/widgets/config.py, line 97, in _setup self.load_configuration() File /usr/lib/python2.7/dist-packages/synaptiks/kde/widgets/config.py, line 220, in load_configuration self._update_widgets_from_mapping(self.__config) File /usr/lib/python2.7/dist-packages/synaptiks/kde/widgets/config.py, line 172, in _update_widgets_from_mapping value = mapping[config_key] File /usr/lib/python2.7/dist-packages/synaptiks/config.py, line 248, in __getitem__ value = getattr(self.touchpad, key) File /usr/lib/python2.7/dist-packages/synaptiks/touchpad.py, line 106, in __get__ values = obj[self.property_name] File /usr/lib/python2.7/dist-packages/synaptiks/x11/input.py, line 552, in __getitem__ atom = _get_property_atom(self.display, name) File /usr/lib/python2.7/dist-packages/synaptiks/x11/input.py, line 180, in _get_property_atom raise UndefinedPropertyError(name) synaptiks.x11.input.UndefinedPropertyError: u'Synaptics Tap FastTap' --- System information. --- Architecture: amd64 Kernel: Linux 3.10-10.dmz.1-liquorix-amd64 Debian Release: jessie/sid 950 unstableftp.deb-multimedia.org 900 unstableftp.debian.org 800 experimentalftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+-== python2.7 | 2.7.5-7 OR python2.6 | 2.6.8-1.1 python (= 2.6.6-7~) | 2.7.5-4 python( 2.8) | 2.7.5-4 python-pyudev | 0.13-1 python (= 2.7) | 2.7.5-4 OR python-argparse| python-pkg-resources | 0.6.49-2 python-qt4(= 4.8) | 4.10.2-2 python-kde4 (= 4:4.5) | 4:4.10.5-1+b1 libxi6 (= 2:1.4) | Recommends (Version) | Installed ==-+-=== libxtst6 | python-dbus| upower | Package's Suggests field is empty. signature.asc Description: This is a digitally signed message part.
Bug#458739: vgrabbj crashes frequently
Le 07/09/13 16:35, Folkert van Heusden a écrit : Hi What did you expect? A gdb backtrace ? A run inside valgrind as requested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458739#10 ? Or anything that would be informative enough to find the problem. It is OK if you do not know how to use gdb. Is it the case? Bye -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#458739: vgrabbj crashes frequently
Hmm did i miss those messages? Odd. Well yeah close it. I solved it by writing something myself (grabby and its successor koudevoeten). Op 7 sep. 2013 19:07 schreef Ludovic Rousseau ludovic.rouss...@gmail.com het volgende: Le 07/09/13 16:35, Folkert van Heusden a écrit : Hi What did you expect? A gdb backtrace ? A run inside valgrind as requested in http://bugs.debian.org/cgi-** bin/bugreport.cgi?bug=458739#**10http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458739#10? Or anything that would be informative enough to find the problem. It is OK if you do not know how to use gdb. Is it the case? Bye -- Dr. Ludovic Rousseau
Bug#650636: gephi debian package
Hi all, My intention was always to package Gephi under the banner of the Java team. Unfortunately the Netbeans platform is a dependency, and getting that in a good state (and keeping up with upstream releases) has been more challenging than I initially expected. When I started on this, the only Netbeans package was in non-free because it bundled jar files of its dependencies. I'm pretty much there on getting the latest Netbeans platform uploaded, although I do need some help with sponsering a few packages. A further complication is that since I last had a working Gephi package, the Gephi build system was updated to use Maven. Getting the relevant plugins packaged will also be needed, so that we can properly build against the Netbeans platform. Failing that, we'll need to heavily patch the Gephi build system, which doesn't sound like much fun... Anyway, if others are keen to work on this then we should try and make a plan, but be prepared to get stuck in with Maven packaging. Thanks, Andy On 06/09/13 07:10, Rogério Brito wrote: Hi there again. On Sep 02 2013, Rogério Brito wrote: I wonder if, somehow, changing to team-maintenance wouldn't be better for the package overall? Perhaps the highly skilled people that already package Java things for Debian may be interested in this? I'm CCing them. Otherwise, changing the status from ITP to RFP would free people to work on it instead of the deadlock here. After all, the original bug was filed on 1 Dec 2011 which will soon complete 2 years! (I almost did this without asking for other people's opinions). OK, I just went ahead and removed this ITP and owned thing. If that was premature, then just modify it again, but, please, keep the bug updated with events/progress of the packaging, so other people are not left wondering what the status of the packaging is and can actually work on the darned thing. Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722086: More suggested fixes from Ubuntu
Package: ibus Version: 1.5.3-5 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy Tags: patch Here's a few more suggested fixes. While GNOME and Unity users can use gnome-control-center for ibus preferences, I think users of other desktops may need to continue to use ibus-setup. I don't think ibus-xx-setup-frequent-lang.patch works since it's patching a gconf schema which isn't installed. If you depend on gsettings-desktop-schemas, perhaps you could use gsettings org.gnome.desktop.input-sources show-all-sources if you want to rewrite the patch. Thanks, Jeremy - -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), (100, 'saucy-backports') 0003-Drop-ibus-xx-setup-frequent-lang.patch.patch Description: Binary data 0002-Restore-disable-silent-rules.patch Description: Binary data 0001-Simplify-dh_install-and-only-hide-ibus-setup-in-GNOM.patch Description: Binary data
Bug#721663: Pending fixes for bugs in the libconfig-model-dpkg-perl package
tag 721663 + pending thanks Some bugs in the libconfig-model-dpkg-perl package are closed in revision a36f395d3c60d8b34de729b3ddbb8d647797c463 in branch 'master' by Dominique Dumont The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libconfig-model-dpkg-perl.git;a=commitdiff;h=a36f395 Commit message: Control model: added support for XS-Testsuite (Thanks Stig) (Closes: #721663) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721696: marked as done (adds multiarch tags to files in /usr/lib/multiarch-triplet/ dir)
gedit-plugins (3.8.3-2) unstable; urgency=low
.
[ Jeremy Bicha ]
* Pass --no-ext-rename to dh_python3 and build-depend on minimum
dh-python version that supports that option (Closes: #721696)
FTR: you didn't have to add --no-ext-rename - multiarch paths are
already ignored by dh_python{2,3} - I tested it with gedit.
I added --no-ext-rename for cases where dh_python* doesn't do the right
thing. Adding it doesn't do any harm if you don't provide any public
extensions, though.
signature.asc
Description: Digital signature
Bug#708050: latex-beamer: includeonlylecture does not work anymore
Package: latex-beamer
Version: 3.24-1
Followup-For: Bug #708050
The bug appears to be know upstream:
https://bitbucket.org/rivanvx/beamer/issue/230/problem-with-lecture-command
In fact, the patch given by
https://bitbucket.org/rivanvx/beamer/commits/54309ceef997 solves it.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10.1 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages latex-beamer depends on:
ii dpkg1.17.1
ii latex-xcolor2.11-1.1
ii pgf 2.10-1
ii tex-common 4.04
ii texlive-latex-base 2013.20130905-1
latex-beamer recommends no packages.
latex-beamer suggests no packages.
-- no debconf information
--- /usr/share/texmf/tex/latex/beamer/base/beamerbasesection.sty.orig 2013-09-07 19:18:53.308507780 +0200
+++ /usr/share/texmf/tex/latex/beamer/base/beamerbasesection.sty 2013-09-07 19:20:12.255509657 +0200
@@ -56,7 +56,7 @@
\ifx\beamer@onlylecture\@empty
\else
\expandafter\beamer@if@in@clist@TF\expandafter\beamer@onlylecture
- \beamer@currentlecturelabel
+ \expandafter{\beamer@currentlecturelabel}%
{\beamer@inlecturetrue}
{\beamer@inlecturefalse}
\fi
Bug#722082: darktable needs libcolord1, but is not installed by default
Control: tags -1 + moreinfo unreproducible On Sat, 2013-09-07 at 11:15 -0500, Akarsh Simha wrote: libcolord1 is a required dependency for darktable. However, libcolord1 is not installed automatically by APT in Debian testing. Therefore, a default installation of darktable results in an error message upon launch: The information included in your e-mail indicates that it's /already/ a dependency: Versions of packages darktable depends on: [...] ii libcolord11.0.2-1 How did you manage to install the package without also installing all of its dependencies? 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#722082: darktable needs libcolord1, but is not installed by default
Hi Adam All of its other dependencies were automatically installed. I just typed sudo apt-get install darktable, and it turns out it installed everything but for libcolord1 Regards Akarsh
Bug#694827: symlinks in the path
If a symlink is in the path of the chroot, the previous patch (see absolute_path.incorrect.patch.gz attached) fails. Here is a corrected version (see absolute_path.patch.gz). Such a failure is illustrated (with the previous patch applied) in example1. The failure doesn't occur with the new patch applied (see example2). Regards, JH Chatenet absolute_path.incorrect.patch.gz Description: Binary data absolute_path.patch.gz Description: Binary data me@here:~$ ls -AlF link_to_my_first_wheezy_chroot lrwxrwxrwx 1 me me 22 Sep 6 21:29 link_to_my_first_wheezy_chroot - my_first_wheezy_chroot/ me@here:~$ fakechroot fakeroot chroot link_to_my_first_wheezy_chroot # ls -AlF home/notme/link_to_my_second_wheezy_chroot lrwxrwxrwx 1 root root 23 Sep 6 21:29 home/notme/link_to_my_second_wheezy_chroot - my_second_wheezy_chroot/ # chroot home/notme/link_to_my_second_wheezy_chroot # echo $FAKECHROOT_BASE /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot # echo $LD_LIBRARY_PATH /home/me/link_to_my_first_wheezy_chroot/home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib: /home/me/link_to_my_first_wheezy_chroot/home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/lib: /home/me/my_first_wheezy_chroot/usr/lib/i386-linux-gnu/libfakeroot: /home/me/my_first_wheezy_chroot/usr/lib64/libfakeroot: /home/me/my_first_wheezy_chroot/usr/lib32/libfakeroot: /home/me/my_first_wheezy_chroot/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/usr/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/usr/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/usr/local/lib: /usr/lib/i386-linux-gnu/libfakeroot: /usr/lib64/libfakeroot: /usr/lib32/libfakeroot: /home/me/link_to_my_first_wheezy_chroot/usr/lib: /home/me/link_to_my_first_wheezy_chroot/lib: /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot/usr/lib: /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot/lib (breaking a long line at ':') There are two incorrect paths : /home/me/link_to_my_first_wheezy_chroot/home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/* which don't exist in the filesystem. me@here:~$ ls -AlF link_to_my_first_wheezy_chroot lrwxrwxrwx 1 me me 22 Sep 6 23:46 link_to_my_first_wheezy_chroot - my_first_wheezy_chroot/ me@here:~$ fakechroot fakeroot chroot link_to_my_first_wheezy_chroot # ls -AlF home/notme/link_to_my_second_wheezy_chroot lrwxrwxrwx 1 root root 23 Sep 6 23:45 home/notme/link_to_my_second_wheezy_chroot - my_second_wheezy_chroot/ # chroot home/notme/link_to_my_second_wheezy_chroot # echo $FAKECHROOT_BASE /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot # echo $LD_LIBRARY_PATH /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib/i386-linux-gnu/libfakeroot: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib64/libfakeroot: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib32/libfakeroot: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/home/notme/my_second_wheezy_chroot/usr/local/lib: /home/me/my_first_wheezy_chroot/usr/lib/i386-linux-gnu/libfakeroot: /home/me/my_first_wheezy_chroot/usr/lib64/libfakeroot: /home/me/my_first_wheezy_chroot/usr/lib32/libfakeroot: /home/me/my_first_wheezy_chroot/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/usr/lib/i386-linux-gnu: /home/me/my_first_wheezy_chroot/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/usr/lib/i486-linux-gnu: /home/me/my_first_wheezy_chroot/usr/local/lib: /usr/lib/i386-linux-gnu/libfakeroot: /usr/lib64/libfakeroot: /usr/lib32/libfakeroot: /home/me/link_to_my_first_wheezy_chroot/usr/lib: /home/me/link_to_my_first_wheezy_chroot/lib: /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot/usr/lib: /home/me/my_first_wheezy_chroot/home/notme/link_to_my_second_wheezy_chroot/lib (breaking a long line at ':') There is no incorrect path.
Bug#554945: Autoflushing of stdout is broken with perl 5.10
On Sat, Nov 07, 2009 at 03:05:23PM +0200, Eugene V. Lyubimkin wrote:
Hi Roger,
Roger Leigh wrote:
Package: perl
Version: 5.10.1-6
Severity: normal
This thread also describes the problem:
http://coding.derkeiler.com/Archive/Perl/comp.lang.perl.misc/2009-06/msg00035.html
Actually, the thread conclusion is the construction itself works. See three
last messages. Personally, I use STDOUT flushing in one of my Perl programs
and it works fine.
Moreover, this program which uses dup() works perfectly fine:
-8-
#!/usr/bin/perl -w
use strict;
use warnings;
use FileHandle;
use POSIX;
my $new_stdout = FileHandle-new_from_fd(dup(fileno(STDOUT)), 'w');
$new_stdout-autoflush(1);
while (1) {
print { $new_stdout } 'a';
sleep(1);
}
-8-
Can you construct a small program to reproduce?
Hi Roger,
Do you find that this is still an issue for you with current versions
of perl? With the lack of a reproducible test case there's not much
we can do about this report, so I would like to either get some more
information about the issue, or close the report.
Thanks!
Dominic.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704869: banshee: 2.6.1 also hangs when attaching android phone
Package: banshee Version: 2.6.1-2 Followup-For: Bug #704869 Dear Maintainer, I just did the update to the most recent version of banshee, the problem is still there. I am attaching the output of stdoutstderr: [Info 19:26:53.959] Running Banshee 2.6.1: [Debian GNU/Linux unstable (sid) (linux-gnu, x86_64) @ 2013-06-05 21:04:48 MYT] Fontconfig warning: /etc/fonts/conf.d/50-user.conf, line 9: reading configurations from ~/.fonts.conf is deprecated. Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 14: Having multiple values in test isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /etc/fonts/conf.d/65-ttf-sil-andika.conf, line 32: Having multiple family in alias isn't supported and may not work as expected (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkComponent) to class (__gtksharp_44_Hyena_Gui_BaseWidgetAccessible) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkTable) to class (__gtksharp_45_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_TrackInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkSelection) to class (__gtksharp_45_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_TrackInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkTable) to class (__gtksharp_51_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_Database_QueryFilterInfo+601+5b+5bSystem_String+2c+20mscorlib+2c+20Version+3d4_0_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3db77a5c561934e089+5d+5d+2c+20Banshee_Services+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkSelection) to class (__gtksharp_51_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_Database_QueryFilterInfo+601+5b+5bSystem_String+2c+20mscorlib+2c+20Version+3d4_0_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3db77a5c561934e089+5d+5d+2c+20Banshee_Services+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkTable) to class (__gtksharp_57_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_ArtistInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkSelection) to class (__gtksharp_57_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_ArtistInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkTable) to class (__gtksharp_63_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_YearInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkSelection) to class (__gtksharp_63_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_YearInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to add an interface (AtkTable) to class (__gtksharp_69_Hyena_Data_Gui_Accessibility_ListViewAccessible+601+5b+5bBanshee_Collection_AlbumInfo+2c+20Banshee_Core+2c+20Version+3d2_6_0_0+2c+20Culture+3dneutral+2c+20PublicKeyToken+3dnull+5d+5d) after class_init (Banshee:30437): GLib-GObject-WARNING **: attempting to
Bug#712712: gnash: Doesn't play YouTube's video of RMS singing the Free Software Song (or any other)
On Tue, Jun 18, 2013 at 11:24:23AM -0700, Kingsley G. Morse Jr. wrote: 4.) The first few frames are rendered, but then the video hangs. The gray status bar keeps creeping across the window, but the video hangs. I heard no sound. Please try 0.8.11~git20130903-2 uploaded few days ago. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722087: libreadline6: Home code for rxvt in inputrc
Package: readline-common Version: 6.2+dfsg-0.1 Severity: normal Tags: patch Existing inputrc has code for End but cod for home is missing. Patch attached that I think covers it. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages readline-common depends on: ii dpkg 1.17.1 ii install-info 5.1.dfsg.1-5 readline-common recommends no packages. readline-common suggests no packages. -- no debconf information inputrc-rxvt-home.patch Description: Binary data
Bug#722088: libx11: add mips64{,el} to symbols for 64 bit
Package: src:libx11 Version: 2:1.6.1-1 Tags: patch In symbols file of libx11, 64 bit architectures are specified to make it corrected. Here is a patch adding mips64 and mips64el to the 64bit architecture list. Thanks, Eleanor Chen mips64-is-64-bit.diff Description: Binary data
Bug#719176: owncloud-client: diff for NMU version 1.3.0+dfsg-1.1
tags 719176 + pending thanks Hi, I've prepared an NMU (diff attached) to fix this and will upload to DELAYED/7. Feel free to (ask me to) cancel or reschedule, or superseded with your own upload. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] diff -Nru owncloud-client-1.3.0+dfsg/debian/changelog owncloud-client-1.3.0+dfsg/debian/changelog --- owncloud-client-1.3.0+dfsg/debian/changelog 2013-08-15 23:37:05.0 + +++ owncloud-client-1.3.0+dfsg/debian/changelog 2013-09-07 17:41:13.0 + @@ -1,3 +1,10 @@ +owncloud-client (1.3.0+dfsg-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Don't run dh_sphinxdoc in an arch-dep build. (Closes: #719176) + + -- Iain Lane la...@debian.org Sat, 07 Sep 2013 17:41:01 + + owncloud-client (1.3.0+dfsg-1) unstable; urgency=low * New upstream release. diff -Nru owncloud-client-1.3.0+dfsg/debian/rules owncloud-client-1.3.0+dfsg/debian/rules --- owncloud-client-1.3.0+dfsg/debian/rules 2013-08-15 10:33:47.0 + +++ owncloud-client-1.3.0+dfsg/debian/rules 2013-09-07 17:45:21.0 + @@ -10,3 +10,6 @@ override_dh_auto_configure: dh_auto_configure --buildsystem=kde -- -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_SYSCONFDIR=/etc/owncloud -DCREATEDOC=ON -DWITH_DOC=ON + +# Only do this for an indep build +override_dh_sphinxdoc-arch:
Bug#722085: Please, delete this bug
It was my MTU problem. Sorry for that.
Bug#721996: [Pkg-xfce-devel] Bug#721996: thunar-volman: confirm XFCE bug #9193
On sam., 2013-09-07 at 18:34 +0200, Javier Cantero wrote: javier@hogwarts:~$ udisks --monitor Is udisks2 installed? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#722089: rectangle select slows gimp
Package: gimp Version: 2.8.2-2 The gimp slows noticably when I use the rectangle select tool. On my 1.9 GHz Pentium 4 machine, it is quite responsive doing tasks like changing the color balance of a 10 megapixel photo, but after selecting a region using the rectangle tool, it slows markedly. All gimp functions I have tried get slow, for example, opening a menu takes upwards of 5 seconds. Cursor movement remains responsive, although it can take a few seconds for the cursor symbol to update. Examining the running processes, 'gimp' looks okay but 'x' continuously uses about 85% of the CPU. Memory use looks okay. If I switch to another application, for example LibreOffice, that application is responsive. The gimp remains slow and x remains a CPU hog until I close the image or I dismiss the selection using the 'select none' command. One peculiar aspect, xcf files seem to preserve whatever causes the problem. If I save a file while the gimp is slow, then the gimp will slow again when I reopen the file. To demonstrate this, I created the attached example by opening the gimp, and created an empty image with the letter template. To make the image a little more interesting, I used the gradient tool to apply a conical gradient. The gimp showed almost no hesitation to any of these commands. Then I selected a small region with the rectangle tool and the gimp slowed. I patiently did a crop to selection to make the image smaller for your convenience. Then saved and closed the gimp. Then I opened the gimp with this small file. The gimp immediately becomes slow. Patiently open a 10 megapixel JPEG, whose window happens to cover the small image, and the gimp becomes responsive. Bring the window with the small image forward, and the gimp slows. Issue the 'select none' command and the gimp becomes responsive. Problem started when I upgraded from Debian 6.6 to 7.1. With 6.6, the gimp was responsive even with multiple ten-megapixel images open with multiple regions selected. I am running Debian 7.1 with pretty much standard desktop installation except xfce instead of gnome. kernel 3.2.0-4-686-pae libc6 2.13-38 X server-common 2:1.12.4-6 xfce4 4.8.0.3 gimp 2.8.2-2 Asus P4T 533-C Intel Pentium 4 478 1.9 GHz PNY Verto GeForce FX 5900SE AGP conical_crop_small.xcf Description: application/xcf
Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]
Le samedi 7 septembre 2013 09:51:28 Raphael Droz a écrit : I happened to be in a situation where I can't even fully flush the postfix queue without having Dspam to segfault. I end up installing dspam-dbg and gdb and attach to the process [I wasn't able to run the process without the init-script]. Symbols for libdspam7-drv-hash are found in libdspam7-dbg. Could you install it and give me stacktrace you get with it? Thanks a lot signature.asc Description: This is a digitally signed message part.
Bug#721677: gnome-user-share: Personal File Sharing GUI not accessable
I think I might be having this bug too. Don't know how much info I can provide. I'm running an amd64 Jessie destribution. Fresh installed in June (after the release of Wheezy). The command gnome-file-share-preferences (or something like that) doesn't exist. In another machine running Wheezy it lunches from the applications menu. By looking at the desktop file of the app I saw it points the above command and when I try to run that in Jessie, it doesn't exist. Or something has changed from the wheezy version up to now or this is a serious bug, which is preventing file-sharing at all. Don't know how much debugging info can I provide as there seems to be no runtime error, but a missing executable! Cheers
Bug#721858: apt-listdifferences: Per-package diff
On Wed, Sep 4, 2013 at 8:05 PM, Michael Welsh Duggan wrote: Michael Gilbert mgilb...@debian.org writes: On Wed, Sep 4, 2013 at 1:11 PM, Michael Welsh Duggan wrote: It would be nice if there were to option to, instead of putting the diff of all packages in a single pager, each package's diff would appear in a separate pager, and that quitting the first pager would bring up the second. Currently, it is difficult to look at diffs from a specific package when another package has a lot of changes. I'm not sure this would necessarily be better from a usability perspective. I think users would not like hitting q multiple times when they want to get out fast. Have you considered searching for the term diffstat? That puts you at the top of the next diff almost 100% of the time. There is no diffstat in the output I see. Rather, one patch just follows another: diff -Nru iproute2-3.10.0/tc/tc_qdisc.c iproute2-3.11.0/tc/tc_qdisc.c --- iproute2-3.10.0/tc/tc_qdisc.c 2013-07-16 13:06:36.0 -0400 +++ iproute2-3.11.0/tc/tc_qdisc.c 2013-09-03 11:23:03.0 -0400 @@ -137,15 +137,15 @@ [diff elided] diff -Nru libass-0.10.0/Changelog libass-0.10.1/Changelog --- libass-0.10.0/Changelog 2011-09-25 11:51:25.0 -0400 +++ libass-0.10.1/Changelog 2012-10-04 08:17:22.0 -0400 @@ -1,3 +1,17 @@ [diff elided] Hi, you don't see something like the following at the top of the output for each source package? diffstat for quilt-0.60 quilt-0.60 .pc/.quilt_patches |1 .pc/.quilt_series |1 .pc/.version|1 changelog | 15 ++- patches/select-mail | 103 patches/series |1 6 files changed, 117 insertions(+), 5 deletions(-) diff -Nru quilt-0.60/debian/changelog quilt-0.60/debian/changelog --- quilt-0.60/debian/changelog 2013-08-22 01:24:09.0 + +++ quilt-0.60/debian/changelog 2013-09-05 12:23:58.0 + [snip] apt-listdifferences should be calling debdiff with the --diffstat option, which generates that. I wonder if there is an issue with coloring that may be masking that. Can you try setting color=False in /usr/bin/apt-listdifferences? Also make sure debdiff --diffstat by itself works as expected on your machine. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721869: install appropriate linux-headers
On Fri, Sep 6, 2013 at 4:58 AM, Bjørn Mork bj...@mork.no wrote: Dmitrijs Ledkovs x...@debian.org writes: On 5 September 2013 20:58, Bjørn Mork bj...@mork.no wrote: Christian PERRIER bubu...@debian.org writes: Quoting Bjørn Mork (bj...@mork.no): So, it's probably less overkill than it may seem at first glance to imagine that installing headers by default may help in some cases. I hope and expect most Linux users never needing kernel headers. And if they do need them, then the headers should be pulled in by one of the -dkms packages. I do not think it is a good idea to encourage users or driver authors to keep drivers out of Debian. How does the dependency look like to get headers for the _currently_ running kernel and not the latest one available/installed? Considering I can upgrade to the new kernel packages a few times before rebooting. This is way outside what you can expect to be supported. I wouldn't worry about that. Users likely want to be using the latest kernel anyway, and if they for some reason aren't and submit a bug report about modules not working, they can be instructed to either reboot or install the linux-headers for their specific kernel version. Sitting on the outside here, I am puzzled to see this belief that Debian should support all sorts of user modifications to the kernel package. This isn't at all about modifying the kernel package itself. It is about building kernel modules available in many separate packages. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721521: fonts-urw-base35 and metrics
Hey Norbert, Am Freitag, den 06.09.2013, 11:52 +0900 schrieb Norbert Preining: I wanted to ask you one thing: Are the font *metrics* unchanged, thus a drop-in replacement of the Adobe fonts, and also a drop-in replacement for the previous URW fonts? Honestly, I haven't checked that yet. But I wouldn't be surprised to find some subtle differences. Actually, fixing some of the metrics to be more compatible to the original base fonts was the very reason for URW releasing the update. The point is, if we have to regenerate metrics on the TeX side, this will create havoc. That's the price of technological progress, if you are asking me. :) Cheers, - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711663: Pending fixes for bugs in the libgeo-googleearth-pluggable-perl package
tag 711663 + pending thanks Some bugs in the libgeo-googleearth-pluggable-perl package are closed in revision f47f0c1acf9d6ef59a1c17760f601cf98259e47a in branch 'master' by Dominic Hargreaves The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libgeo-googleearth-pluggable-perl.git;a=commitdiff;h=f47f0c1 Commit message: Depend/build-depend explicitly on Module::Pluggable which is being removed from perl in 5.20 (Closes: #711663) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722090: slapd: slapindex on back_mdb directory expands without limit, leading to failure
Package: slapd Version: 2.4.31-1+nmu2 Severity: normal Dear Maintainer, I just had to rebuild my LDAP directory because I made the mistake of trying to reindex my back_mdb data (after changing indexes in slapd.conf). The file grew until it hit its limit; increasing the limit did not solve this. This issue seems to be known and solved in upstream: http://www.openldap.org/lists/openldap-bugs/201209/msg00034.html Some solution to this should be backported, as using slapindex and mdb is a reasonable configuration that should work, especially on a stable Debian release. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages slapd depends on: ii adduser 3.113+nmu3 ii coreutils 8.13-3.5 ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38 ii libdb5.15.1.29-5 ii libgcrypt11 1.5.0-5+deb7u1 ii libgnutls26 2.12.20-7 ii libldap-2.4-2 2.4.31-1+nmu2 ii libltdl72.4.2-1.1 ii libodbc12.2.14p2-5 ii libperl5.14 5.14.2-21 ii libsasl2-2 2.1.25.dfsg1-6+deb7u1 ii libslp1 1.2.1-9 ii libwrap07.6.q-24 ii lsb-base4.1+Debian8+deb7u1 ii multiarch-support 2.13-38 ii perl [libmime-base64-perl] 5.14.2-21 ii psmisc 22.19-1+deb7u1 Versions of packages slapd recommends: ii libsasl2-modules 2.1.25.dfsg1-6+deb7u1 Versions of packages slapd suggests: ii ldap-utils 2.4.31-1+nmu2 -- Configuration Files: /etc/default/slapd changed: SLAPD_CONF= SLAPD_USER=openldap SLAPD_GROUP=openldap SLAPD_PIDFILE= SLAPD_SERVICES=ldap:/// ldaps:/// ldapi:/// SLAPD_SENTINEL_FILE=/etc/ldap/noslapd SLAPD_OPTIONS= -- debconf information: slapd/allow_ldap_v2: false slapd/password_mismatch: * slapd/invalid_config: true shared/organization: csclub.uwaterloo.ca slapd/upgrade_slapcat_failure: slapd/no_configuration: false slapd/move_old_database: true slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/purge_database: false slapd/domain: csclub.uwaterloo.ca slapd/backend: HDB slapd/dump_database: when needed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722057: libdspam7-drv-hash: dspam segfaults [libhash_drv on _hash_drv_seek()]
On Sat, Sep 07, 2013 at 08:33:21PM +0200, Thomas Preud'homme wrote: Le samedi 7 septembre 2013 09:51:28 Raphael Droz a écrit : I happened to be in a situation where I can't even fully flush the postfix queue without having Dspam to segfault. I end up installing dspam-dbg and gdb and attach to the process [I wasn't able to run the process without the init-script]. Symbols for libdspam7-drv-hash are found in libdspam7-dbg. Could you install it and give me stacktrace you get with it? thanks! sadly for now I've postsuper'ed -r ALL emails for now. But I installed libdspam7-dbg, relink postfix to dspam and I will need to wait for another email to come to mailman in order reproduce it. But could you offer me another reliable way to make Dspam dumps its core somewhere automatically instead of this situation where I'm waiting for hours through ssh with $ gdb pid-of-dspam ? thx -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
