Bug#680674: transition: leptonlib
On Wed, Jul 18, 2012 at 18:13:12 -0500, Jonathan Nieder wrote: Julien Cristau wrote: Agreed. Either this happens or leptonlib and friends get removed from wheezy, IMO. Thanks for looking it over. Is that a please go ahead or a yes, this is the right thing to do when the moment is right? The former. (No guarantees that it'll get into wheezy, but the chances of leptonlib releasing with wheezy are much higher if it's not rc buggy, so...) Cheers, Julien signature.asc Description: Digital signature
Bug#679665: [Pkg-javascript-devel] Bug#679665: jquery: build-deps not satisfiable in wheezy
On Thu, Jul 19, 2012 at 03:09:38 +0200, Jonas Smedegaard wrote: On 12-07-18 at 11:13pm, Julien Cristau wrote: diff -Nru jquery-1.7.2+debian/debian/links jquery-1.7.2+debian/debian/links --- jquery-1.7.2+debian/debian/links2010-03-16 01:32:42.0 +0100 +++ jquery-1.7.2+debian/debian/links2012-07-18 22:59:35.0 +0200 @@ -1,2 +1,3 @@ /usr/share/javascript/jquery/jquery.min.js /usr/share/javascript/jquery/jquery.pack.js /usr/share/javascript/jquery/jquery.min.js /usr/share/javascript/jquery/jquery.lite.js +/usr/share/javascript/jquery/jquery.js /usr/share/javascript/jquery/jquery.min.js Did you see my warnings about symlinks needing special care for some webserver setups? I must have missed that. No special care seems to be taken for the pack and lite symlinks, so I'm not sure what this is about. Cheers, Julien signature.asc Description: Digital signature
Bug#609047: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)
Hi,
Please CC replies to my email address. Thanks.
I have put my preliminary packaging of CCL on Bitbucket as a Mercurial
repository, located at https://bitbucket.org/faheem/ccl-debian-tmp
Please test and report problem and suggest improvements. For
preference, open an issue.
This packaging is relative to the recommened release checkout from
svn, i.e.
svn co http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl
per the documentation in
http://ccl.clozure.com/manual/chapter2.2.html#obtaining-via-svn
2.2.3.2.2. Downloading a Release Version
which appears to be equivalent to the tarball in
ftp://ftp.clozure.com/pub/release/1.8/ccl-1.8-linuxx86.tar.gz
Instructions for use:
i) Checkout out CCL sources from svn or download and unpack the tarball.
ii) Copy the cloned repository into the source directory as the debian/
subdirectory.
iii) Run
debuild binary
or a similar command in the source directory to produce the
binary. See `man debuild`.
This packaging should be considered preliminary, because it is not in
a form that would be acceptable for the Debian archives. The sources
above contain precompiled binaries for the x86 and amd64 archs. Since
CCL is not currently in the Debian archive, and since CCL requires
itself to compile. it is necessary to use precompiled binaries from
somewhere.
I was informed that the correct way to address this is to use the
source without any precompiled binaries, and have some adjunct binary
packages which contain necessary precompiled binaries which bootstrap
the compiler. More about this later.
I have some queries and comments about this packaging. I'll divide
this into Debian-specific and CCL-specific questions. So, the former
may be of interest to Debian people, and the latter to CCL people.
First, the Debian-specific questions.
1) I'd like to take over the outstanding ITP for CCL (#609047,
cc'd). I've written to Darren Ho, the creator of this ITP, on 1st July
2012, (see http://bugs.debian.org/609047), but have not yet received a
reply. What else do I need to do, if anything?
I guess I need to get a sponsor at some point. When should this happen?
2) The main outstanding issue is how to handle the bootstrapping
issue, namely that CCL is not in Debian, but requires CCL to compile.
R. Matthew Emerson wrote in the openmcl-devel mailing list
#
But, that said, what I myself actually do is this:
1. Check out the sources. I use the svn:// scheme so that I can
commit. (Note that the publicsvn component of the URL used for
the http: scheme is not used with the svn: scheme.)
svn co svn://svn.clozure.com/openmcl/trunk/source ccl
2. Get bootstrapping binaries from somewhere.
One way to get them is via the following checkout:
svn co --ignore-externals \
svn://svn.clozure.com/openmcl/trunk/linuxx86/ccl bootstrap cp
bootstrap/* ccl/
3. Get interface databases from somewhere.
cd ccl svn co svn://svn.clozure.com/openmcl/trunk/x86-headers svn
co svn://svn.clozure.com/openmcl/trunk/x86-headers64
###
It looks reasonable to me to divide up the build requirements into two
separate pieces, as Matthew suggests, namely the source, and second
the bootstrapping binaries and the interface database. However, I'm
not sure about the details of how this should be done. Some specific
questions.
First, it seems that the source should be the only thing in
*.orig.tar.gz, per usual Debian guidelines. From what I have read, it
seems that the other two items (binaries + interface databases) should
be in a separate special binary package (or packages). There would
be several of these packages to cover all the different archs.
I think Debian prefers pristine upstream tarballs, but I have also
seen versions of software get packaged, so I assume there is no
problem packaging the results of `svn co
svn://svn.clozure.com/openmcl/trunk/source` as *.orig.tar.gz.
As regards the binary stuff, I'm less clear what to do with it. The
idea would be just to stick the binaries + interface into a binary
(deb) package. So, does there need to be a corresponding
*.orig.tar.gz, *debian.tar.gz and *dsc to create this binary, or not?
Also, can I put both of these into one package? If so what should the
package be called? And where should the files live? Would a package
name like ccl-bootstrap, and location like /usr/lib/ccl-bootstrap/ be
Ok?
Now the CCL specific questions:
3) My current package description for the package is
##
Package: ccl
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: slime
Provides: lisp-compiler
Recommends: binfmt-support (= 1.1.2)
Description: Common Lisp compiler and development system
CCL is a development environment for the ANSI Common Lisp language.
It provides a native-code compiler and an
Bug#682047: Package the python binding of the libfko library
Package: fwknop Version: 2.0.0rc2-2 Severity: wishlist It should be nice to package the python binding of the libfko library. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653750: retitle - nightmare bug
On 2012-07-19 Regid Ichira regi...@yahoo.com wrote: --- On Wed, 7/18/12, Marc Haber wrote: retitle #653750 nightmare multi-bug about spec.txt - please do not report more issues here - file new bugs thanks Hello Regid, Do you think it would help if I will: 1. Copy the whole, multiple issues report, as a message to pkg-exim4-users. Just to have it archived. No need, the bug report is already archived. 2. close the bug. As you might have noticed I have gone through the whole report, picked up the valid issues and forwarded a patch upstream. It has been applied http://git.exim.org/exim.git/commit/a543079f3c7a2ca09a90a9728a9726439f33eb60, we will close the Debian bug once we include the patch in an upload to Debian. (Probably when packaging the new upstream release.) cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682048: wget corrupts ssl chunked transfer-encoded downloads
Package: wget
Version: 1.12-2.1
Severity: important
After running this command:
$ wget --no-check-certificate
https://www.lubemobile.com.au:2078/backup-7.19.2012_00-21-23_lubemobi.tar.gz
--user=redacted --password='redacted'
The file was downloaded was corrupt (it wasn't a valid gzip file).
Looking at it revealed this:
$ hd backup-7.19.2012_00-21-23_lubemobi.tar.gz | sed 1q
00 31 66 66 66 65 0d 0a 1f 8b 08 00 93 99 07 50 00 1fffe.P.
The leading 1fffe\r\n was suspicious. It looks like the content length
from a chunked http transfer (ie http header Transfer-Encoding: chunked).
Sure enough, the 1fffe\r\n insertion was repeated on every
0x1fffe+7==0x20007 byte byte boundary:
$ hd xxx | sed -n -e 8193p -e 16385,16386p -e 24578p
02 1a 5a f7 ae e4 0d 0a 31 66 66 66 65 0d 0a d7 59 .Z.1fffe...Y
04 6c 57 9d f7 b0 f2 90 42 7c da bd 95 0d 0a 31 66 lW.B|.1f
040010 66 66 65 0d 0a 03 99 f5 a5 dc 56 64 7c 9f 85 f8 ffe...Vd|...
060010 19 e6 47 0d 0a 31 66 66 66 65 0d 0a 8f a2 4a f0 ..G..1fffeJ.
MITM'ed the https connection to verify this was in fact the case:
000 c connect(('www.lubemobile.com.au', 2078))
000 s 'CONNECT www.lubemobile.com.au:2078 HTTP/1.0\r\n'
000 s 'User-Agent: Wget/1.12 (linux-gnu)\r\n'
'\r\n'
000 r 'HTTP/1.0 200 Connection established\r\n'
000 r '\r\n'
000 S 'GET /backup-7.19.2012_00-21-23_lubemobi.tar.gz HTTP/1.0\r\n'
000 S 'User-Agent: Wget/1.12 (linux-gnu)\r\n'
'Accept: */*\r\n'
'Host: www.lubemobile.com.au:2078\r\n'
'\r\n'
000 R 'HTTP/1.1 401 Unauthorized\r\n'
000 R 'Date: Thu, 19 Jul 2012 05:56:11 GMT\r\n'
'Server: cPanel\r\n'
'Content-Length: 23\r\n'
'Connection: Keep-Alive\r\n'
'WWW-Authenticate: Basic realm=cPanel WebDisk\r\n'
'Content-Type: text/plain\r\n'
'\r\n'
000 R 'Authentication Required'
000 C close()
000 S recv() EOF
001 c connect(('www.lubemobile.com.au', 2078))
001 s 'CONNECT www.lubemobile.com.au:2078 HTTP/1.0\r\n'
001 s 'User-Agent: Wget/1.12 (linux-gnu)\r\n'
'\r\n'
001 r 'HTTP/1.0 200 Connection established\r\n'
001 r '\r\n'
001 S 'GET /backup-7.19.2012_00-21-23_lubemobi.tar.gz HTTP/1.0\r\n'
001 S 'User-Agent: Wget/1.12 (linux-gnu)\r\n'
'Accept: */*\r\n'
'Host: www.lubemobile.com.au:2078\r\n'
'Authorization: Basic redacted\r\n'
'\r\n'
001 R 'HTTP/1.1 200 OK\r\n'
001 R 'Date: Thu, 19 Jul 2012 05:56:15 GMT\r\n'
'Server: cPanel\r\n'
'Connection: Keep-Alive\r\n'
'Transfer-Encoding: chunked\r\n'
'Accept-Ranges: bytes\r\n'
'Content-Type: application/download\r\n'
'Last-Modified: Thu, 19 Jul 2012 05:22:46 GMT\r\n'
'\r\n'
001 R
'1fffe\r\n\x1f\x8b\x08\x00\x93\x99\x07P\x00\x03\xec\xfd]\xb7\xa6\xd7u\x9f\xf9\xe9T\xfc\x14\x15\x8d\x1c\xf4\x1b\x80g\xceu\xbf-6\xcd\x8e\xdaV\x92\x1e\xc3\x96\x1dK\xdd\xa3;\'\x1c
Q4\x11\x81\x00\x03\x80\xa2\x95\x83|\xf6\xcc\xfb\x99\x0f6!\xadK\x12.*\r\xabm\x949,\x89\x00/\x02\xab\xd6\xc2\x7fW\xd5\xde\xbf\xfa\xf9\xc7\xbf\xf8\xab\xdf\xfe\xe6\x83\xf3\xc3\x98\x1f\xe6#\xf2g\x8f\xc7\x07\x19\x1f\xe4\xf8\xd9g\xbf\xfd\xf9\xfb_\x7f\xf1\xf3O?\xfa\xa3\x7f\xea\xb7G};\xf7\xc7\xf3\x7f\xd6\xb7\xfb\x7f\xc6\xd8\xcfo\xfe\xef\xe7\xbf\x17Y\xff\xe6\x19\xdb\x91\xe3\x8f\x1e\xb1o[\xfc\xd1\xbb\xfd\x9f\xfc\xdf\xfc\x1d\xbe\xfd\xf6\xab\xaf?\xfe\xf2\xdd\xbb?\xfa\xf2\x8b/\xbe\xfe\x87\xfe\xbco\x8e\xe3\xfb\xf8k\xfa\x1e\xbf\xfd\xfc\x1f\xff\xfe\xff\xea\xab\xcf~\xf1\xfe\xcb\xaf\xbf\xfa\x83/\xc2\xf3\xfb\xff\xf1\xb7\xbe\xff\xeb;;\xf1\xfb\x7f\x7f~\xff\x1f\xfbq\xfc3\xfb\xfe\xff\xdd\xaf\xde\xbf\xff\xec\xfb\xf8\x0b\xfa~\xbf}\x87\xef\xff\xcf\xbf\xf8\xf9\x17\x9f\xfc\xcd/?\xfd\xec\xfdW\x7f\xd8\x7f\xc7\xfd\x1d||\xc7\xe
f\xff#\xb6?\xba\xff\x97}\xff\xa3w\x8f\xff\xff\xfe\xad\xf2\xb7\x1f\xbe\xff\xff\xb1\xef\xff_\xbf\xff\xfa\xe3\x7f\xd2\x08\x98\xf7\xdf\xdf\xff\xfb\xb1\x8f\x1f\xde\xff\xf7\xf1\xed\xbb~\xff\x7f\xf2\xf3_\x7f\xfc\x9b\x0f\xff\xe6\xe3_\xff\x01g\xf0|\xff\xdb\xf6\xb7\xbf\xff\x7f\xff?\x1f\xfb\xbe\xfdQ\xc4v\xea;?\x8f\xfb\x9f\xff\xe7\x9e\xdb?\xb3\xf7\xff\x8f\xfd\xf1\xff\x83~\xfb\xe0\x83\x0f\xde\xfd\xe8\xdf\xfco\x7f\xf1\xff\xf8\xd7?~\xf7\xa3w\xef\xf9\xf9W\xcf\xff\xf9\xee\xdd7\xdf\xfd?\xfb\xf9g_\xfc\x87\x1f\xbf\x8bs\xfb\xb0\xde\xe8\x87\xb9\x8d\x0f\xe3\xc8\xbf\xfd\xa7|\xf3\xbf|\xf6\x9e\xfe\xc4O~\xfe\xdb\xaf\xde\x7f\xf9\xf7t\x9f\xff\xde\xb7\xff{\xbf\xe3\x7f\xf7\xbbw\xd5\xfc\xeb\xf7_~\xb7\xbf\xb2\x7f\xec\xbf\xe7\x1f\xfe\x1b\xf8\x87\xff\xdb\xbe\xf8\xdd\xe7\xf7\x1f\xf8\xf1\xa3\xbf\xff\xcf\xfdO\xfd}M\xdf\xbe\xeb\xfb\xff\xf5\xc7\x9f~\xd6\x7f_\xfe\xbf\x03\xdf\xff\xb7\xff\xf9\x1f\x7f\xf7\xe3\xbf\xf3\xdc\xce\x7ff\xef\xff?\xd3\x7f\xfe\x7f\xf2\xc5_\xbf\xff\xc5\x17_\xff\xb3\xbc\x9b?|\xfb\xdf\xff\xdbw}
Bug#681960: closed by Scott Kitterman sc...@kitterman.com (Bug#681960: fixed in clamav 0.97.5+dfsg-4)
On 2012-07-19 05:36, Debian Bug Tracking System wrote: * Add /var/run/clamav to directories shipped by clamav-base so dpkg cleanup will work for it too. That won't work. /var/run is a volatile file system. Any directory you use there needs to be created by an initscript. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682045: libtool: please mark libtool multi-arch: foreign (as in Ubuntu)
On Thu, 2012-07-19 at 08:45 +0200, Kurt Roeckx wrote: On Thu, Jul 19, 2012 at 04:46:00AM +, shawn wrote: Package: libtool Version: 2.4.2-1.1 Severity: important Dear Maintainer, This is important for cross-building https://launchpadlibrarian.net/84463096/libtool_2.4-4ubuntu3_2.4-4ubuntu4.diff.gz I think that's just wrong. The /usr/bin/libtool file is generated for the current architecture and doesn't support cross-building. It's also the only reason this is an arch any package and not an arch all pacakge. In that case, would Multi-arch: allowed work? that way the depending package can specify if cross-arch is OK or otherwise split off a multi-arch: foreign package, which libtool would depend on. There probably aren't many users of /usr/bin/libtool, but I know there are. Kurt -- -Shawn Landden -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682045: libtool: please mark libtool multi-arch: foreign (as in Ubuntu)
On Thu, Jul 19, 2012 at 04:46:00AM +, shawn wrote: Package: libtool Version: 2.4.2-1.1 Severity: important Dear Maintainer, This is important for cross-building https://launchpadlibrarian.net/84463096/libtool_2.4-4ubuntu3_2.4-4ubuntu4.diff.gz I think that's just wrong. The /usr/bin/libtool file is generated for the current architecture and doesn't support cross-building. It's also the only reason this is an arch any package and not an arch all pacakge. There probably aren't many users of /usr/bin/libtool, but I know there are. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491717: Folder always delete read email does not work
also sprach Carsten Schoenert c.schoen...@t-online.de [2012.07.18.2019 +0200]: the last four years nothing rellay happend to this bug. Do you still have such problems as you have discribed? For me, I can't reproduce this behavior over all the time and the last years. So I hope this problems have gone over the last years. If so, this bug could be closed, if not ... mhh difficult. Well, have you managed to get Thunderbird to delete read messages? -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems was aus liebe getan wird, geschieht immer jenseits von gut und böse. - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#681960: [Pkg-clamav-devel] Bug#681960: closed by Scott Kitterman sc...@kitterman.com (Bug#681960: fixed in clamav 0.97.5+dfsg-4)
On Thursday, July 19, 2012 08:41:36 AM Andreas Beckmann wrote: On 2012-07-19 05:36, Debian Bug Tracking System wrote: * Add /var/run/clamav to directories shipped by clamav-base so dpkg cleanup will work for it too. That won't work. /var/run is a volatile file system. Any directory you use there needs to be created by an initscript. I left in the part where the init script will create it if it doesn't exist already. I checked and it gets correctly removed both after initial install and if I remove the directory and let the init recreate it. Scott K signature.asc Description: This is a digitally signed message part.
Bug#680084: postinst script gets stuck
On 07/18/12 16:41, Fabian Greffrath wrote: Hm, does manually adding stop as per http://www.fifi.org/doc/debconf-doc/tutorial.html in the last line in memtest86+.postinst fix the issue? This seems to work. Regards Harri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680084: postinst script gets stuck
Am 19.07.2012 08:58, schrieb Harald Dunkel: This seems to work. Fine. I suspect the script to get stuck because of the error message printed by grub-probe to some file descriptor. The grub-invaders package has a very similar postinst script. Could you please install it and test if its postinst script gets stuck, too? Thanks, Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682048: wget corrupts ssl chunked transfer-encoded downloads
On 07/18/2012 11:23 PM, Russell Stuart wrote: Package: wget Version: 1.12-2.1 Wget 1.12 doesn't support HTTP/1.1. It's inappropriate for the server to send chunked content in response to an HTTP/1.0 request. For HTTP/1.1 and chunked support, try a newer version of Wget, such as 1.13.4 (available from unstable). -mjc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682049: Please add Ian Campbell as a Debian Maintainer
Package: debian-maintainers Please find the jetring generated file (edited to add fields as requested) attached. Thanks, Ian. -- Ian Campbell Any given program will expand to fill available memory. Comment: Add Ian Campbell i...@hellion.org.uk as a Debian Maintainer Date: Thu, 19 Jul 2012 06:52:53 +0100 Action: import Recommended-By: Ian Jackson ijack...@chiark.greenend.org.uk, Ben Hutchings b...@decadent.org.uk, Martin Michlmayr t...@cyrius.com, Steve McIntyre st...@einval.com, Hector Oron hector.o...@gmail.com, Bdale Garbee bd...@gag.com, Thomas Goirand z...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2012/07/msg00019.html Advocates: http://lists.debian.org/debian-newmaint/2012/07/msg00020.html http://lists.debian.org/debian-newmaint/2012/07/msg00021.html http://lists.debian.org/debian-newmaint/2012/07/msg00022.html http://lists.debian.org/debian-newmaint/2012/07/msg00023.html http://lists.debian.org/debian-newmaint/2012/07/msg00024.html http://lists.debian.org/debian-newmaint/2012/07/msg00025.html http://lists.debian.org/debian-newmaint/2012/07/msg00030.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.12 (GNU/Linux) mQINBE24IUcBEACis9e3QtgcOOHlbqjgVXScdxud6AvE5ziXGM7vt1AFudWqVqWf yXoEA22l1qG2l54Fe/+sWJ5y43ReROOlTRUIyx40Xz8dVj35/PJZ442elpUz5Ica KUNX/cgGen0I98VRoNUUCZQfuxg3y0CgHU2S5U7ETSKxVx0E2UYZOqsaU4gYQjmn ly1uvkNiEthdDB+15yL0YpqA8g2OcQsfh6WmfM2bo78tLvsQj6zlEhiaUimUUlSM Z8X38FK4hC8x353LO8K+9yryX5SMBPYsi8GlD0x12mL7v2TayIxKJP8iKpXL1TU6 rnrxs2Q8wyPIuosK9nVx24o8hAA/Otb10PbO9iQqwLk0COZ760m+OR5rAx2VzbJ3 oyqU694P6Y8hmxtYF5sw+CB6UWxDxHHeyX6hZIulBeFq0V9trpBBo2pV06r5AWZt GK4GTRlAAR9b96wFFqyCvDFvSIOTYcsqTY2aUxzUPYDlvPrGxQy+OWRvPnH7BM6Q AybwMrFbNZltqSXIZclkO1wDAafmgMr5soM12KSl4HaptVTp1PO41yezMqSEYsB+ 6XjSFsEMMugd0OBUlnIU7tgiiyd9Pe4HVjnRUl/EuUC6KR+bWftUSEpcgsaJO6EK 1rqlxZJnG0Woi6C89wWTxwE3Y/X7wFdVjvdxZnBnPEekd3VlBxdd/3a2FQARAQAB tCFJYW4gQ2FtcGJlbGwgPGlqY0BoZWxsaW9uLm9yZy51az6JAkAEEwEIACoCGwMF CQlmAYAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFAk6aAKkCGQEACgkQ7GNpl3kH T6iKGA//VeIAjavnzrk9RF02qDb4rP8H+iX5Vk+IuuHeHH9v3q2zYGtRPw8srbP1 GkX/oq68cJk+7K78wG9lhs9pk/HBNX3xrmgsxWQJAGgAA3BVgp31NtO259211m4v BDQAlAQYB0k4nAuuGQ6llaJdmErhP4aJNwNSsG6C5bSY5x+RS92pir1/PASZD0oj u4K5l7zFvnz926oq0tDCY5AgwoSjCnY2Thg3GhwFlEajgih69+A0/fhEpDk2li9/ b0UrOuLLuUkp1BTcUX+QKNWv5jZZe4QwtPbxhGy5FtGBkcRGWjbq+P//y5rJpDvJ 9fFJFbBO8pz7/50hz+qWR/VZlYORsQNCGBdd/Om9PRN3vBeSKch59CVdOBSQooYQ GE9Z1Gcx10NBa1l+qZySLVtXDq4gSeMBn3rVDQZc4NLuRDD4O1c8wjRgy9tbmMSu nrfv1xTMcRF/8wi7k/0ilP8GGl5YqvJbM/JyxrEsWoZrsRBSwgc5MgJqYidG2GL+ s9pCUs6siD4zDXGYW5LvQKR1s3QJNvM2NRhrSpDTnrk7+XyUuODXpheisWVTy9eB G1sTWfHSETfei5yjXbpIzPK/kjk4dSZuw3/GzWJr7iyVVFzr/3s4CofNVmdBuFhd 6Q5WFhq/ALuTWFnjEnv7rzV2Mt4Ujd4Oy1wUPo2LzX3aTfi2JS+IRgQQEQgABgUC TbgobAAKCRAzT7SpL2vNWZCHAJ4gg+dA2zkB/8TrHtq8GzIuFK4AWgCfU477EtCG YGHPnMUugNFye0Ua2T+JAhwEEwEKAAYFAk416ioACgkQ0BeMdn0GnuZE4hAApM6C PiacswB89c2a6WIpZcHyIUAxDiavDirmjfxH/AB6FmAID4byRE+I8DOJWZCYvxEh IbOtqsQKZUX0a8iG5HWP+4cBhLAbvgpHUwiwecXkC/6sYTcS70ff3jnV54Fe5lOM +CxBLQ5lIIWfHHd1fQAuLuGgIM7dT3lpsMDcdd7b9TSm6EJqivDKgzBeoXrgPZi5 sm/RNbp3UyUGzU6bn0iLWH54K69TEq1wN0Nkgx4Ja01l721zBRCxQtcRurC3buu9 lnD1TWNxnTeBzUrXlBHMp8Qg1Di6ss77LYWcf9pqNQhgoGQKogyIEYciQh6evwAY SUu59JbKNY9gKa1cLTEGDt1AsSC/+UEqypHC3yu0BYbs+MJGO+Jk8WKSlFIKXTyn PD35iFARvyLoipR+C1eSHZDXdmKAVxrJ/mY4f4Rb1Lue3USGAzqSo8YCnst4bnJC zGl/2RMyNZfSqWC8vm38vy59HXcM6roSx/zeDfiCZAAu9cMj5UkSVVpFLOlA2z16 pZTS9/puuLCz7s4xy/e69gHGwOs4wTcg5E87boszyaT5XVmDtit6diejGXqxm+Bt 5bTNGM2DacA7xvYHmsSBNANAIPsrWml5+nMbTUAcIdLH3GPVjrHz9ExV45Y18ze6 tRrh9wut3n/sC50rqZ8+sb8yV8QjIjEav6DLbY6JAhwEEAEIAAYFAk44cAcACgkQ 2SnymSvvCjMzhBAAxaKBYT+RjvuT9C2AbxhOZS0YFM3kiL4cbc5ena63qrsry+6t 5yumAqUIeQggeNXdhc7tboDfOib/lsPf83BAbpopO9z5M4elp0mZan8lcunRW5H3 CqdgZ3yl5ZQs3HVzhBRJr83YVqxCsZNke2rTGhpOPiX3Eq6i+a/5ERLtH/bpENDH fwQWh+ZT15a3wvlJFrjcmF5ZzBzUJ1BoL2jKQrPx0R5eGLiujnslQ9jDYWBPnoCU KQPfHh5WQuXO9gJb+47Gfr2H5cVIJxkAjfoyB79N0Qky85lhbu7NcxWzFw3FgwLA QiWAgSZuY6fIt+T2Eej2YA243zlziI+P1Ty7XGwC5l/GHaA2OTBClOSQ/PhTap9M Y2JFa1393shvqACiriFdCRdL0LL3Vzzf/VptGfJxdqG5vAbs8xciACpJy7vVFkaq //1swOqRie2n9wW0uRU5l+ZlCM/EyKwFfUK0b8Dtacbml0bpUIqHUT9ppMCY0KO2 Zxp28SsU397ZndazWBwf5SChIQ5PwS/K8PZQvtipsA+Bn190D/sUhKFAdCFSeFrE 6n78KL6iMs17QZua8jQc/mwkFQxnS+8/BLOCy11JIjWzJz/UMqpFWduDM0V/6rEe mkw1PWvhkkx/snuncAkDikuHerQeK78xF0bQu3/yXCob9DRtNagiP+gu6xOIRgQQ EQIABgUCTkEUzAAKCRAS23nuxHY7pakKAJwME/IayoOCrH4sJSBNRjnz6Ect3ACg ira8JCQzPPOVuUd4X3A8lUzr8zKJAhwEEAEIAAYFAk5AcW8ACgkQTSSdmyPm/Drz MRAA5wgfmHSxvemMoG0ORGZfglTlkHh7ZML5MqYfxolz0UTqjA+NElynK0zCF68X I/8u6LL30RxDsV3rtXDIvoMrmzpUt1Usr5rAea0ibz7L348qb7Vne5arUs47EW06 ozzWZnnL2irALq/Hh9X7vRzUHcKc1YB747Z7efQvbe1OqdJoxFUiZbD3Z8WDO5OR 29uylQEQ3TzI9FWXStPcNCCo+bC/ufV5nh4CvR4lZtP+lopGchXOZtyUjP3+5Wmp 786FfRylmtteIvQ7VbdpTqp9IobxY4KUwBrMwrY4iqYnkL2Bd0P2mJgNdEEF7H5u CBLqLWtgVt8CIe5txnTws9KmKy0zHBuR8gwTWxVhuO4EBa/lZ26FqEllSAEffsXl
Bug#682042: [EMBOSS] About bulky taxonomy and gene ontology data in the EMBOSS package.
On 19/07/2012 05:17, Charles Plessy wrote: Dear EMBOSS developers, today I received the following bug report about the quantity of data shipped in the Debian package for EMBOSS. emboss-data recently grew from a slim 5 megabytes to a massive 305. Closer inspection reveals the primary culprits to be large taxonomy and gene ontology databases: In Debian, one solution would be to transfer this data in a separate optional package. But before doing so, I would like to ask you if this data really oughts to be distributed with EMBOSS ? After all, for many other databases, there are scripts to download and index the data after installation. Will EMBOSS 6.5 ship the taxonomy and gene ontology databases as well ? They are included in the release which appeared on 15th July (announcement in preparation). For developers the data is updated by rsync ... we could provide scripts to upload and index the data at the end of installation though I found in preparing the release that two ontologies had moved in the last year so that is error-prone. Some EMBOSS applications assume these databases are installed, particularly EDAM and the NCBI taxonomy. EDAM is used for all metadata, the taxonomy for organism searches in data retrieval. The Gene Ontology is included in analysis of GO terms in metadata. So if they are in an optional package ... some things will not work if it is not installed. EDAM I would say is essential. regards, Peter Rice EMBOSS Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681741: libreoffice: LibreOffice user installation could not be processed etc.
Installing debian with the Debian Desktop task works fine. However, you can reproduce this with the following steps (which is how I tend to work) 1. Install just the base system 2. apt-get install lxde (this doesn't depend on libreoffice) 3. Log in to lxde as a regular user 4. Menu Accessories Root Terminal (uses gksu) 5. As root, apt-get install libreoffice This creates the directory .config/libreoffice under the *user's* home directory, owned by *root*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680278: not specific to linux-image-3.2.0-3-686-pae
Same problem here with linux-image-3.2.0-3-amd64, Version 3.2.21-3. So this bug does not seem to be specific to the binary package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681743: i915: display backlight brightness initially set to zero on boot
Tested 3.5.0-rc7+, boots up the same way, with the backlight off. Adding i915.invert_brightness=1 makes it turn the brightness up to the maximum as expected, however this is pretty ugly. Without this parameter, I can just turn the brightness up with the fn keys and I get the nice on-screen indicator from GNOME. However with invert_brightness I need to turn it _up_, with the indicator showing it going up, in order to get it down, and vice versa. Anyway, I guess the desired result is that it should just work without having to do special workarounds. On Mon, 2012-07-16 at 06:45 -0500, Jonathan Nieder wrote: Those commits are both in 3.5-rc1, so if you get a chance to test 3.5-rc1 or newer, that would also be useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681960: [Pkg-clamav-devel] Bug#681960: closed by Scott Kitterman sc...@kitterman.com (Bug#681960: fixed in clamav 0.97.5+dfsg-4)
On 2012-07-19 08:56, Scott Kitterman wrote: I left in the part where the init script will create it if it doesn't exist already. I checked and it gets correctly removed both after initial install and if I remove the directory and let the init recreate it. Expect a lintian error and someone filing a RC bug as shipping something in /var/run is a policy violation: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs-run Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653750: [Pkg-exim4-users] Bug#653750: retitle - nightmare bug
On Thursday 19 July 2012 04:53:23 Regid Ichira wrote: --- On Wed, 7/18/12, Marc Haber wrote: retitle #653750 nightmare multi-bug about spec.txt - please do not report more issues here - file new bugs thanks Do you think it would help if I will: 1. Copy the whole, multiple issues report, as a message to pkg-exim4-users. Just to have it archived. 2. close the bug. ? I do not remember this. Might save it anyway and close (or ask on the users group if anyone has this issue now). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677335: [php-maint] Fwd: Bug#677335: gforge-web-apache2: PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression'
Hi Olivier, I have no idea at all, but you might try asking in php-internals, maybe they won't eat you :) O. On Wed, Jul 18, 2012 at 6:01 PM, Olivier Berger olivier.ber...@it-sudparis.eu wrote: Hi. I'm puzzled by this bug. It seems that the following, set in fusionforge's : ob_start(ob_gzhandler); isn't compatible with some zlib compression counter part. However, I can't seem to spot anything that would have activated zlib.output_compression or zlib.output_handler by default in Debian. phpinfo reports, as expected from default apache2 php.ini : Directive Local Value Master Value zlib.output_compression Off Off zlib.output_compression_level -1 -1 zlib.output_handler no valueno value Do you have any idea on how to try and investigate that ? Thanks in advance. Best regards, -- Forwarded message -- From: Olivier Berger olivier.ber...@telecom-sudparis.eu To: Debian Bug Tracking System sub...@bugs.debian.org Cc: Date: Wed, 13 Jun 2012 12:09:38 +0200 Subject: Bug#677335: gforge-web-apache2: PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression' Package: gforge-web-apache2 Version: 5.2~rc1-1 Severity: minor Hi. I notice this : [Wed Jun 13 12:04:15 2012] [error] [client 82.238.14.130] PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression' in /usr/share/gforge/common/include/pre.php on line 54 [Wed Jun 13 12:04:15 2012] [error] [client 82.238.14.130] PHP Notice: ob_start(): failed to create buffer in /usr/share/gforge/common/include/pre.php on line 54 Doesn't seem harmful, but still... Thanks in advance. Best regards, -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gforge-web-apache2 depends on: ii cronolog 1.6.2+rpk-1 ii debconf [debconf-2.0] 1.5.43 ii debianutils 4.3.1 ii gforge-common 5.2~rc1-1 ii gforge-db-postgresql [gforge-db] 5.2~rc1-1 ii libapache2-mod-php5 5.4.4~rc2-1 ii libdbd-pg-perl2.19.2-1 ii libdbi-perl 1.621-1 ii libjs-jquery 1.7.2+debian-1 ii libjs-jquery-tipsy5-1 ii libjs-scriptaculous 1.9.0-2 ii libjs-yui 2.8.2r1~squeeze-1 ii libnusoap-php 0.7.3-4 ii libphp-jpgraph1.5.2-12 ii libphp-simplepie 1.2.1-3 ii perl 5.14.2-11 ii php-http 1.4.1-1 ii php5-cgi 5.4.4~rc2-1 ii php5-gd 5.4.4~rc2-1 ii php5-pgsql5.4.4~rc2-1 ii python2.7.2-10 ii ssl-cert 1.0.28 ii ucf 3.0025+nmu3 Versions of packages gforge-web-apache2 recommends: ii locales 2.13-33 gforge-web-apache2 suggests no packages. -- Configuration Files: /etc/cron.d/gforge-web-apache2 changed [not included] /etc/gforge/httpd.conf.d/30-vhosts-projects.conf changed [not included] -- debconf information excluded -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682050: fails to connect to server using non default port
Package: python-paramiko Version: 1.7.7.1-3 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi this seems to be regression caused by fixing #668239. The original code does work for me, while new one always fails with: ssh: Rejecting ssh-rsa host key for .cihar.com: b655967c31be1f70a8222cedb3b1c5d0 Using OpenSSH to the same host works, so I believe it must be bug in paramiko's handling of known_hosts. - -- Michal Čihař | http://cihar.com | http://blog.cihar.com - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.10-1.16-desktop (SMP w/2 CPU cores; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-paramiko depends on: ii python 2.7.3~rc2-1 ii python-crypto 2.6-2 python-paramiko recommends no packages. python-paramiko suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQB7ZQAAoJEGo39bHX+xdN25YP/2oj40QRM3f6Q+oddp9YUPj+ IsP0cQd6EcTLGJzgd0gHEwzfost1Vsf+N8njDzk4rFTPMMgO/byTWMkst4m73nRq BoAEK7LfrQRqL+qF8a6TKOzNacXtKG9xYMcrKltnsiTsgpohPQW+lLFh52IPWS2G nfZ8I0kZYhVR00xCCMIlickT+AdsY15IVcHkGMfpGuP75vG9R7CFxDYdMtt5r9TJ a+2BXMyIp1GYuT//UUA8NbMiZo3LoTwW1qCIzhJebpZ0Q+98TrKIK+Kw+htrlbjZ LNE3QEwyzLc1BROLmC0dXr70BlDt7eumxkl5jMKOkjBO4ko6btRkgkzcmmX+MErA 4OwxbM+pz3K9LnPEqLeB6/aHetXz3RcF/Fe10+auNfblFcYwMoM8WwJjfNEGszMK LXu5yZyoTXF/l6QtsqjW6tK2Qa+RrOjX6T5sQDJumq/c0DhzozctBvuZDym96vGk 5Og34scIj4SHHdcuE0WA7riKDLnGhYxYllPLRhKmkx7yHVm4DehtTw+SGvN1CGGg 6Us1jHtstHmOJDv+NmDHhMcTVKE8CrroxmMbjzpJskAtP9GQwFsjycTO5J3fK3BN wgjIQP+2fDX2eQa6gaoJpdRCgo7h9ViahJMT9dSKNhzvZamJfECFTZRRytCuZujK 5C368BJkUVCDMlk2FWch =HuGp -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#682051: xfonts-a12k12: should be rebuilt with current dh_installxfonts
Package: xfonts-a12k12 Version: 1-9 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the piuparts log: 0m57.2s ERROR: FAIL: Package purging left files on system: /usr/share/fonts/X11/ owned by: xfonts-a12k12, xfonts-utils, xfonts-encodings /usr/share/fonts/X11/misc/ owned by: xfonts-a12k12 /usr/share/fonts/X11/misc/fonts.alias not owned Rebuilding the package in sid with no further changes updates the maintainer script parts generated by dh_installxfonts to properly cleanup during removal. cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682052: xfonts-kappa20: should be rebuilt with current dh_installxfonts
Package: xfonts-kappa20 Version: 0.396-3 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the piuparts log: 0m39.5s ERROR: FAIL: Package purging left files on system: /usr/share/fonts/X11/ owned by: xfonts-kappa20, xfonts-utils, xfonts-encodings /usr/share/fonts/X11/misc/ owned by: xfonts-kappa20 /usr/share/fonts/X11/misc/fonts.alias not owned Rebuilding the package in sid with no further changes updates the maintainer script parts generated by dh_installxfonts to properly cleanup during removal. cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675785: Same problem
Hi, Now, I cannot build my application as well, even installing libgcrypt11-dev $ pkg-config --cflags libssh2 Package libgcrypt was not found in the pkg-config search path. Perhaps you should add the directory containing `libgcrypt.pc' to the PKG_CONFIG_PATH environment variable Package 'libgcrypt', required by 'libssh2', not found Please have a look this package. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653750: [Pkg-exim4-users] Bug#653750: retitle - nightmare bug
David Baron wrote: On Thursday 19 July 2012 04:53:23 Regid Ichira wrote: --- On Wed, 7/18/12, Marc Haber wrote: retitle #653750 nightmare multi-bug about spec.txt - please do not report more issues here - file new bugs thanks Do you think it would help if I will: 1. Copy the whole, multiple issues report, as a message to pkg-exim4-users. Just to have it archived. 2. close the bug. ? I do not remember this. Might save it anyway and close (or ask on the users group if anyone has this issue now). Looking at this from the exim maintainers point of view, if you are making local modifications to spec.txt then you are pretty much fucked. We're very happy to take documentation fixes - including as changes to text/html if really necessary, but any bugs reported in that form take much more work to resolve in much the same way as you giving me a binary diff of spec.pdf or exim.o - the source looks somewhat different. So by playing games with spec.txt at the debian package level you are making life hard for the debian package maintainers, the upstream maintainers and probably yourselves... All the actors here are short on time, so making things hard tends to mean things just don't get fixed. Thanks to Andreas for putting the work into fixing and pushing those bug fixes upstream. Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682053: FTBFS if built twice in a row
Source: datapm Version: 0.10-1 Severity: serious Justification: fails to build from source Hi, datapm fails to build if built twice in a row. From my cowbuilder log: dpkg-buildpackage: source package datapm dpkg-buildpackage: source version 0.10-1 dpkg-buildpackage: source changed by J. Félix Ontañón fonta...@emergya.es dpkg-buildpackage: host architecture amd64 dpkg-source --before-build datapm-0.10 fakeroot debian/rules clean dh clean --with python2 dh_testdir dh_auto_clean running clean removing 'build/lib.linux-x86_64-2.6' (and everything under it) 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.6' does not exist -- can't clean it running clean removing 'build/lib.linux-x86_64-2.7' (and everything under it) 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it removing 'build' dh_clean dpkg-source -b datapm-0.10 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building datapm using existing ./datapm_0.10.orig.tar.xz dpkg-source: warning: file datapm-0.10/datapm.egg-info/entry_points.txt has no final newline (either original or modified version) dpkg-source: warning: file datapm-0.10/datapm.egg-info/SOURCES.txt has no final newline (either original or modified version) dpkg-source: info: local changes detected, the modified files are: datapm-0.10/datapm.egg-info/PKG-INFO datapm-0.10/datapm.egg-info/SOURCES.txt datapm-0.10/datapm.egg-info/dependency_links.txt datapm-0.10/datapm.egg-info/entry_points.txt datapm-0.10/datapm.egg-info/not-zip-safe datapm-0.10/datapm.egg-info/top_level.txt dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/datapm_0.10-1.diff.c17Zcp dpkg-buildpackage: error: dpkg-source -b datapm-0.10 gave error exit status 2 E: Failed autobuilding of package W: no hooks of type C found -- ignoring I: unmounting /var/cache/pbuilder/result filesystem I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting /home filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem - Cleaning COW directory forking: rm -rf /var/cache/pbuilder/build//cow.24677 Will attach a patch as soon I have a bug#. Regards Evgeni -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677335: Fwd: Bug#677335: gforge-web-apache2: PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression'
On Wed, 18 Jul 2012, Olivier Berger wrote: Do you have any idea on how to try and investigate that ? Yes I did so (told people in IRC, IIRC). $ sudo a2dismod deflate This seems to be a new Debian standard setting for new installations. We can add a workaround to not use our own gzip compression *at all* if mod_deflate is detected, although that’ll kill it too if it’s not active. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682054: modemmanager: 3G modem (Ericsson F5521gw) doesn't connect after suspend
Package: modemmanager Version: 0.5.2.0-1 Severity: important Dear Maintainer, 3G modem (Ericsson F5521gw) doesn't connect after suspend on Lenovo Thinkpad e320. Actually the mobile broadband couldn't be activated at all. It works after reboot until the computer is suspended. If the power is totally lost(battery disconnected) , bios defaults has to restored before, the mobile broadband can be activated. I'm running Debian testing with Gnome3. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages modemmanager depends on: ii libc6 2.13-33 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-2 0.100-1 ii libglib2.0-0 2.32.3-1 ii libgudev-1.0-0175-3.1 Versions of packages modemmanager recommends: ii usb-modeswitch 1.2.3+repack0-1 modemmanager 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#680084: postinst script gets stuck
On 07/19/12 09:05, Fabian Greffrath wrote: Fine. I suspect the script to get stuck because of the error message printed by grub-probe to some file descriptor. The grub-invaders package has a very similar postinst script. Could you please install it and test if its postinst script gets stuck, too? grub-invaders installs without problem. Looking at the grub-install: It seems that os-prober (run by update-grub) starts a grub-mount tool that keeps on running, even though the update-grub already did an exit. ps -ef showed me a few of these: grub-mount /dev/mapper/vg00-root2 /var/lib/os-prober/mount If I kick out os-prober then the old memtest86+ postinst doesn't get stuck. So I would suggest to reassign this bug to os-prober. Version is 1.54. But I've got one question: Why does the postinst script run update-grub at all? Ain't this supposed to be triggered at the end of the whole apt-get install session instead? Regards Harri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682055: xfonts-mplus: should be rebuilt with current dh_installxfonts
Package: xfonts-mplus Version: 2.2.4-1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the piuparts log: 0m37.7s ERROR: FAIL: Package purging left files on system: /usr/share/fonts/X11/ owned by: xfonts-mplus, xfonts-utils, xfonts-encodings /usr/share/fonts/X11/misc/ owned by: xfonts-mplus /usr/share/fonts/X11/misc/fonts.alias not owned Rebuilding the package in sid with no further changes updates the maintainer script parts generated by dh_installxfonts to properly cleanup during removal. cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682053: FTBFS if built twice in a row
tags 682053 + patch thanks On Thu, Jul 19, 2012 at 09:34:34AM +0200, Evgeni Golov wrote: datapm fails to build if built twice in a row. Will attach a patch as soon I have a bug#. https://github.com/evgeni/dpm/commit/5069268d47ae6f27ae514dc51178d7d4c2389cf1 -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682056: xfonts-shinonome: should be rebuilt with current dh_installxfonts
Package: xfonts-shinonome Version: 5-1.1 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the piuparts log: 0m40.7s ERROR: FAIL: Package purging left files on system: /usr/share/fonts/X11/ owned by: xfonts-shinonome, xfonts-utils, xfonts-encodings /usr/share/fonts/X11/misc/ owned by: xfonts-shinonome /usr/share/fonts/X11/misc/fonts.alias not owned Rebuilding the package in sid with no further changes updates the maintainer script parts generated by dh_installxfonts to properly cleanup during removal. cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682057: Add VCS line in d.control
Package: fwknop Version: 2.0.0rc2-2 Severity: wishlist The Vcs line in debian.control should be added. It has been removed with the last release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682058: xfonts-naga10: FTBFS: BDF Error on line 1: bad 'STARTFONT' \n bdftopcf: bdf input, knj10I.bdf, corrupt
Package: xfonts-naga10 Version: 1.1-13 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, rebuilding xfonts-naga10 in a clean sid chroot fails: debian/rules build dh_testdir # Add here commands to configure the package. chmod a+x debian/mkbold debian/mkitalic touch configure-stamp dh_testdir # Add here commands to compile the package. #/usr/bin/make #/usr/bin/docbook-to-man debian/xfonts-naga10.sgml xfonts-naga10.1 patch -o maru10.bdf maru10.bdf.diff patching file knj10.bdf patch -o min10.bdf min10.bdf.diff patching file knj10.bdf bdftopcf -o maru10.pcf maru10.bdf bdftopcf -o min10.pcf min10.bdf bdftopcf -o 5x10B.pcf 5x10B.bdf bdftopcf -o 5x10rk.pcf 5x10rk.bdf bdftopcf -o knj10.pcf knj10.bdf bdftopcf -o 5x10a.pcf 5x10a.bdf bdftopcf -o knj10B.pcf knj10B.bdf # mkbold debian/mkbold -V maru10.bdf maru10B.bdf debian/mkbold -V min10.bdf min10B.bdf #debian/mkbold -V 5x10rk.bdf 5x10rkB.bdf bdftopcf -o maru10B.pcf maru10B.bdf bdftopcf -o min10B.pcf min10B.bdf #bdftopcf -o 5x10rkB.pcf 5x10rkB.bdf # mkitalic debian/mkitalic -V knj10.bdf knj10I.bdf debian/mkitalic -V knj10B.bdf knj10BI.bdf debian/mkitalic -V maru10.bdf maru10I.bdf debian/mkitalic -V maru10B.bdf maru10BI.bdf debian/mkitalic -V min10.bdf min10I.bdf debian/mkitalic -V min10B.bdf min10BI.bdf debian/mkitalic -V 5x10a.bdf 5x10aI.bdf debian/mkitalic -V 5x10B.bdf 5x10BI.bdf #debian/mkitalic -V 5x10rk.bdf 5x10rkI.bdf #debian/mkitalic -V 5x10rkB.bdf 5x10rkBI.bdf bdftopcf -o knj10I.pcf knj10I.bdf BDF Error on line 1: bad 'STARTFONT' bdftopcf: bdf input, knj10I.bdf, corrupt make: *** [build-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 I wanted to test rebuilding the package with current dh_installxfonts which should produce maintainer scripts that properly cleanup on removal. cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
Il 18/07/2012 22:44, Luca Capello ha scritto: Hi there! Alexander, thank you for the detailed explanation, which means that this bug should stay open (and retitled, in case). On Wed, 18 Jul 2012 19:55:29 +0200, Alexander Golovko wrote: On Wed, 18 Jul 2012 18:35:07 +0200, AZ Imballaggi S.r.l. - Enrico Ghera wrote: Il 18/07/2012 18:03, Luca Capello ha scritto: Hi there! On Wed, 18 Jul 2012 03:18:44 +0200, Alexander Golovko wrote: So, this is not a bug in package, but dbconfig-common habits. Ofcourse, we should describe database upgrade habits in README.Debian UPGRADE section. If you want to do that, then please go ahead, but strictly speaking this is not something that belongs to Debian, but in upstream manual. Debian provides a way to manage local and remote database, via dbconfig-common. If the admin changes that, than she/he should *know* that automatic upgrades could fail (Debian can not assure all possible configurations). We should describe differences from upstream - dbconfig-common usage and common troubles. I slightly disagree, simply because dbconfig-common is the Debian way of doing such things. If we go on the path of documenting differences WRT upstream, than each package using dbconfig-common should do the same, which is IMHO plainly wrong. It is something difficult for me, because english is not native for me, but i will try later. Do not worry for the language, having a not-completely-English documentation is better than no documentation at all. Enrico, I am sorry for the bug, but I bet that having configured the remote database via dbconfig-common (thus via `dpkg-reconfigure bacula-director-mysql`) would have resulted in a correct upgrade. No, we should not use dpkg-reconfigure for change database parameters without database reinstallation. If we run dpkg-reconfigure, dbconfig ask to reinstall database and rewrite config file In choice of don't reinstall database, dbconfig rewrite config file and add to it 'dbc_install=false', so this will stop future database upgrades. IMHO this is a bug in dbconfig-common or in the way we use it, given that we should be able to use it *without* database reinstallation. I agree on this. just to understand better (and avoid other useless bug reports): everytime I modify my database settings I should run dpkg-reconfigure? doing the work twice? (one for actual conf and one for dbconfig) or I should run dpkg-reconfigure and it updates my conf as well? or my brain is dead and I have not understood anything? If you change only database connect parameters (host, dbname, user, password, etc), than you should not run dpkg-reconfigure, but should make changes in two places: 1. in bacula config 2. in dbconfig files (/etc/dbconfig-common/bacula-director-(mysql|pgsql|sqlite3).conf IMHO this is prone to errors, which is why I blindly thought that dpkg-reconfigure would have done the trick. also in my opinion doubling the places where to configure is too prone to errors. there should be a different way to make things, without doubling. maybe each package that requires dbconfig shoud be able to read the package's conf files and generate automatically the dbconfig's conf. it's a lot of effort but is transparent to users. this is how I think it should work: a) first installation: * run dbconfig asking wether to install on local machine or on remote one (also for new databases). * dbconfig shoud generate it's own conf files and place one example conf in the package's conf dir. * install package b) updates/upgrades: * first of all dbconfig shoud read the package's conf, and generate a new one for itself. * update/upgrade package this way if the sysadmin changes something in the package's conf on each subsequent upgrade/update dbconfig will find the right database. anyhow the syntax of configuration files is quite stable... this should be a one time work. Enrico, in the end you were right, which also means that you discovered a bug in the Bacula packaging (or in dbconfig-common, I would say). Wooo hooo! my first bug in Debian! Thx, bye, Gismo / Luca thank you all. Enrico -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680084: memtest86+.postinst script gets stuck
reassign 680084 os-prober found 680084 1.54 thanks Am 19.07.2012 09:42, schrieb Harald Dunkel: Looking at the grub-install: It seems that os-prober (run by update-grub) starts a grub-mount tool that keeps on running, even though the update-grub already did an exit. ps -ef showed me a few of these: grub-mount /dev/mapper/vg00-root2 /var/lib/os-prober/mount If I kick out os-prober then the old memtest86+ postinst doesn't get stuck. So I would suggest to reassign this bug to os-prober. Version is 1.54. Agreed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682059: root-system: Bunch of not-installed libs and include files
Package: root-system Version: 5.34.01-1 Severity: normal Dear Maintainer, I tried to built myself the latest root-system version from debian mentors (but I believe the same issue is present in present debian version 5.34.00-1) and noticed that there is bunch of built but not installed files (mostly libaries and include files, see below). Is it intentional or a bug ? It looks like that at least part of them could be recovered but putting appropriate plugin package into the debian/control file (e.g. for root-plugin-graph2d-gviz is missing in there). Thanks for the effort to include this complex package into debian repositories. Pavel Here is the list of not-installed files: dh_install: etc/root/Makefile.arch exists in debian/tmp but is not installed to anywhere dh_install: etc/root/system.plugins-ios exists in debian/tmp but is not installed to anywhere dh_install: etc/root/HistFactorySchema.dtd exists in debian/tmp but is not installed to anywhere dh_install: etc/root/class.rules exists in debian/tmp but is not installed to anywhere dh_install: etc/root/svninfo.txt exists in debian/tmp but is not installed to anywhere dh_install: etc/root/root.desktop exists in debian/tmp but is not installed to anywhere dh_install: etc/root/cmake/FindROOT.cmake exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/ProofBenchCPUSel.par.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGLEW.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libSRPAuth.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGviz.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libRecorder.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libProofBench.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libHDFS.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libOracle.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGviz3d.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libSapDB.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libMonaLisa.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGFAL.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libDCache.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGCocoa.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGenetic.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libChirp.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libEGPythia6.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libRCastor.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGQuartz.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libRgLite.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libGenetic.so exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/ProofBenchDataSel.par.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/libFITSIO.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libGviz.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libRecorder.so.5 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libGviz3d.rootmap exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libRecorder.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libProofBench.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libGviz3d.so.5.34 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libProofBench.so.5 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libProofBench.rootmap exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/x86_64-linux-gnu/root5.34/libFITSIO.so.5 exists in debian/tmp but is not installed to anywhere dh_install:
Bug#682060: jarjar: Embeds parts of libasm3-java
Package: jarjar Version: 1.1-3 Severity: important This embedded code caused #646600 and it is not really preferred. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682061: unblock: jarjar/1.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package jarjar, which fixes the RC bug #646600. The bug is that if you rebuild jarjar in SID it will construct an incomplete Java library. This is because it embeds a part of libasm3-java inself during build (I have filed a bug for that) and some of that moved to another Jar file breaking. I also took the liberity of removing a MIA uploader. unblock jarjar/1.1-3 ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666980: zoneminder: hash authentication broken in update
On 07/18/2012 09:25 PM, Marcelo Jorge Vieira wrote: Hi Kevin, On Sun, 2012-04-15 at 15:12 -0700, Kevin Ross wrote: I'm having the same problem, but unfortunately for me, your workaround isn't working for me. Looking at my apache access.log, I can see it is passing the user name, but it isn't passing the password. So for now, I have completely turned off authentication. Obviously this is not a great solution, but it gets me back up and running while waiting for a fix. you can try turn on authentication and set AUTH_RELAY to 'none'. Cheers, Thanks, that worked! -- Kevin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664261: , Bug#667684: nvidia-glx: Crashes and system freezes
In Tue, 2012-07-17 at 20:30 +0200, Andreas Beckmann wrote: There are also 295.59 in squeeze-backports and 302.17 in sid/wheezy. I've tested 302.17-3 from testing on my workstation and it seems to reduce the occurrence: My workstation hanged up only once. I'm not sure it is related (did not investigated) but don't see any other reason. However I continue to see [158606.609199] NVRM: os_pci_init_handle: invalid context! [158606.609203] NVRM: os_pci_init_handle: invalid context! [158606.609206] NVRM: os_pci_init_handle: invalid context! [158991.947984] NVRM: os_pci_init_handle: invalid context! [158991.947989] NVRM: os_pci_init_handle: invalid context! [158991.947993] NVRM: os_pci_init_handle: invalid context! [159321.312080] NVRM: Xid (:01:00): 8, Channel 0002 [159330.312048] NVRM: Xid (:01:00): 8, Channel The good info is that now the system is usable again : a few days without hanging and dual monitor without 100% CPU load Thanks for your hard work. Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682061: unblock: jarjar/1.1-3
On 2012-07-19 10:18, Niels Thykier wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jarjar, which fixes the RC bug #646600. The
bug is that if you rebuild jarjar in SID it will construct an
incomplete Java library.
This is because it embeds a part of libasm3-java inself during build
(I have filed a bug for that) and some of that moved to another Jar
file breaking.
I also took the liberity of removing a MIA uploader.
unblock jarjar/1.1-3
~Niels
... and the debdiff.
~Niels
changelog| 19 ++
control |2 -
patches/0006-remove-asm-commons-from-final-jar.patch | 25 ---
patches/series |1
4 files changed, 20 insertions(+), 27 deletions(-)
diff -Nru jarjar-1.1/debian/changelog jarjar-1.1/debian/changelog
--- jarjar-1.1/debian/changelog 2011-09-08 20:31:33.0 +
+++ jarjar-1.1/debian/changelog 2012-07-15 11:19:14.0 +
@@ -1,3 +1,22 @@
+jarjar (1.1-3) unstable; urgency=low
+
+ * Rember to actually remove Michael Koch from uploaders.
+
+ -- Niels Thykier ni...@thykier.net Sun, 15 Jul 2012 13:19:13 +0200
+
+jarjar (1.1-2) unstable; urgency=low
+
+ [ James Page ]
+ * Drop debian/patches/0006-remove-asm-commons-from-final-jar.patch:
+libasm3-java now ships correctly separated jar files so asm-commons
+must be included. (Closes: #646600)
+
+ [ Niels Thykier ]
+ * Remove Michael Koch from uploaders. Thanks for your work so far.
+(Closes: #654028)
+
+ -- Niels Thykier ni...@thykier.net Sun, 15 Jul 2012 12:42:56 +0200
+
jarjar (1.1-1) unstable; urgency=low
* Team upload
diff -Nru jarjar-1.1/debian/control jarjar-1.1/debian/control
--- jarjar-1.1/debian/control 2011-09-08 20:31:33.0 +
+++ jarjar-1.1/debian/control 2012-07-15 11:18:46.0 +
@@ -2,7 +2,7 @@
Section: java
Priority: optional
Maintainer: Debian Java Maintainers
pkg-java-maintain...@lists.alioth.debian.org
-Uploaders: Michael Koch konque...@gmx.de, Niels Thykier ni...@thykier.net
+Uploaders: Niels Thykier ni...@thykier.net
Build-Depends: debhelper (= 7), cdbs, ant, libasm3-java, default-jdk
Standards-Version: 3.9.2
Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/jarjar
diff -Nru
jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
--- jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
2011-09-08 20:26:25.0 +
+++ jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
1970-01-01 00:00:00.0 +
@@ -1,25 +0,0 @@
-From: Torsten Werner twer...@debian.org
-Date: Sun, 28 Feb 2010 12:45:45 +0100
-Subject: remove asm-commons from final jar
-
- build.xml |5 -
- 1 files changed, 0 insertions(+), 5 deletions(-)
-
-diff --git a/build.xml b/build.xml
-index bbae4da..160e9ee 100644
a/build.xml
-+++ b/build.xml
-@@ -79,11 +79,6 @@
- jarjar jarfile=${jarfile}
- fileset dir=build/main/
- zipfileset src=${asm.jar}/
-- zipfileset src=${asm-commons.jar}
--include name=org/objectweb/asm/commons/EmptyVisitor.class/
--include name=org/objectweb/asm/commons/Remap*.class/
--include
name=org/objectweb/asm/commons/LocalVariablesSorter.class/
--/zipfileset
- keep pattern=com.tonicsystems.jarjar.Main/
- keep pattern=com.tonicsystems.jarjar.JarJarTask/
- rule pattern=com.tonicsystems.jarjar.util.**
result=com.tonicsystems.jarjar.ext_util.@1/
---
diff -Nru jarjar-1.1/debian/patches/series jarjar-1.1/debian/patches/series
--- jarjar-1.1/debian/patches/series2010-02-28 11:52:52.0 +
+++ jarjar-1.1/debian/patches/series2012-07-15 10:36:37.0 +
@@ -3,4 +3,3 @@
0003-fix-path-in-build.xml.patch
0004-support-gnu-regexp.patch
0005-cast-null-to-java.io.File.patch
-0006-remove-asm-commons-from-final-jar.patch
Bug#679665: [Pkg-javascript-devel] Bug#679665: jquery: build-deps not satisfiable in wheezy
On 12-07-19 at 08:05am, Julien Cristau wrote: On Thu, Jul 19, 2012 at 03:09:38 +0200, Jonas Smedegaard wrote: On 12-07-18 at 11:13pm, Julien Cristau wrote: diff -Nru jquery-1.7.2+debian/debian/links jquery-1.7.2+debian/debian/links --- jquery-1.7.2+debian/debian/links 2010-03-16 01:32:42.0 +0100 +++ jquery-1.7.2+debian/debian/links 2012-07-18 22:59:35.0 +0200 @@ -1,2 +1,3 @@ /usr/share/javascript/jquery/jquery.min.js /usr/share/javascript/jquery/jquery.pack.js /usr/share/javascript/jquery/jquery.min.js /usr/share/javascript/jquery/jquery.lite.js +/usr/share/javascript/jquery/jquery.js /usr/share/javascript/jquery/jquery.min.js Did you see my warnings about symlinks needing special care for some webserver setups? I must have missed that. No special care seems to be taken for the pack and lite symlinks, so I'm not sure what this is about. A user may - directly or via a dependent package - rely on the minified version being a file, even if *other* files in this package is usable only when webserver has relaxed its security to follow symlinks. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#679665: [Pkg-javascript-devel] Bug#679665: jquery: build-deps not satisfiable in wheezy
On Thu, Jul 19, 2012 at 10:32:25 +0200, Jonas Smedegaard wrote: A user may - directly or via a dependent package - rely on the minified version being a file, even if *other* files in this package is usable only when webserver has relaxed its security to follow symlinks. I'm still not following, sorry. How would one rely on such a thing? Cheers, Julien signature.asc Description: Digital signature
Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib
Dnia 2012-07-17, wto o godzinie 10:35 -0700, Russ Allbery pisze: Hello all, Could someone who has the time and the tools available do a check on all the dependencies in main for dependencies on non-free/contrib? This information would be very helpful in evaluating tech-ctte bug #681419. In particular: I'm maintaining PyOpenCL which is currently in contrib, but I hope to move it to main in Wheezy+1. PyOpenCL builds cleanly with main-only packages, and can run with packages from main, but will not be usable then. It depends on ICD loader (free) and on opencl-icd (currently only non-free implementations are available). For more detailed description of OpenCL packaging in Debian see Vincent Danjean vdanj...@debian.org mail OpenCL in Debian from 2012-07-01 http://lists.debian.org/debian-devel/2012/06/msg01108.html * How many total dependencies are there? (We're only interested in Depends or Recommends for this purpose, not Suggests.) * Are all of those dependencies alternative dependencies of the form: Depends: foo | foo-nonfree In PyOpenCL it'll always be: Depends: ocl-icd-libopencl1 | libopencl1 where the ocl-icd-libopencl1 is free package, while other packages providing libopencl1 (currently amd-libopencl1 and nvidia-libopencl1) are non-free. I want to allow for users to be able to use non-free ICD loaders to allow for experiments and having different OpenCL versions (see bug #673992). As for opencl-icd, now PyOpenCL has: Depends: opencl-icd As soon as Debian has a free OpenCL implementation I'll change it to Depends: free-opencl-icd | opencl-icd but I intend to keep dependency on non-free OpenCL implementations (currently amd-opencl-icd and nvidia-opencl-icd) to allow to use GPGPU hardware if users are using non-free drivers. or are there other cases? A list of the other cases would be very interesting. (Some may just be bugs, but we may not have thought of some other possible pattern.) I am not sure if PyOpenCL fits general case or is special case. It requires two OpenCL-related packages (ICD loader and ICD) to work and those can be any mixture of free and non-free packages. * Are any of these dependencies versioned? One of the things we're evaluating is whether it would always be possible to replace those dependencies with a straight dependency on foo, with foo-nonfree Providing foo. Currently not (ICD loader takes care of proper managing of ICD versions) but I am wondering whether to add versioned dependency on ocl-libopencl1 (see my mail from 2012-07-10 OpenCL in Debian http://lists.debian.org/debian-devel/2012/07/msg00240.html ). From experience it seems that PyOpenCL works well with opencl-headers and ocl-icd-libopencl1, while there are some problems with different versions of non-free libopencl1 (most notably NVIDIA). Best regards. -- Tomasz Rybak tomasz.ry...@post.pl GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#682062: liblinear1: Please drop Recommends against liblinear-tools
Package: liblinear1 Version: 1.8+dfsg-1 Severity: wishlist Hi, Could you please drop the recommends against liblinear-tools. Nmap is now depending on liblinear1 which is pulling liblinear-tools via the recommends. In turn liblinear-tools is, by default, pulling a lot of other dependencies. I don't think it's the role of a library package to recommends packages like liblinear-tools. Cheers Laurent Bigonville -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liblinear1 depends on: ii libblas3 [libblas3gf] 1.2.20110419-5 ii libblas3gf 1.2.20110419-5 ii libc6 2.13-34 ii libgcc11:4.7.1-5 ii libstdc++6 4.7.1-5 Versions of packages liblinear1 recommends: pn liblinear-tools none Versions of packages liblinear1 suggests: pn liblinear-dev 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#682063: firmware-iwlwifi: Version 0.36 breaks firmware loading
Package: firmware-iwlwifi Version: 0.36 Severity: important Hello, With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module with the error: Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request for firmware file 'iwlwifi-6000g2b-5.ucode' failed. Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request for firmware file 'iwlwifi-6000g2b-4.ucode' failed. Rollback to 0.35 fixes the problem. Thanks for your work, Sylvestre PS: modinfo iwlagn gives: # modinfo iwlagn filename: /lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko license:GPL author: Copyright(c) 2003-2011 Intel Corporation i...@linux.intel.com version:in-tree: description:Intel(R) Wireless WiFi Link AGN driver for Linux firmware: iwlwifi-5150-2.ucode firmware: iwlwifi-5000-5.ucode firmware: iwlwifi-6000g2b-5.ucode firmware: iwlwifi-6000g2a-5.ucode firmware: iwlwifi-6050-5.ucode firmware: iwlwifi-6000-4.ucode firmware: iwlwifi-100-5.ucode firmware: iwlwifi-1000-5.ucode firmware: iwlwifi-135-5.ucode firmware: iwlwifi-105-5.ucode firmware: iwlwifi-2030-5.ucode firmware: iwlwifi-2000-5.ucode srcversion: B3B67A8BF067C2881E7C1F8 alias: pci:v8086d0892sv*sd0466bc*sc*i* alias: pci:v8086d0893sv*sd0266bc*sc*i* alias: pci:v8086d0892sv*sd0066bc*sc*i* alias: pci:v8086d0892sv*sd0462bc*sc*i* alias: pci:v8086d0893sv*sd0262bc*sc*i* alias: pci:v8086d0892sv*sd0062bc*sc*i* alias: pci:v8086d0894sv*sd0426bc*sc*i* alias: pci:v8086d0895sv*sd0226bc*sc*i* alias: pci:v8086d0894sv*sd0026bc*sc*i* alias: pci:v8086d0894sv*sd0422bc*sc*i* alias: pci:v8086d0895sv*sd0222bc*sc*i* alias: pci:v8086d0894sv*sd0022bc*sc*i* alias: pci:v8086d088Esv*sd4466bc*sc*i* alias: pci:v8086d088Fsv*sd4266bc*sc*i* alias: pci:v8086d088Esv*sd4066bc*sc*i* alias: pci:v8086d088Esv*sd4464bc*sc*i* alias: pci:v8086d088Fsv*sd4264bc*sc*i* alias: pci:v8086d088Esv*sd4064bc*sc*i* alias: pci:v8086d088Esv*sd4460bc*sc*i* alias: pci:v8086d088Fsv*sd4260bc*sc*i* alias: pci:v8086d088Esv*sd4060bc*sc*i* alias: pci:v8086d0887sv*sd4466bc*sc*i* alias: pci:v8086d0888sv*sd4266bc*sc*i* alias: pci:v8086d0887sv*sd4066bc*sc*i* alias: pci:v8086d0887sv*sd4462bc*sc*i* alias: pci:v8086d0888sv*sd4262bc*sc*i* alias: pci:v8086d0887sv*sd4062bc*sc*i* alias: pci:v8086d0890sv*sd4426bc*sc*i* alias: pci:v8086d0891sv*sd4226bc*sc*i* alias: pci:v8086d0890sv*sd4026bc*sc*i* alias: pci:v8086d0890sv*sd4422bc*sc*i* alias: pci:v8086d0891sv*sd4222bc*sc*i* alias: pci:v8086d0890sv*sd4022bc*sc*i* alias: pci:v8086d0896sv*sd5027bc*sc*i* alias: pci:v8086d0896sv*sd5025bc*sc*i* alias: pci:v8086d0897sv*sd5017bc*sc*i* alias: pci:v8086d0897sv*sd5015bc*sc*i* alias: pci:v8086d0896sv*sd5007bc*sc*i* alias: pci:v8086d0896sv*sd5005bc*sc*i* alias: pci:v8086d08AEsv*sd1027bc*sc*i* alias: pci:v8086d08AEsv*sd1025bc*sc*i* alias: pci:v8086d08AFsv*sd1017bc*sc*i* alias: pci:v8086d08AFsv*sd1015bc*sc*i* alias: pci:v8086d08AEsv*sd1007bc*sc*i* alias: pci:v8086d08AEsv*sd1005bc*sc*i* alias: pci:v8086d0084sv*sd1316bc*sc*i* alias: pci:v8086d0084sv*sd1216bc*sc*i* alias: pci:v8086d0083sv*sd1326bc*sc*i* alias: pci:v8086d0083sv*sd1226bc*sc*i* alias: pci:v8086d0083sv*sd1306bc*sc*i* alias: pci:v8086d0083sv*sd1206bc*sc*i* alias: pci:v8086d0084sv*sd1315bc*sc*i* alias: pci:v8086d0084sv*sd1215bc*sc*i* alias: pci:v8086d0083sv*sd1325bc*sc*i* alias: pci:v8086d0083sv*sd1225bc*sc*i* alias: pci:v8086d0083sv*sd1305bc*sc*i* alias: pci:v8086d0083sv*sd1205bc*sc*i* alias: pci:v8086d0886sv*sd1317bc*sc*i* alias: pci:v8086d0886sv*sd1315bc*sc*i* alias: pci:v8086d0885sv*sd1327bc*sc*i* alias: pci:v8086d0885sv*sd1325bc*sc*i* alias:
Bug#673107: kirkwood: TCP checksum errors when using MTU 9000
Same behaviour :/ dmesg shows : [ 619.869032] [c002f078] (unwind_backtrace+0x0/0xdc) from [c00ab688] (__alloc_pages_nodemask+0x4dc/0x57c) [ 619.878846] [c00ab688] (__alloc_pages_nodemask+0x4dc/0x57c) from [c00ab73c] (__get_free_pages+0x14/0x44) [ 619.888727] [c00ab73c] (__get_free_pages+0x14/0x44) from [c00cfecc] (__kmalloc_track_caller+0x40/0x19c) [ 619.898526] [c00cfecc] (__kmalloc_track_caller+0x40/0x19c) from [c01fa504] (__alloc_skb+0x50/0x10c) [ 619.907976] [c01fa504] (__alloc_skb+0x50/0x10c) from [c01fb5c0] (dev_alloc_skb+0x1c/0x44) [ 619.916599] [c01fb5c0] (dev_alloc_skb+0x1c/0x44) from [bf112264] (rxq_refill+0x7c/0x144 [mv643xx_eth]) [ 619.926363] [bf112264] (rxq_refill+0x7c/0x144 [mv643xx_eth]) from [bf113b0c] (mv643xx_eth_poll+0x5e4/0x68c [mv643xx_eth]) [ 619.937757] [bf113b0c] (mv643xx_eth_poll+0x5e4/0x68c [mv643xx_eth]) from [c02027b4] (net_rx_action+0x90/0x208) [ 619.948171] [c02027b4] (net_rx_action+0x90/0x208) from [c00511d8] (__do_softirq+0xc0/0x1a8) [ 619.956920] [c00511d8] (__do_softirq+0xc0/0x1a8) from [c0051300] (irq_exit+0x40/0x94) [ 619.965108] [c0051300] (irq_exit+0x40/0x94) from [c0028070] (asm_do_IRQ+0x70/0x8c) [ 619.973079] [c0028070] (asm_do_IRQ+0x70/0x8c) from [c0028ad4] (__irq_svc+0x34/0x80) [ 619.981114] Exception stack(0xd5393d50 to 0xd5393d98) [ 619.986220] 3d40: 401a5d20 401a6000 0875 1000 [ 619.994399] 3d60: d5393d9c d358e268 0001 d57dcd80 401a5000 d57dcd80 [ 620.002613] 3d80: d7894cdc d5393d98 c00309d4 c00327c4 0013 [ 620.009295] [c0028ad4] (__irq_svc+0x34/0x80) from [c00327c4] (feroceon_flush_user_cache_range+0x24/0x40) [ 620.019190] [c00327c4] (feroceon_flush_user_cache_range+0x24/0x40) from [d74e9c70] (0xd74e9c70) [ 620.028258] Mem-info: [ 620.030531] Normal per-cpu: [ 620.033325] CPU0: hi: 90, btch: 15 usd: 80 [ 620.038175] active_anon:12271 inactive_anon:12281 isolated_anon:0 [ 620.038191] active_file:10174 inactive_file:9996 isolated_file:0 [ 620.038208] unevictable:0 dirty:26 writeback:0 unstable:0 [ 620.038223] free:13631 slab_reclaimable:1922 slab_unreclaimable:993 [ 620.038240] mapped:5751 shmem:164 pagetables:506 bounce:0 [ 620.067688] Normal free:54524kB min:2032kB low:2540kB high:3048kB active_anon:49084kB inactive_anon:49124kB active_file:40696kB inactive_file:39984kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:259072kB mlocked:0kB dirty:104kB writeback:0kB mapped:23004kB shmem:656kB slab_reclaimable:7688kB slab_unreclaimable:3972kB kernel_stack:1592kB pagetables:2024kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 620.107406] lowmem_reserve[]: 0 0 [ 620.110742] Normal: 12503*4kB 548*8kB 4*16kB 2*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 54524kB [ 620.121725] 21208 total pagecache pages [ 620.125551] 872 pages in swap cache [ 620.129078] Swap cache stats: add 1865, delete 993, find 362/382 [ 620.135074] Free swap = 973040kB [ 620.138422] Total swap = 979832kB [ 620.153822] 65536 pages of RAM [ 620.156937] 14150 free pages [ 620.159818] 1618 reserved pages [ 620.162955] 2110 slab pages [ 620.165783] 34061 pages shared [ 620.168840] 872 pages swap cached -- Regards, Damien Martins -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679665: [Pkg-javascript-devel] Bug#679665: jquery: build-deps not satisfiable in wheezy
On 12-07-19 at 10:34am, Julien Cristau wrote: On Thu, Jul 19, 2012 at 10:32:25 +0200, Jonas Smedegaard wrote: A user may - directly or via a dependent package - rely on the minified version being a file, even if *other* files in this package is usable only when webserver has relaxed its security to follow symlinks. I'm still not following, sorry. How would one rely on such a thing? The very purpose of minified JavaScript files is to reduce download times when serving the files via a slow connection (typically http over a WAN). Some http daemons follow symlinks and serve their source, but some does not by default to limit risk of security flaws. If I install e.g. Apache2 + Drupal + jquery and have apache configured to not follow symlinks (either because that's the default of Apache2 or because I changed the settings to tighten security) then upgrading to a jquery package that provides the minified file as a symlink instead of a real file as before, my website will be broken by that package update. Does it make sense now? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#682064: output of --fingerprint keyid and --with-fingerprint keyfile should be identical
Package: gnupg Version: 1.4.12-4+b1 Severity: minor Tags: upstream Hi, I think the output of gpg --fingerprint keyid and gpg --with-fingerprint exported_key.file should (at least try to) be identical. This is currently not the case: 10:38 evgeni@rodo /tmp % gpg --with-fingerprint AC15B50C.asc pub 1024D/AC15B50C 2004-12-26 Evgeni -SargentD- Golov sarge...@die-welt.net Key fingerprint = 0C04 F872 0963 ADC9 AA83 882B 24A0 1418 AC15 B50C uidEvgeni Golov evg...@golov.eu uidEvgeni Golov evg...@debian.org uidEvgeni Golov sarge...@die-welt.net uidEvgeni Golov (Debian) evg...@debian.org uidEvgeni Golov (30doradus) go...@30doradus.de uidEvgeni Golov (Jabber) sarge...@jabber.ccc.de uidEvgeni Golov (Jabber) sarge...@jabber.die-welt.net uidEvgeni -SargentD- Golov (Backup/Notfall EMail) sarge...@ish.de uidEvgeni Golov (HHU Duesseldorf) evgeni.go...@uni-duesseldorf.de sub 1024g/AA637FD1 2004-12-26 10:38 evgeni@rodo /tmp % gpg --fingerprint AC15B50C pub 1024D/AC15B50C 2004-12-26 Key fingerprint = 0C04 F872 0963 ADC9 AA83 882B 24A0 1418 AC15 B50C uid Evgeni -SargentD- Golov sarge...@die-welt.net uid Evgeni Golov evg...@golov.eu uid Evgeni Golov evg...@debian.org uid Evgeni Golov sarge...@die-welt.net uid Evgeni Golov (Debian) evg...@debian.org uid Evgeni Golov (Jabber) sarge...@jabber.die-welt.net uid Evgeni -SargentD- Golov (Backup/Notfall EMail) sarge...@ish.de uid Evgeni Golov (HHU Duesseldorf) evgeni.go...@uni-duesseldorf.de sub 1024g/AA637FD1 2004-12-26 As you can see, the first UID is printed above the fingerprint when using --with-fingerprint. This confuses tools like gpgsigs as it does not recognise this as an uid line and thus ignores the uid completely. Regards Evgeni -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg depends on: ii dpkg 1.16.7 ii gpgv 1.4.12-4+b1 ii install-info 4.13a.dfsg.1-10 ii libbz2-1.01.0.6-3 ii libc6 2.13-34 ii libreadline6 6.2-8 ii libusb-0.1-4 2:0.1.12-23 ii zlib1g1:1.2.7.dfsg-13 Versions of packages gnupg recommends: pn gnupg-curl none ii libldap-2.4-2 2.4.31-1 Versions of packages gnupg suggests: ii eog 3.4.2-1 pn gnupg-doc none ii imagemagick 8:6.7.7.10-2 ii libpcsclite1 1.8.4-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680861: Bug #680861 - change postinst or bug in debhelper?
On 19.07.2012 10:00, Reinier Haasjes wrote: Hi All, I'm trying to resolve bug #680861 where the problem is that if the config of aiccu is incorrect and thus the program can't start it breaks the upgrade. If the configuration is incorrect and aiccu fails because of that, I think it is also correct if the postinst fails. Otherwise this problem would go unnoticed. I want to change this to invoke-rc.d aiccu start || true but then I have to remove the #DEBHELPER# line and do it 'manually', ofcourse this isn't the problem but I prefer to use debhelper as much as possible. The problem is that if I (/aiccu) have this problem than other packages should have the same problem and this would be a debpacker bug. Is this a debhelper bug and should I report a bug or should I just replace the code so it works for aiccu? You can use dh_installinit's --error-handler option for that. But as said, I don't think it is a good idea to hide errors. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
On 19 July 2012 09:01, AZ Imballaggi S.r.l. - Enrico Ghera enr...@azimballaggi.com wrote: b) updates/upgrades: * first of all dbconfig shoud read the package's conf, and generate a new one for itself. * update/upgrade package I'm of an opinion db-config behaviour was as expected and correct to its design. While it's an awesome tool which greatly helps with upgrades, I actually would be tempted to say its fully automatic behaviour should be limited (and this limitation clearly communicated) to local database installations only. While it'd be great to have all the possible configurations supported, the list of things that can possibly go wrong with remote database is quite long and anyway, if users moves database to remote host you can't really treat this setup as basic anymore; user moves the database conciously and is supposed to update dbconfig configuration as a part of this move. My knowledge about dbconfig is not great, however reading packages configs doesn't sound like dbconfig's job to me. If we wanted to do this, again the list of things that can potentially go wrong is quite long, eg. what if I split bacula config into multiple files and include one from within another one? Should dbconfig read all of them? Some of them? If so, which ones? I think the correct tool for the job here would be Puppet, which could manage Bacula as well as dbconfig flat configuration file and change database location accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
On Wed, 18 Jul 2012 22:44:57 +0200, Luca Capello wrote: Hi there! Alexander, thank you for the detailed explanation, which means that this bug should stay open (and retitled, in case). On Wed, 18 Jul 2012 19:55:29 +0200, Alexander Golovko wrote: On Wed, 18 Jul 2012 18:35:07 +0200, AZ Imballaggi S.r.l. - Enrico Ghera wrote: Il 18/07/2012 18:03, Luca Capello ha scritto: Hi there! On Wed, 18 Jul 2012 03:18:44 +0200, Alexander Golovko wrote: So, this is not a bug in package, but dbconfig-common habits. Ofcourse, we should describe database upgrade habits in README.Debian UPGRADE section. If you want to do that, then please go ahead, but strictly speaking this is not something that belongs to Debian, but in upstream manual. Debian provides a way to manage local and remote database, via dbconfig-common. If the admin changes that, than she/he should *know* that automatic upgrades could fail (Debian can not assure all possible configurations). We should describe differences from upstream - dbconfig-common usage and common troubles. I slightly disagree, simply because dbconfig-common is the Debian way of doing such things. If we go on the path of documenting differences WRT upstream, than each package using dbconfig-common should do the same, which is IMHO plainly wrong. You are right, will be better to make package more standard and similarly other packages with dbconfig-common. It is something difficult for me, because english is not native for me, but i will try later. Do not worry for the language, having a not-completely-English documentation is better than no documentation at all. Enrico, I am sorry for the bug, but I bet that having configured the remote database via dbconfig-common (thus via `dpkg-reconfigure bacula-director-mysql`) would have resulted in a correct upgrade. No, we should not use dpkg-reconfigure for change database parameters without database reinstallation. If we run dpkg-reconfigure, dbconfig ask to reinstall database and rewrite config file In choice of don't reinstall database, dbconfig rewrite config file and add to it 'dbc_install=false', so this will stop future database upgrades. IMHO this is a bug in dbconfig-common or in the way we use it, given that we should be able to use it *without* database reinstallation. Argh, this is a my fail! dpkg-reconfigure correctly work if choose do not reinstall database. It was because i try on not very clean system. But this is don't solve this problem, because it can change database parameters only with database reinstallation. Yes, we can say reinstall to already existed database and then ignore error about already existed tables, but, IMHO, it is better to change config by hands and then run dpkg-reconfigure without database reinstallation. just to understand better (and avoid other useless bug reports): everytime I modify my database settings I should run dpkg-reconfigure? doing the work twice? (one for actual conf and one for dbconfig) or I should run dpkg-reconfigure and it updates my conf as well? or my brain is dead and I have not understood anything? If you change only database connect parameters (host, dbname, user, password, etc), than you should not run dpkg-reconfigure, but should make changes in two places: 1. in bacula config 2. in dbconfig files (/etc/dbconfig-common/bacula-director-(mysql|pgsql|sqlite3).conf IMHO this is prone to errors, which is why I blindly thought that dpkg-reconfigure would have done the trick. dbconfig-common can't rename database (#439080). But changing /etc/dbconfig-common/*.conf files is not anything incorrect. As i understand, it is normal for dbconfig-common to make changes in /etc/dbconfig-common/package.conf and then run dpkg-reconfigure package without database reinstallation. It is a ususal for all debian packages, that use dbconfig-common. Am i right? So, there best solution will be make bacula-dir.conf consistent on dpkg-reconfigure. We can do this by two methods: 1. dbconfig-common will generate additional file from template with database parameters (dbc_generate_*) and include it from bacula-dir.conf 2. substitute variables itself. This is will be very simple, when we migrate config files under ucf control. Enrico, in the end you were right, which also means that you discovered a bug in the Bacula packaging (or in dbconfig-common, I would say). Thx, bye, Gismo / Luca -- with best regards, Alexander Golovko email: alexan...@ankalagon.ru xmpp: alexan...@ankalagon.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681901: datapm: missing dependency on python-pkg-resources
tags 681901 + patch thanks Hi, the obvious patch can be found at [1]. Regards Evgeni [1] https://github.com/evgeni/dpm/commit/76c40035880fae740edc8d193f21d168b2893dfe -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674153: [3.2.16 - 3.2.17 regression] High reported CPU load when idle
On 07/18/2012 01:25 AM, Jonathan Nieder wrote: Anders Boström wrote: Starting with 3.2.17-1, the CPU load accounting is broken when the computer is idle. The CPU load is reported as 0.50 when idle. 3.2.16-1 don't suffer from this problem. Suspected patch is the upstream patch sched: Fix nohz load accounting -- again! commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 to 3.2 and originating from c308b56b5398779cd3da0f62ab26b0453494c3d4 . Please test the attached patch against a 3.2.y kernel, for example following the instructions below: Good news everyone. I have tested kernel 3.2.21 and the attached patch (based on 5167e8d I presume) seems to be fixing all the load average oddities. I've compiled following kernels: * 3.2.21-hz (CONFIG_NO_HZ=n) * 3.2.21-no-hz (CONFIG_NO_HZ=y) * 3.2.21-no-hz-5167e8d (CONFIG_NO_HZ=y) + attached patch The load reported by 3.2.21-hz and 3.2.21-no-hz-5167e8d is exactly the same under different CPU usage. Without the patch the tickless kernel tends to show lower load values than what you would expect. I can't say much for the case when load is too high on an idle machine, because I haven't been able to reproduce the problem in the first place. To summarize: the bug is present in unpatched kernel and fixed by applying the attached patch. No nasty side effects noticed. -- Lesław Kopeć signature.asc Description: OpenPGP digital signature
Bug#682066: kphotoalbum crashes when starting Advanced Slide Show from the KIPI Plugin Collection
Package: kphotoalbum Version: 4.2-1 Severity: important kphotoalbum crashes when starting Advanced Slide Show from the KIPI Plugin Collection (Plugins - Tools - Advanced SlideShow). Interestingly the Slideshow KIPI-Plugin works when being started from digicam. That means that the crash it is not opengl or nvidia related related. (Kernel module nouveau, Gallium 0.4 on NV46, NVIDIA G72M (GeForce Go 7400), OpenGL/ES-Version 2.1 Mesa 8.0.3) If kphotoalbum is started from the command line, there the following error message will be issued: kphotoalbum: Symbol `_ZTVN4KIPI15ImageInfoSharedE' has different size in shared object, consider re-linking -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kphotoalbum depends on: ii kde-runtime4:4.8.4-1 ii libc6 2.13-33 ii libexiv2-120.23-1 ii libgcc11:4.7.1-2 ii libjpeg8 8d-1 ii libkdcraw204:4.8.4-1 ii libkdecore54:4.8.4-3 ii libkdeui5 4:4.8.4-3 ii libkio54:4.8.4-3 ii libkipi8 4:4.8.4-1 ii libphonon4 4:4.6.0.0-2 ii libqt4-dbus4:4.8.2-1 ii libqt4-qt3support 4:4.8.2-1 ii libqt4-sql 4:4.8.2-1 ii libqt4-sql-sqlite 4:4.8.2-1 ii libqt4-xml 4:4.8.2-1 ii libqtcore4 4:4.8.2-1 ii libqtgui4 4:4.8.2-1 ii libstdc++6 4.7.1-2 ii phonon 4:4.6.0.0-2 Versions of packages kphotoalbum recommends: pn khelpcenter none ii kipi-plugins 4:2.6.0-1+b1 Versions of packages kphotoalbum suggests: ii mplayerthumbs 4:4.8.4-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681741: libreoffice: LibreOffice user installation could not be processed etc.
On Thu, Jul 19, 2012 at 03:06:34AM -0400, Gedalya wrote: 1. Install just the base system I did: chreated a wheezy chroot. 2. apt-get install lxde (this doesn't depend on libreoffice) 3. Log in to lxde as a regular user I did: Logged into my normal system (via ssh). 4. Menu Accessories Root Terminal (uses gksu) As as you said in an other post, the $HOME there is /root. Anyway: 5. As root, apt-get install libreoffice I did: rene@frodo:~/tmp$ sudo debootstrap wheezy wheezy3 http://192.168.0.2/debian rene@frodo:~/tmp$ rm -rf ~/.config/libreoffice rene@frodo:~/tmp$ sudo chroot wheezy3 root@frodo:/# useradd -u 1000 -m rene root@frodo:/# exit rene@frodo:~/tmp$ sudo mount /home/rene/ wheezy3/home/rene -obind rene@frodo:~/tmp$ gksu chroot wheezy3 apt-get install libreoffice [...] (some packages failed because Java needing /proc) rene@frodo:~/tmp$ sudo mount -t proc proc wheezy3/proc rene@frodo:~/tmp$ gksu chroot wheezy3 dpkg --configure -a This creates the directory .config/libreoffice under the *user's* home directory, owned by *root*. After the steps above: rene@frodo:~/tmp$ ls -l1 /home/rene/.config/ | grep libreoffice rene@frodo:~/tmp$ No, it didn't create anything. Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682067: gitrepo as FAI_CONFIG_SRC fails with fatal: Not a git repository /var/lib/fai/config/.git
Package: fai-client Version: 4.0.3 Tags: patch When I use a git repository as config source for a FAI network install, FAI exits after trying to setup the config space from git. Inside /var/lib/fai there were not only the files I checked into the git repo but also the git control files (e.g. HEAD, refs/). Those should not be in /var/lib/fai but in /var/lib/fai/.git/ IMO the clone command in get-config-dir-git should check out to $GIT_DIR, see the patch at https://github.com/bneuburg/fai/commit/1b567f8c6790176c142f8373446265fa9b4e00cf After fixing it, installation is successful. Regards, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682068: piuparts: Please mount selinuxfs to /sys/fs/selinux
Package: piuparts Version: 0.45 Severity: wishlist Hi, Could you please mount selinuxfs to /sys/fs/selinux as it should be now the case on wheezy systems. We are in the process of removing the /selinux directory for wheezy+1 (see #658070). The current version of libselinux is checking both /sys/fs/selinux and /selinux (in that order) to find a selinuxfs, so things should continue to work properly in any cases. As a matter of compatibility with older systems, it could be interesting to lookup where the selinuxfs file system is mounted on the host machine and mount it at the same location in the chroot. Cheers Laurent Bigonville -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages piuparts depends on: ii debootstrap1.0.42 ii dpkg 1.16.7 ii lsb-release4.1+Debian7 ii lsof 4.86+dfsg-1 ii python 2.7.3-1 ii python-debian 0.1.21 piuparts recommends no packages. Versions of packages piuparts suggests: ii schroot 1.6.1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: #682010 re celt and mumble referred to the TC
Hi Ian, Being cc'd on this would have been nice, so apologies in advance if I messed up any quoting by pasting stuff in. On Thu, Jul 19, 2012 at 12:26:01AM +0100, Ian Jackson wrote: Note: this evening we think we have found a security expert who is willing to audit the CELT 0.7.1 codec for issues and possibly provide patches, assuming this is reasonably feasible. This sounds like a good option to me. I will write to the security team and ask them for their opinion about CELT. From what you say I think: - We should try to address the security problems, if any, in the celt 0.7.1 codec. An audit would be very good. You understand this is a fairly arbitrary 'daily' snapshot of an experimental research codec, from ~2.5 years ago, that nobody has looked at since that day, that nobody has committed to maintaining, that its author has explicitly said he has no interest in maintaining, that has had large parts completely rewritten since for all manner of reasons, and is bitstream incompatible with every other snapshot that was ever released, right? And that its successor code has been reviewed in detail by some of the brightest minds of the IETF, prior to accepting that code as being the normative part of a proposed standard (which has now occurred) - and without exception, all of them said this is way too deep for me, I'm going to have to take the WG report on faith that it's sufficiently debugged now ... If skilled people have time for auditing, I'd love to see the code from the RFC pass under their eyes as a better, more enduring, use of their time. But this isn't something people are likely to find high school programming errors in from a quick read through or automated scan, or are likely to shake things out of just with simple fuzz testing. On the contrary, I fully expect mumble to have also EOL'd this long before anyone else, except perhaps the most dedicated blackhats, have understood even half of what goes on in this code, or the astronomical number of state transitions that are possible within it. And they have a 2.5 year head start on anyone who might try starting from today. - This is a serious problem for mumble at least and is arguably RC. Yes, mumble has a serious problem, that is arguably RC. In fact it has several of them aside from this corner that people have painted themselves into with it ... - Its primary author, who is also a DD and comaint of the package, is currently MIA with a new job that has consumed pretty much every minute of his time for the last 2 years or so now. The people who remain that are hacking on it, can't even do a formal new release at present, because he is the only one with access to the systems they need to do that, and is not available to do so. They are all busy too, so there is very much a culture of close your eyes and pretend it's all ok there at present. - It has other deps in the distro aside from this one that appear to be near enough to completely unmaintained too. Have a look at the code for zeroc-ice, and the ABI breaking patch that was blindly applied for gcc 4.7 and then left unfixed until Svedrin and I got stuck with the job of unscrewing that, and share in our tears ... - It has a small subset of users who would rather risk everyone's systems, than simply update their most ancient servers and tell their friends that it's time for a security update too. Which is all it takes to 'fix' this. FWIW, even the original poster of the bug in question later agreed in calmer discussion on IRC that the Right Thing for mumble to do is to release 1.3 and accelerate the migration, and that is only being delayed now by the first point above. This particular problem being raised here was entirely avoidable. Only a lack of foresight that the primary author of this software was going to be taken by the rapture, and a subsequent failure to plan for that loss by migrating to options that actually have maintainers ahead of the crunch date, have left us in the situation we are in today. These aren't things I usually associate with the idea of something being viable stable release candidate software ... If I'd known that Thorvald was not going to be here to manage this transition for Wheezy, I'd have never agreed to shipping libcelt in the Squeeze release either, and would have instead kept it in sid only. If I'd known that his plan to have all other distros ship the 0.7.1 release as a temporary interoperability snapshot would fail as dismally as it did (no other distro shipped this version except debian derivatives who took it from us), I'd have similarly vetoed the idea of shipping this as a public library in the last stable release too. Mumble already ships this as an embedded private library on every system other than direct Debian derivatives. I assume it would be possible to reintroduce a celt package which was very similar to the one recently
Bug#663916: RFS: phonetisaurus
Hi Bart! On 19/07/2012 07:23, Bart Martens wrote: I see that you updated the package at mentors around 24 June 2012, but the package is no longer there. What happened ? It happened that I contacted Jakub Wilk that is wishing to review and to sponsor both openfst and phonetisaurus. I published the git repositories on collab-maint and we are using them to keep track of the latest updates (openfst packages expecially are big and it would be a waste of time and resources to upload them on mentors). The latest version of phonetisaurus is available at: git://git.debian.org/git/collab-maint/phonetisaurus.git You can browse sources at: http://anonscm.debian.org/gitweb/?p=collab-maint/phonetisaurus.git Bests, Giulio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682069: yui-compressor: Can't find bundle for base name org.mozilla.javascript.resources.Messages, locale en_US
Package: yui-compressor Version: 2.4.7-1 Severity: important Steps: $ wget https://raw.github.com/thatcher/openseadragon/master/openseadragon.js $ yui-compressor -o test.js openseadragon.js See attached error.log file. Thanks much ! -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages yui-compressor depends on: ii default-jre-headl 1:1.6-40 Standard Java or Java compatible R ii gcj-4.4-jre-headl 4.4.5-2Java runtime environment using GIJ ii gcj-jre-headless 4:4.4.5-1 Java runtime environment using GIJ ii java-wrappers 0.1.16 wrappers for java executables ii libjargs-java 1.0.0-2Command-line argument parsing for ii openjdk-6-jre-hea 6b18-1.8.13-0+squeeze2 OpenJDK Java runtime, using Hotspo yui-compressor recommends no packages. yui-compressor suggests no packages. -- no debconf information Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21) Caused by: java.util.MissingResourceException: Can't find bundle for base name org.mozilla.javascript.resources.Messages, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:805) at org.mozilla.javascript.ScriptRuntime$DefaultMessageProvider.getMessage(ScriptRuntime.java:3608) at org.mozilla.javascript.ScriptRuntime.getMessage(ScriptRuntime.java:3592) at org.mozilla.javascript.ScriptRuntime.getMessage0(ScriptRuntime.java:3540) at org.mozilla.javascript.Parser.addError(Parser.java:145) at org.mozilla.javascript.Parser.reportError(Parser.java:160) at org.mozilla.javascript.Parser.memberExprTail(Parser.java:2039) at org.mozilla.javascript.Parser.memberExpr(Parser.java:1977) at org.mozilla.javascript.Parser.unaryExpr(Parser.java:1832) at org.mozilla.javascript.Parser.mulExpr(Parser.java:1761) at org.mozilla.javascript.Parser.addExpr(Parser.java:1742) at org.mozilla.javascript.Parser.shiftExpr(Parser.java:1722) at org.mozilla.javascript.Parser.relExpr(Parser.java:1696) at org.mozilla.javascript.Parser.eqExpr(Parser.java:1652) at org.mozilla.javascript.Parser.bitAndExpr(Parser.java:1641) at org.mozilla.javascript.Parser.bitXorExpr(Parser.java:1630) at org.mozilla.javascript.Parser.bitOrExpr(Parser.java:1619) at org.mozilla.javascript.Parser.andExpr(Parser.java:1607) at org.mozilla.javascript.Parser.orExpr(Parser.java:1595) at org.mozilla.javascript.Parser.condExpr(Parser.java:1578) at org.mozilla.javascript.Parser.assignExpr(Parser.java:1563) at org.mozilla.javascript.Parser.expr(Parser.java:1542) at org.mozilla.javascript.Parser.statementHelper(Parser.java:1221) at org.mozilla.javascript.Parser.statement(Parser.java:726) at org.mozilla.javascript.Parser.parseFunctionBody(Parser.java:482) at org.mozilla.javascript.Parser.function(Parser.java:611) at org.mozilla.javascript.Parser.primaryExpr(Parser.java:2255) at org.mozilla.javascript.Parser.memberExpr(Parser.java:1974) at org.mozilla.javascript.Parser.unaryExpr(Parser.java:1832) at org.mozilla.javascript.Parser.mulExpr(Parser.java:1761) at org.mozilla.javascript.Parser.addExpr(Parser.java:1742) at org.mozilla.javascript.Parser.shiftExpr(Parser.java:1722) at org.mozilla.javascript.Parser.relExpr(Parser.java:1696) at org.mozilla.javascript.Parser.eqExpr(Parser.java:1652) at org.mozilla.javascript.Parser.bitAndExpr(Parser.java:1641) at org.mozilla.javascript.Parser.bitXorExpr(Parser.java:1630) at org.mozilla.javascript.Parser.bitOrExpr(Parser.java:1619) at org.mozilla.javascript.Parser.andExpr(Parser.java:1607) at org.mozilla.javascript.Parser.orExpr(Parser.java:1595) at org.mozilla.javascript.Parser.condExpr(Parser.java:1578) at org.mozilla.javascript.Parser.assignExpr(Parser.java:1563) at org.mozilla.javascript.Parser.expr(Parser.java:1542) at
Bug#682070: Sparkleshare icon flashes erratically
Package: sparkleshare Version: 0.9.0-1 Control: severity -1 critical Hi, The array used to display the moving status icon when there it is performing work is filled incorrectly, causing the icon to disappear and reappear in the icon area. This is a major usability setback as the icon is a large part of sparkleshare's UI. cmn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682071: nautilus: Built-in search does not work for non-indexed directories when tracker is enabled
Package: nautilus Version: 3.4.2-1 Severity: normal Dear Maintainer, when tracker is enabled, search from the built-in search area in Nautilus doesn't find files that are either not yet indexed or outside the watched directories. However, gnome-search-tool do find those files properly. I guess (although I have no insight) the right behaviour would be to first check the tracker indexes, then fallback to mlocate, and then, if it also yields no result, to do a regular search. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-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 nautilus depends on: ii desktop-file-utils 0.20-0.1 ii gsettings-desktop-schemas 3.4.2-1 ii gvfs 1.12.3-1+b1 ii libatk1.0-02.4.0-2 ii libc6 2.13-33 ii libcairo-gobject2 1.12.2-2 ii libcairo2 1.12.2-2 ii libexempi3 2.2.0-1 ii libexif12 0.6.20-2 ii libgail-3-03.4.2-2 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.32.3-1 ii libglib2.0-data2.32.3-1 ii libgnome-desktop-3-2 3.4.2-1 ii libgtk-3-0 3.4.2-2 ii libnautilus-extension1a3.4.2-1 ii libnotify4 0.7.5-1 ii libpango1.0-0 1.30.0-1 ii libselinux12.1.9-5 ii libtracker-sparql-0.14-0 0.14.1-2 ii libx11-6 2:1.5.0-1 ii libxml22.8.0+dfsg1-4 ii nautilus-data 3.4.2-1 ii shared-mime-info 1.0-1 Versions of packages nautilus recommends: ii brasero 3.4.1-2 ii eject2.1.5+deb1+cvs20081104-11 ii gnome-sushi 0.4.1-3 ii gvfs-backends1.12.3-1+b1 ii librsvg2-common 2.36.1-1 Versions of packages nautilus suggests: ii eog3.4.2-1 ii evince [pdf-viewer]3.4.0-2+b1 ii totem 3.0.1-8 ii tracker0.14.1-2 ii vlc [mp3-decoder] 2.0.2-2 ii vlc-nox [mp3-decoder] 2.0.2-2 ii xdg-user-dirs 0.14-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681901: datapm: missing dependency on python-pkg-resources
2012/7/19 Evgeni Golov evg...@golov.de: tags 681901 + patch thanks Hi, the obvious patch can be found at [1]. Regards Evgeni [1] https://github.com/evgeni/dpm/commit/76c40035880fae740edc8d193f21d168b2893dfe Evgeni, thanks for your patch, right for me. -- J. Félix Ontañón Carmona Emergya Consultoría -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682072: gnome-search-tool: Results list incomplete / incorrectly refreshed after the first search
Package: gnome-search-tool Version: 3.4.0-2 Severity: normal Dear Maintainer, when starting gnome-search-tool and starting a search, the results count is always greater than the number of results actually displayed in the list below. If I press enter and do the same search again, OR if I click into the list (in a blank area for instance), everything is refreshed and displayed properly. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-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 gnome-search-tool depends on: ii gconf-service 3.2.5-1 ii gconf2 3.2.5-1 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-33 ii libgconf-2-43.2.5-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgtk-3-0 3.4.2-2 ii libice6 2:1.0.8-2 ii libsm6 2:1.2.1-2 gnome-search-tool recommends no packages. Versions of packages gnome-search-tool suggests: ii yelp 3.4.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681901: datapm: missing dependency on python-pkg-resources
Hi On Thu, Jul 19, 2012 at 11:55:45AM +0200, J. Félix Ontañón wrote: [1] https://github.com/evgeni/dpm/commit/76c40035880fae740edc8d193f21d168b2893dfe Evgeni, thanks for your patch, right for me. Do you want to upload yourself (and need a sponsor), or should I drop an NMU tonight for this and the FTBFS I filled? Regards Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680244: xpra: consider adding bug fixes from the upstream stable branch 0.3.x before release?
Hi, I see you uploaded 0.3.3 to unstable. I have been using it for a week now without problems. Thanks! Have you considered asking for a freeze exception? I can work with upstream to produce a list of bugs that it fixes if that helps. -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676123: jed: FTBFS: UTF-8 mode not enabled-- test_search_char not run.
+++ Wookey [2012-07-19 00:03 +0100]: +++ Antti-Juhani Kaijanaho [2012-07-18 22:30 +0300]: libslang was broken for a while recently in testing: I meant unstable of course. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682063: firmware-iwlwifi: Version 0.36 breaks firmware loading
Sylvestre Ledru sylves...@debian.org writes: Package: firmware-iwlwifi Version: 0.36 Severity: important Hello, With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module with the error: Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request for firmware file 'iwlwifi-6000g2b-5.ucode' failed. Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request for firmware file 'iwlwifi-6000g2b-4.ucode' failed. Rollback to 0.35 fixes the problem. Thanks for your work, Sylvestre PS: modinfo iwlagn gives: # modinfo iwlagn filename: /lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko Your kernel is not in the archive. The firmware-iwlwifi package support all kernels in squeeze, wheezy and sid. You need to keep track of the necessary firmware yourself if you want to run other kernel versions. Bjørn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682059: root-system: Bunch of not-installed libs and include files
Hi, I am well aware of #557017 that you reported the same problem more than two years ago ;-) While about half of missed libraries depend on packages that have license issue or unavailable in Debian, most of the rest are rarely needed by Debian ROOT users, and it's my fault root-plugin-graph2d-gviz package is missing, I would like to bring it back when I get a second reason for the package to go through NEW queue. Regrads, Lifeng On 10:10 Thu 07/19/12 Jul , Pavel Reznicek wrote: I tried to built myself the latest root-system version from debian mentors (but I believe the same issue is present in present debian version 5.34.00-1) and noticed that there is bunch of built but not installed files (mostly libaries and include files, see below). Is it intentional or a bug ? It looks like that at least part of them could be recovered but putting appropriate plugin package into the debian/control file (e.g. for root-plugin-graph2d-gviz is missing in there). -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597199: pm-utils : stash kernel on upgrades
On 12-07-18 06:24 PM, Michael Biebl wrote: Hi, Hi Michael, I need to be honest and say that I don't like the approach to do this via a sysvinit or upstart script which does the copy on each and every boot, even when a/ the kernel doesn't actually change during runtime because it isn't upddated b/ the user doesn't actually use hibernation OK. That's a fair assessment. TBH, I was not entirely happy with the approach but wanted to put something out there to try to solicit comment and more importantly, ideas. Also, running grub-mkconfig on every boot is is a very costly operation which can take several seconds. Right. Agreed. And now that I have had some time to read your entire critique and reflect, probably that belongs in the actual resuming-from-hibernate code path. Running the grub update on *every* hibernation is wrong, too. It can probably gated with some logic to see if the grub config is newer than stashed kernel to avoid it every time. I will look into that. What happens to those grub entries after a reboot? It seems to me they are left there as stale hibernate entries. No. They are cleaned out by the resume|thaw code path in /etc/pm/sleep.d/20_update-grub. Stale entries are cleared during boot, No, during thaw (i.e. return from hibernation). so we will have those entries at least for one boot cycle, right? No, per above. I also don't see any error handling anywhere, in case /boot was not writable/big enough to create the stashed kernel. This can happen if you have a separate /boot partition which is small or mounted ro. Yes. This was just proof-of-concept to solicit critique on the approach. Of course a final implementation would have to have error handling. 08_linux_thaw looks like it could be painful to maintain, it looks rather complex and contains stuff like kexec. Is everything there really necessary? Is that a copy of /etc/grub.d/10_linux which has been extended by you? Yes, it is a copy of /etc/grub.d/10_linux modified to handle the Resume from Hibernation grub entry. I debated simply adding that handling to the 10_linux hook or maintaining the spirit of grub.d's modularity. Obviously I chose the latter. I'm certainly not against the former, it just means more red-tape in the form of trying to get a modification into grub as well as pm-utils, co-ordinated. TBH, I'm not entirely optimistic that grub will take such a modification since it has reliance on the bits also being in pm-utils, tying the dependency of the two packages more tightly together. It has stuff like /etc/linuxmint/info in there which make me curious where it comes from as it generates warnings on my Debian system. I'm not a grub expert, so I'm a bit wary about having to maintain such a file. Yeah, that is just an artifact of the fact that my system is a Linux Mint system. Of course, if the work were applied to Debian, such a thing would not be in that file. Additionally, the duplication of linux_entry() in that file begs for some abstraction and/or sharing of that function amongst hooks. But again, my submission was just a PoC for comment. To sum up: I'm not happy about the general approach to do this kernel stashing during boot and running grub update at boot and before hibernation and the implementation has its flaws, too. Well, I can agree with getting that stuff out of the boot path given your idea below, but if it's not in the boot path, it pretty much has to be in the hibernate path. Not having it in both the boot path and not in the hibernate path is pretty much like wanting your cake and eating it too. You might look into the /etc/kernel/ hooks, which are run whenever a kernel is upgraded. Maybe it allows to do the kernel stashing in a much cleaner way. Yes, this is a good idea. I tend to forget that there is a hook system called during kernel upgrades and indeed, it would be a better place to stash the running kernel. I would also very much prefer, if the grub specific hook is moved into grub proper. grub already contains the hooks for xen kernels or the recovery mode. Yes. The recovery mode is handled by 10_linux for the kernels that are handled by 10_linux but xen kernels are handled by their own hook in 20_linux_xen, just like my own 08_linux_thaw, and is very much a duplication+modification of 10_linux, again just like my own 08_linux_thaw. IOW, if xen kernel handling is the model to follow, then my 08_linux_thaw very much follows the model. Let me take a moment now to thank you very much for the critique. It was exactly what I was looking for. Thank-you. With any luck I will find the time to try to rework my implementation. Cheers, b. signature.asc Description: OpenPGP digital signature
Bug#680244: xpra: consider adding bug fixes from the upstream stable branch 0.3.x before release?
On Thu, Jul 19, 2012 at 01:03:45PM +0300, Timo Juhani Lindfors wrote: I see you uploaded 0.3.3 to unstable. I have been using it for a week now without problems. Thanks! ---end quoted text--- Please do. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#682073: strongswan-starter: /etc/ipsec.secrets includes non-existing file
Package: strongswan-starter Version: 4.6.4-5 Severity: normal Hi, /etc/ipsec.secrets includes non-existing /var/lib/strongswan/ipsec.secrets.inc file. That file doesn't seems to be created by debconf anymore. # this file is managed with debconf and will contain the automatically # created private key include /var/lib/strongswan/ipsec.secrets.inc There is only one reference to that file in debian/strongswan-starter.postinst Cheers Laurent Bigonville -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (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#682074: texmaker: Restore session does not work after fresh boot
Package: texmaker Version: 3.3.4-1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Attempt to restore session * What exactly did you do (or not do) that was effective (or ineffective)? change default /tmp from ram to HD space and to keep files following a boot * What was the outcome of this action? Session restore worked * What outcome did you expect instead? I have reported a bug to the developer but he does not seem inclined to change the location of restore session data from /tmp to something like ~/.config/xm1 (see https://code.google.com/p/texmaker/issues/detail?id=686). Perhaps for the debian package, it can be patched. *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages texmaker depends on: ii libc6 2.13-33 ii libgcc1 1:4.7.1-2 ii libpoppler-qt4-3 0.18.4-3 ii libqt4-network4:4.8.2-1 ii libqt4-xml4:4.8.2-1 ii libqtcore44:4.8.2-1 ii libqtgui4 4:4.8.2-1 ii libqtwebkit4 2.2.1-4+b1 ii libstdc++64.7.1-2 ii texmaker-data 3.3.4-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages texmaker recommends: ii aspell 0.60.7~20110707-1 pn asymptote none ii ghostscript 9.05~dfsg-6 pn ibus-qt4none ii myspell-en-us [myspell-dictionary] 1:3.3.0-3 pn netpbm none pn psutils none ii texlive-latex-extra 2012.20120611-1 texmaker 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#677335: Fwd: Bug#677335: gforge-web-apache2: PHP Warning: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression'
Hi. Thorsten Glaser t.gla...@tarent.de writes: On Wed, 18 Jul 2012, Olivier Berger wrote: Do you have any idea on how to try and investigate that ? Yes I did so (told people in IRC, IIRC). $ sudo a2dismod deflate This seems to be a new Debian standard setting for new installations. We can add a workaround to not use our own gzip compression *at all* if mod_deflate is detected, although that’ll kill it too if it’s not active. OK, we have a workaround then. I expect the behaviour to change a bit with Apache 2.4 too, according to #601033 (AddOutputFilterByType used in deflate.conf was an absolete parameter in apache 2.2 apprently, etc.). Thanks for your help. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660488: miredo: FTBFS `pkglibdir' is not a legitimate directory for `PROGRAMS'
* Rémi Denis-Courmont r...@remlab.net, 2012-07-11, 09:54: I've put the files at http://www.remlab.net/files/miredo/debian/ until someone can sponsor the upload. debdiff is: 89 files changed, 10731 insertions(+), 6211 deletions(-) I'm afraid it's a bit too much at this point of the release cycle. Could you please prepare an upload with _only_ a dedicated fix for this RC bug? No I don't have time to work around the Debian process. I didn't ask you to work around anything. And this was made a long time before the freeze. That's unfortunate. Once I get my time machine working, I'll travel back to April and then sponsor your changes. Would that be okay? In the mean time, let's figure out what went wrong: Did you ask your previous sponsor to upload the package? If that didn't work out, did you ask at debian-mentors@lists.d.o? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682075: RFP: osqa -- an open source stackexchange clone
Package: wnpp Severity: wishlist * Package name : osqa * URL : http://www.osqa.net/ * Licence : GPLv3: http://meta.osqa.net/questions/40/what-open-source-license-is-osqa-using Description : open source stackexchange clone From the homepage: OSQA is the free, open source QA system you've been waiting for. Your OSQA site is more than just an FAQ page, it is a full-featured QA community. Users earn points and badges for useful participation, and everyone in the community wins.
Bug#682076: FTBFS if built twice in a row
Source: httpie Version: 0.1.6+20120309git-2 Severity: serious Tags: patch Justification: fails to build from source Hi, httpie fails to build if built twice in a row: dpkg-buildpackage: source package httpie dpkg-buildpackage: source version 0.1.6+20120309git-2 dpkg-buildpackage: source changed by Bartosz Fenski fe...@debian.org dpkg-buildpackage: host architecture amd64 dpkg-source --before-build httpie-0.1.6+20120309git fakeroot debian/rules clean dh clean --with python2 dh_testdir dh_auto_clean running clean removing 'build/lib.linux-x86_64-2.6' (and everything under it) 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.6' does not exist -- can't clean it running clean removing 'build/lib.linux-x86_64-2.7' (and everything under it) 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it removing 'build' dh_clean dpkg-source -b httpie-0.1.6+20120309git dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building httpie using existing ./httpie_0.1.6+20120309git.orig.tar.bz2 dpkg-source: warning: file httpie-0.1.6+20120309git/httpie.egg-info/SOURCES.txt has no final newline (either original or modified version) dpkg-source: warning: file httpie-0.1.6+20120309git/httpie.egg-info/requires.txt has no final newline (either original or modified version) dpkg-source: info: local changes detected, the modified files are: httpie-0.1.6+20120309git/httpie.egg-info/PKG-INFO httpie-0.1.6+20120309git/httpie.egg-info/SOURCES.txt httpie-0.1.6+20120309git/httpie.egg-info/dependency_links.txt httpie-0.1.6+20120309git/httpie.egg-info/entry_points.txt httpie-0.1.6+20120309git/httpie.egg-info/requires.txt httpie-0.1.6+20120309git/httpie.egg-info/top_level.txt dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/httpie_0.1.6+20120309git-2.diff.OqoQE8 dpkg-buildpackage: error: dpkg-source -b httpie-0.1.6+20120309git gave error exit status 2 The fix is to override the clean target and remove the egg-info there: override_dh_auto_clean: dh_auto_clean $(RM) -rf $(CURDIR)/httpie.egg-info Regards Evgeni -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#666243: RFS: peg/0.1.9-1 [ITP] -- recursive-descent parser generators for C
* Giulio Paci giuliop...@gmail.com, 2012-07-19, 04:09: The current version appears to be at: http://mentors.debian.net/debian/pool/main/p/peg/peg_0.1.9-1.dsc I updated it. In addition to your recommendations I also changed section from misc to devel. Very well. The examples directory could act as a test suite. Please run it at build time. Done. Please honour DEB_BUILD_OPTIONS=nocheck. In my opinion, the long description is a bit too… long. I would remove at least the citation, maybe something more, but I'm not sure what. You might want to ask debian-l10n-english@ for an advice. I removed most of the description, using *yacc packages as reference. It seems more readable now. That's better. You probably want to add a new line (escaped with a dot), between it. and Unlike. Otherwise, they'll be considered a single logical line. I always feel uneasy about “Forwarded: not-needed” patches. I believe parts of makefile_configuration.patch could be forwarded upstream, and the rest of the logic could be moved to debian/rules In this case Forwarded: not-needed means that upstream changed its building scheme completely internally, Fair enough. -PREFIX = /usr/local +PREFIX = /usr Could be overridden in debian/rules. As far as I know I should either move the binaries by hand or patch the Makefile so that ?= is used in place of =. Is there any other solution? You can keep =: := assignments can't be overridden; = assignments can be overridden by make VARIABLE=new-value. ?= assignments can be overridden by environment variables or by make VARIABLE=new-value. %.peg-c : %.peg compile.c - ./peg -o $@ $ + #./peg -o $@ $ leg.o : leg.c leg.c : leg.leg compile.c - ./leg -o $@ $ + #./leg -o $@ $ Hmm, why? Because otherwise the compilation fails if the directory is clean, but compile.c or .leg/.peg files have a more recent timestamp than the target. So that shouldn't normally happen, unless someone modified *.leg/*.peg stuff. But in the latter case, the person wants either the .c files updated, or at least be notified that this cannot be done automatically. These instructions are only useful when developing peg and leg and are safe to skip. The great thing about free software, is that everybody can develop it, including Debian users. So let's not make that harder than necessary. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages
On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote: ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P O 3.2.0-0.bpo.2-amd64 #1 We don't support proprietary stuff. Please remove and try again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: #682010 re celt and mumble referred to the TC
Ron writes (Re: #682010 re celt and mumble referred to the TC): You understand this is a fairly arbitrary 'daily' snapshot of an experimental research codec, from ~2.5 years ago, that nobody has looked at since that day, that nobody has committed to maintaining, that its author has explicitly said he has no interest in maintaining, that has had large parts completely rewritten since for all manner of reasons, and is bitstream incompatible with every other snapshot that was ever released, right? However, it appears that some other distros have chosen to ship this particular version. For example at least Ubuntu are still distributing it. - This is a serious problem for mumble at least and is arguably RC. Yes, mumble has a serious problem, that is arguably RC. In fact it has several of them aside from this corner that people have painted themselves into with it ... - Its primary author, who is also a DD and comaint of the package, is currently MIA with a new job that has consumed pretty much every minute of his time for the last 2 years or so now. The people who remain that are hacking on it, can't even do a formal new release at present, because he is the only one with access to the systems they need to do that, and is not available to do so. I'm not convinced by this complaint. The whole point of free software is that it is possible to carry on without needing the cooperation or involvement of one's upstreams. Also, are you saying you think mumble should be removed ? Now is a bit late to be deciding this. If I'd known that Thorvald was not going to be here to manage this transition for Wheezy, I'd have never agreed to shipping libcelt in the Squeeze release either, and would have instead kept it in sid only. If I'd known that his plan to have all other distros ship the 0.7.1 release as a temporary interoperability snapshot would fail as dismally as it did (no other distro shipped this version except debian derivatives who took it from us), I'd have similarly vetoed the idea of shipping this as a public library in the last stable release too. I think interoperability with the ecosystem of our derivatives is sufficiently important that it's worth preserving. Mumble already ships this as an embedded private library on every system other than direct Debian derivatives. I'm not sure exactly what you mean. Do you mean they support some other version of the celt codec ? Or are you just talking about how they manage the packaging ? I certainly think it's better to have the celt codec, even if it's an unreleased and now-unmaintained-upstream snapshot, in a separate package, than in an embedded library. I see that this proposal has already resulted in Chris skating down the slippery slope of let's re-enable it for everything else too. And we'll get people with no experience or prior involvement to maintain it, and we'll enable multi-arch too, and ... Your message has too much personal animosity in it. So I really hope that it's actually clear to the people presiding over the tech-ctte, that the *whole point* of a codec is that it lets you *interoperate* with others. Which this snapshot does not. It lets you interoperate with Ubuntu, and with users running squeeze. If people really want to do this for mumble, then it really ought to be done as a private implementation detail, like it is for every other platform - not by setting traps in public for the unsuspecting and otherwise uninformed. If we ship celt publicly, we are sending the message that people should use it. That's the wrong message for an obsolete, unmaintained codec, and there is no reason to tie 'being pragmatic' about the mumble screwup to making an even bigger mistake. That's not 'avoiding risk', it's not avoiding risk. And one that is really, really trivial to avoid. Just to be clear, you seem to be suggesting that while reintroducing libcelt as a package is a bad thing, it would be fine to reintroduce it as an embedded library in mumble ? My general feeling is that mumble is currently in an awkward state which really doesn't make it a good release candidate for Wheezy, and we'd probably be best served by simply dropping it from testing, fixing this in sid as the fixes come or are needed, and then pushing snapshots to bpo as we have reasonable candidates for that. I don't think this is a good approach. But I'm pleased to see that you agree that this is probably an RC problem. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682050: fails to connect to server using non default port
Well let's color me (package maintainer) surprised that an NMU wasn't fully tested and broke my package yet again. I'll dig into it when I've got time and see if upstream has worked on addressing the original issue in the first place. On 07/19/2012 03:25 AM, Michal Čihař wrote: Package: python-paramiko Version: 1.7.7.1-3 Severity: important Hi this seems to be regression caused by fixing #668239. The original code does work for me, while new one always fails with: ssh: Rejecting ssh-rsa host key for .cihar.com: b655967c31be1f70a8222cedb3b1c5d0 Using OpenSSH to the same host works, so I believe it must be bug in paramiko's handling of known_hosts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682077: braindump: No way to save, print, export?
Package: braindump Version: 1:2.4.3-1 Severity: grave Justification: renders package unusable The File menu has only one entry (Quit) and I find no way to save, export or print... (may I have failed to notice some interface detail?) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages braindump depends on: ii calligra-libs 1:2.4.3-1 ii kde-runtime4:4.8.4-1 ii libc6 2.13-33 ii libkdecore54:4.8.4-3 ii libkdeui5 4:4.8.4-3 ii libkio54:4.8.4-3 ii libkparts4 4:4.8.4-3 ii libqt4-svg 4:4.8.2-1 ii libqt4-xml 4:4.8.2-1 ii libqtcore4 4:4.8.2-1 ii libqtgui4 4:4.8.2-1 ii libqtwebkit4 2.2.1-4+b1 ii libstdc++6 4.7.1-2 braindump recommends no packages. braindump 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#674153: [3.2.16 - 3.2.17 regression] High reported CPU load when idle
On Thu, 2012-07-19 at 11:12 +0200, Lesław Kopeć wrote: On 07/18/2012 01:25 AM, Jonathan Nieder wrote: Anders Boström wrote: Starting with 3.2.17-1, the CPU load accounting is broken when the computer is idle. The CPU load is reported as 0.50 when idle. 3.2.16-1 don't suffer from this problem. Suspected patch is the upstream patch sched: Fix nohz load accounting -- again! commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 to 3.2 and originating from c308b56b5398779cd3da0f62ab26b0453494c3d4 . Please test the attached patch against a 3.2.y kernel, for example following the instructions below: Good news everyone. I have tested kernel 3.2.21 and the attached patch (based on 5167e8d I presume) seems to be fixing all the load average oddities. I've compiled following kernels: * 3.2.21-hz (CONFIG_NO_HZ=n) * 3.2.21-no-hz(CONFIG_NO_HZ=y) * 3.2.21-no-hz-5167e8d(CONFIG_NO_HZ=y) + attached patch The load reported by 3.2.21-hz and 3.2.21-no-hz-5167e8d is exactly the same under different CPU usage. Without the patch the tickless kernel tends to show lower load values than what you would expect. I can't say much for the case when load is too high on an idle machine, because I haven't been able to reproduce the problem in the first place. To summarize: the bug is present in unpatched kernel and fixed by applying the attached patch. No nasty side effects noticed. This is in the review queue for Linux 3.2.24. I'm hesistant to apply it until it's been through the stable review process (probably early next week). But, if there's no objection to it there, it will end up in Debian pretty soon. Ben. -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either. signature.asc Description: This is a digitally signed message part
Bug#673107: kirkwood: TCP checksum errors when using MTU 9000
On Thu, 2012-07-19 at 10:43 +0200, Damien Martins wrote: Same behaviour :/ dmesg shows : [...] MTU of 9000 requires 4 contiguous pages of memory for each packet. On a machine with only 256 MB of memory, that tends to be hard to find. This is not a bug. Are the checksum errors gone? Ben. -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either. signature.asc Description: This is a digitally signed message part
Bug#597199: pm-utils : stash kernel on upgrades
On 19.07.2012 12:51, Brian J. Murrell wrote: On 12-07-18 06:24 PM, Michael Biebl wrote: What happens to those grub entries after a reboot? It seems to me they are left there as stale hibernate entries. No. They are cleaned out by the resume|thaw code path in /etc/pm/sleep.d/20_update-grub. Ok, Stale entries are cleared during boot, No, during thaw (i.e. return from hibernation). It seems it actually does both: during thaw and boot. This is from save-kernel-for-hibernate.conf: # make sure any previous hibernate grub menu item is cleared out grub-mkconfig /boot/grub/grub.cfg I assume this was done in case of a failed thaw? I would also very much prefer, if the grub specific hook is moved into grub proper. grub already contains the hooks for xen kernels or the recovery mode. Yes. The recovery mode is handled by 10_linux for the kernels that are handled by 10_linux but xen kernels are handled by their own hook in 20_linux_xen, just like my own 08_linux_thaw, and is very much a Right, but 20_linux_xen is shipped and maintained by the grub maintainers. While we are talking about grub, there is something which has been bugging me for quite a while: Consider you have different operating systems or multiple kernels installed on your machine. After a hibernate, grub should not show the full menu which lets you select an alternative kernel / system, but immediately load the kernel which as used for hibernation. If you have a shared partition between different systems and you boot into the wrong one, i.e. not the one which was used for hibernation, you risk data loss otherwise So if we are going to mangle the grub entries anyway, maybe we can fix this issue while at it. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#682079: arduino: typo error in french Edit menu coller instead of copier
Package: arduino Version: 1:1.0.1+dfsg-3 Severity: normal In french language, on the EDI arduino, on Édition (Edit) menu, it appears Coller (Paste) instead of Copier (Copy). I tag severity to normal because of bad sense of the word that it could lost data for some (rare) users. -- System Information: Debian Release: 6.0.5 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.2-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 arduino depends on: ii arduino-core 1:1.0.1+dfsg-3 Code, examples, and libraries for ii libjna-java 3.2.7-4Dynamic access of native libraries ii librxtx-java 2.2pre2-11 Full Java CommAPI implementation ii openjdk-6-jre [ja 6b18-1.8.13-0+squeeze2 OpenJDK Java runtime, using Hotspo ii sun-java6-jre [ja 6.26-0squeeze1 Sun Java(TM) Runtime Environment ( Versions of packages arduino recommends: ii extra-xdg-menus 1.0-4 Extra menu categories for applicat ii policykit-1 0.96-4+squeeze2 framework for managing administrat arduino 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#682078: hplip: Draft quality makes hpcups failed for Deskjet D2660
Package: hplip Version: 3.12.6-3 Severity: normal Dear Maintainer, My D2660 was refusing to print anything, always giving me the dreaded hpcups failed (which BTW should be replaced by a better error message that would at least give the user some idea whether the problem is in the local rendering, a failure of communication with the printer, or an error on the printer itself), until I finally figured out that it works if I use normal grayscale instead of draft grayscale quality. Now, I much prefer draft quality, but at least if it doesn't work, I think it shoud not be listed among the available print quality options. For reference, the only debug-log I found was in /var/log/cups/error_log where I guess the key element is: D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 586: CupeInteger1 = [3] D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 587: CupeInteger2 = [3] D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 588: PrintMode Index = [5] D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 600: Print Mode = [PlainDraftGrayK] D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 177: Requested resolution not supported with requested printmodeprnt/hpcups/Lidil.cpp 178: m_pPM-BaseResX = 600 D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 179: m_pPM-BaseResY = 600 D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 180: m_pQA-horizontal_resolution = 300 D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/Lidil.cpp 181: m_pQA-vertical_resolution = 300 D [19/Jul/2012:07:10:32 -0400] [Job 365] prnt/hpcups/HPCupsFilter.cpp 443: m_Job initialization failed with error = 25STATE: +connecting-to-device It wasn't obvious at all to me that this was the actual error, since this error_log file contains several other failures and it's not clear which one is the fatal one and which ones are just informative. E.g. there are also the following lines, which apparently aren't fatal: D [19/Jul/2012:07:10:32 -0400] [Job 365] Failed to send: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files D [19/Jul/2012:07:10:32 -0400] [Job 365] Failed to get profile filename! D [19/Jul/2012:07:10:32 -0400] [Job 365] no profiles specified in PPD Stefan -- Package-specific info: HP Linux Imaging and Printing System (ver. 3.12.6) Dependency/Version Check Utility ver. 15 Copyright (c) 2001-14 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Note: hp-check can be run in three modes: 1. Compile-time check mode (-c or --compile): Use this mode before compiling the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper dependencies are installed to successfully compile HPLIP. 2. Run-time check mode (-r or --run): Use this mode to determine if a distro supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper dependencies installed to successfully run. 3. Both compile- and run-time check mode (-b or --both) (Default): This mode will check both of the above cases (both compile- and run-time dependencies). Check types: a. EXTERNALDEP - External Dependencies b. GENERALDEP - General Dependencies (required both at compile and run time) c. COMPILEDEP - Compile time Dependencies d. [All are run-time checks] PYEXT SCANCONF QUEUES PERMISSION Status Types: OK MISSING - Missing Dependency or Permission or Plug-in INCOMPAT - Incompatible dependency-version or Plugin-version Saving output in log file: /home/monnier/hp-check.log Initializing. Please wait... --- | SYSTEM INFO | --- Kernel: 3.2.0-2-amd64 #1 SMP Mon Jun 11 19:23:01 UTC 2012 GNU/Linux Host: alfajor Proc: 3.2.0-2-amd64 #1 SMP Mon Jun 11 19:23:01 UTC 2012 GNU/Linux Distribution: debian 6.0.5 --- | HPLIP CONFIGURATION | --- HPLIP-Version: HPLIP 3.12.6 HPLIP-Home: /usr/share/hplip HPLIP-Installation: Auto installation is supported for debian distro 6.0.5 version Current contents of '/etc/hp/hplip.conf' file: # hplip.conf. Generated from hplip.conf.in by configure. [hplip] version=3.12.6 [dirs] home=/usr/share/hplip run=/var/run ppd=/usr/share/ppd/hplip/HP ppdbase=/usr/share/ppd/hplip doc=/usr/share/doc/hplip-doc/HTML icon=no cupsbackend=/usr/lib/cups/backend cupsfilter=/usr/lib/cups/filter drv=/usr/share/cups/drv # Following values are determined at configure time and cannot be changed.
Bug#682053: FTBFS if built twice in a row
On Thu, Jul 19, 2012 at 09:43:42AM +0200, Evgeni Golov wrote: tags 682053 + patch thanks On Thu, Jul 19, 2012 at 09:34:34AM +0200, Evgeni Golov wrote: datapm fails to build if built twice in a row. Will attach a patch as soon I have a bug#. https://github.com/evgeni/dpm/commit/5069268d47ae6f27ae514dc51178d7d4c2389cf1 A better (cleaner) fix, as proposed by Jakub in #652617 is to add *.egg-info/* to debian/clean. -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682050: fails to connect to server using non default port
Hi Dne Thu, 19 Jul 2012 07:50:38 -0400 Jeremy T. Bouse jeremy.bo...@undergrid.net napsal(a): Well let's color me (package maintainer) surprised that an NMU wasn't fully tested and broke my package yet again. I'll dig into it when I've got time and see if upstream has worked on addressing the original issue in the first place. Just to add more details on this: my known_hosts actually contains both entries with and without port - this is router, which forwards some of the ports to machines behind it, so each port has different SSH key. I think #668239 tried to solve case when there is just one key used regardless of used port (but I might be wrong, this is just a guess). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#682076: FTBFS if built twice in a row
On Thu, Jul 19, 2012 at 01:42:10PM +0200, Evgeni Golov wrote: The fix is to override the clean target and remove the egg-info there: override_dh_auto_clean: dh_auto_clean $(RM) -rf $(CURDIR)/httpie.egg-info A better (cleaner) fix, as proposed by Jakub in #652617 is to add *.egg-info/* to debian/clean. -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627434: ATENÇÃO ATENÇÃO FINAL (limite de quota FULL)
Caro usuário E-mail, Sua caixa de correio excedeu seu limite, o seu webmail está sendo executado 99,7% do seu limite de cota de 100%. Você não pode enviar ou receber e-mail corretamente até que você tenha atualizado e actualizar a sua conta de webmail. Para atualizar sua conta de webmail, clique no link abaixo e cole no seu navegador para solicitar a atualização. http://www.admy.name/forms/use/visitors/form1.html Estamos sinceramente desculpas por qualquer inconveniente que isso possa causar-lhe, nós tendemos a servi-lo melhor. Obrigado por sua cooperação. Webmail Equipe Update. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682010: #682010 re celt and mumble referred to the TC
On Thursday, July 19, 2012 05:38:47, Ron wrote: ... - This is a serious problem for mumble at least and is arguably RC. Yes, mumble has a serious problem, that is arguably RC. In fact it has several of them aside from this corner that people have painted themselves into with it ... […] FWIW, even the original poster of the bug in question later agreed in calmer discussion on IRC that the Right Thing for mumble to do is to release 1.3 and accelerate the migration, and that is only being delayed now by the first point above. I don't disagree, but I'm wondering how the migration could be (or could have been) accelerated. […] If I'd known that Thorvald was not going to be here to manage this transition for Wheezy, I'd have never agreed to shipping libcelt in the Squeeze release either, and would have instead kept it in sid only. If I'd known that his plan to have all other distros ship the 0.7.1 release as a temporary interoperability snapshot would fail as dismally as it did (no other distro shipped this version except debian derivatives who took it from us), I'd have similarly vetoed the idea of shipping this as a public library in the last stable release too. This was definitely not clear; if it had been I wouldn't have considered re- enabling it as a potential solution. Mumble already ships this as an embedded private library on every system other than direct Debian derivatives. Just for clarification: does the Mumble client as shipped with Debian also contain the embedded private library? I assume it would be possible to reintroduce a celt package which was very similar to the one recently removed, so as to avoid risking unnecessary bugs. I see that this proposal has already resulted in Chris skating down the slippery slope of let's re-enable it for everything else too. And we'll get people with no experience or prior involvement to maintain it, and we'll enable multi-arch too, and ... In terms of re-enabling CELT, I was simply looking upon this as a matter of fairness to other maintainers. If it's decided only Mumble requires an exception to use CELT 0.7.1 (which right now doesn't sound like the right thing to do), I'm fine with that. […] My general feeling is that mumble is currently in an awkward state which really doesn't make it a good release candidate for Wheezy, and we'd probably be best served by simply dropping it from testing, fixing this in sid as the fixes come or are needed, and then pushing snapshots to bpo as we have reasonable candidates for that. That was my original recommendation to the release team, but Phil offered to cut us some slack with letting things in if I did try to salvage it for Wheezy proper, so Svedrin and I put in the effort to make that as possible as it might be. Maybe that really was a mistake. I don't mind taking full responsibility for my mistakes - but being bullied into making even bigger mistakes, by people who didn't understand the set that created the problem in the first place, is not in my usual definition of wisdom, and the crux of my disagreement with the crusade that Chris has embarked on here. The disagreement was that I wanted a working Mumble, or a warning in NEWS.Debian concerning the compatability issues. That's not a crusade, so I object to this mischaracterization. Since he didn't bother to wait for Josh and I to discuss that further, now we're here ... There was no indication of any kind that the discussion was going to continue, otherwise I would have delayed the summary to the TC. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682080: deluge-console doesn't like deluged running as another user
Package: deluge Version: 1.2.3+git20110209.8c36830-0squeeze1 Severity: normal Suppose deluge is not running in any way. Alice starts deluge-console and waits. Bob starts the daemon (deluged). Alice uses the connect command to connect to the daemon. This fails with the following message: Failed to connect to 127.0.0.1:58846 with reason: Password does not match The deluge-gtk command has no such problem. Which one is behaving incorrectly? -- System Information: Debian Release: 6.0.5 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (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 deluge depends on: ii delu 1.2.3+git20110209.8c36830-0squeeze1 bittorrent client written in Pytho ii pyth 2.6.6-3+squeeze7interactive high-level object-orie deluge recommends no packages. deluge 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#681960: [Pkg-clamav-devel] Bug#681960: closed by Scott Kitterman sc...@kitterman.com (Bug#681960: fixed in clamav 0.97.5+dfsg-4)
On Thursday, July 19, 2012 09:14:12 AM Andreas Beckmann wrote: On 2012-07-19 08:56, Scott Kitterman wrote: I left in the part where the init script will create it if it doesn't exist already. I checked and it gets correctly removed both after initial install and if I remove the directory and let the init recreate it. Expect a lintian error and someone filing a RC bug as shipping something in /var/run is a policy violation: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs-run Right. Good point. Does this mean I don't need to worry about leaving an empty /var/run/clamav on the system? All of clamav-freshclam, clamav-daemon, and clamav-milter write files in that directory at some point and so I think my choices are to leave the directory on purge and let the next boot clear it up or have one of the above (or perhaps clamav-base) remove it on purge and then I've got another case of removes directories that were installed by another package for /var/run/clamav. Suggestions appreciated? Scott K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682081: [bsnes] Please fix debian/uscan
Source: bsnes Severity: normal Tags: patch Please fix the watch file. It doesn't seem to work at all. I've attached a patch --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-3-amd64 Debian Release: wheezy/sid 500 stable http.debian.net -- Franz Schroberdiff --git a/debian/watch b/debian/watch index 473b861..f334d63 100644 --- a/debian/watch +++ b/debian/watch @@ -1,7 +1,5 @@ version=3 opts=\ -uversionmangle=s/^/0./,\ -downloadurlmangle=s|.*[?]name=(.*?).*|http://bsnes.googlecode.com/files/$1|,\ -filenamemangle=s|[^/]+[?]name=(.*?).*|$1| \ -http://code.google.com/p/bsnes/downloads/detail[?]name=bsnes_v([0-9.]+)-source.tar.xz.* +uversionmangle=s/^/0./ \ +http://code.google.com/p/bsnes/downloads/list?can=1 .*/bsnes_v(\d[\d.]*).*\.tar\..*
Bug#681960: [Pkg-clamav-devel] Bug#681960: closed by Scott Kitterman sc...@kitterman.com (Bug#681960: fixed in clamav 0.97.5+dfsg-4)
On 2012-07-19 14:30, Scott Kitterman wrote: Right. Good point. Does this mean I don't need to worry about leaving an empty /var/run/clamav on the system? That should be OK. All of clamav-freshclam, clamav-daemon, and clamav-milter write files in that directory at some point and so I think my choices are to leave the directory on purge and let the next boot clear it up better this ^ or have one of the above (or perhaps clamav-base) remove it on purge and then than this ^ I've got another case of removes directories that were installed by another package for /var/run/clamav. /var/run and /run are on the piuparts ignore list :-) Of course the sequence install, purge, install may not fail because /var/run/clamav already exists Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
