Bug#764380: A closer look
Hi Stephan and Stuart, On Mon, Oct 13, 2014 at 05:07:43PM +0200, Stephan Sürken wrote: > Hi Stuart, > > thanks for pointing to the commit. > > I had a closer look; it's this compat include > > --- > try: > from StringIO import StringIO > BytesIO = StringIO > except ImportError: > from io import BytesIO, StringIO > --- > > that previously made it work. > > Using io.open() implicitly makes the "split_gpg_and_payload" produce > unicode strings. Then finally code like this > > --- > io.BytesIO().write(b"\n".join([u"unicode string"])) > --- > > is run (and fails). > > Fwiw, for python3 "split_gpg_and_payload" implicitly produces 'bytes', > and everything works fine. > > Not really sure though what a good fix could be ;). Thanks for the report and investigation. Unicode handling in deb822 has been the bane of my existence, and this is no exception. I have a proposed fix for this that involves trying to figure out the encoding from the input object's 'encoding' property, or failing that, the 'encoding' kwarg, and encoding each element of the sequence. Will send that to the list (or maybe just upload, since it's fairly simple and this is pretty broken) hopefully tomorrow. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760805: dgit depends on "curl | wget" but actually needs curl
Package: dgit Version: 0.22 Severity: normal Hello, dgit declares a dependency on "curl | wget", but then proceeds to call curl. I couldn't find any evidence of trying and failing to call wget. (Perhaps an earlier version did, but a cursory look at 'git blame' did not reveal that.) Probably it should just remove the " | wget", but perhaps it would be more appropriate to use wget if curl is not available. $ dgit clone apt canonical suite name for unstable is sid starting new git history downloading http://ftp.debian.org/debian//pool/main/a/apt/apt_1.0.7.dsc... last upload to archive has NO git hash Can't exec "curl": No such file or directory at /usr/bin/dgit line 405. dgit: failed command: curl -f -o ./apt_1.0.7.tar.xz -- 'http://ftp.debian.org/debian//pool/main/a/apt/apt_1.0.7.tar.xz' dgit: failed to fork/exec: No such file or directory (System information taken after I installed curl in order to dgit clone dgit...) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dgit depends on: ii curl 7.37.1-1 ii devscripts 2.14.6 ii dpkg-dev 1.17.13 ii dput-ng [dput] 1.7 ii git [git-core] 1:2.1.0-1 ii libdpkg-perl 1.17.13 ii libwww-perl6.08-1 ii perl [libdigest-sha-perl] 5.20.0-6 ii realpath 8.23-2 ii wget 1.15-1+b1 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.6p1-7 Versions of packages dgit suggests: pn sbuild -- 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#695932: deb822: flawed handling of signed data
On Wed, Aug 27, 2014 at 01:36:33AM +0200, Ansgar Burchardt wrote: > Control: tag -1 - moreinfo unreproducible > > John Wright writes: > > On Fri, Dec 14, 2012 at 02:31:03PM +, Ansgar Burchardt wrote: > >> Package: python-debian > >> Version: 0.1.21+nmu2 > >> Severity: important > >> > >> debian.deb822 does not handle signed data properly and can be tricked into > >> processing unsigned data while thinking the data is signed. > >> > >> I have attached an example program and *.dsc demonstrating the problem: it > >> will > >> output "gnupg", but the Source field in the signed part of the file > >> actually > >> says "dpkg". > >> > >> See also #695855. > > > > Thanks for the report. Unfortunately (or fortunately, depending on your > > point of view), I cannot reproduce this, either with 0.1.22 or > > 0.1.21+nmu2. (Because the keyring has also changed, I had to replace > > the signed portion with a different signed .dsc for dpkg in order for > > i.valid() to return True, but the end result was that d['Source'] is > > 'dpkg' and not 'gnupg' as in the report.) > > There are subtle changes to the signed part that are easy to miss. I've > attached an updated example .dsc (which is signed with a key still in > the keyring). Well, this time it works as you say. I must have dropped something important when I manually updated the test file before... Thanks! -- John Wright signature.asc Description: Digital signature
Bug#642020: python-debian: ArFile (via DebFile) errors when given only a fileobj
Sorry for the very delayed response. I'm trying to clean up our outstanding bug list... I'm not convinced that sharing the file is the correct thing to do - it introduces thread-unsafe-ness between DebFile/ArFile and its dependent objects that isn't obvious up front. In addition, the existing behavior or re-opening the file by name is bad for another reason: it leaks open files. I think a better solution is probably something like: - If the input file is a "real" file, use mmap to get a view of the object for members. - Otherwise, we should probably iterate over the entire input object to generate our own file-like view of it, which itself supports an interface similar to mmap, and use that for member objects. -- John Wright signature.asc Description: Digital signature
Bug#695932: deb822: flawed handling of signed data
package python-debian tags 695932 moreinfo unreproducible thanks On Fri, Dec 14, 2012 at 02:31:03PM +, Ansgar Burchardt wrote: > Package: python-debian > Version: 0.1.21+nmu2 > Severity: important > > debian.deb822 does not handle signed data properly and can be tricked into > processing unsigned data while thinking the data is signed. > > I have attached an example program and *.dsc demonstrating the problem: it > will > output "gnupg", but the Source field in the signed part of the file actually > says "dpkg". > > See also #695855. Thanks for the report. Unfortunately (or fortunately, depending on your point of view), I cannot reproduce this, either with 0.1.22 or 0.1.21+nmu2. (Because the keyring has also changed, I had to replace the signed portion with a different signed .dsc for dpkg in order for i.valid() to return True, but the end result was that d['Source'] is 'dpkg' and not 'gnupg' as in the report.) I'm tagging the bug unreproducible, but please respond if you can still reproduce this and we'll try to figure out under what circumstances this can actually happen. -- John Wright signature.asc Description: Digital signature
Bug#604093: Bug #604093: python-debian: iter_paragraphs: be more robust against RFC822 comments in unicoded files -- swallows the trailer
Hi Stuart (and pkg-python-debian-maint): On Tue, Jul 29, 2014 at 11:31:31PM +1000, Stuart Prescott wrote: > > > The only place where comments are defined in deb822 files that I can find > > > is in policy §5.1 and they are only defined for debian/control files and > > > comments are started by a # at the start of the line. > > > > if I get it right, I either saw (or found somewhere) a confirmation that > > deb822 is based on (not just inspired by) rfc822, and that is why I was > > expecting comments as defined in rfc822 be respected: > > > > https://www.ietf.org/rfc/rfc0822.txt > > 2.8. ; COMMENTS > > > > A semi-colon, set off some distance to the right of rule > > text, starts a comment that continues to the end of line. This > > is a simple way of including useful notes in parallel with the > > specifications. > > > > > > but if deb822 is not derived from rfc822, I guess my report was a moot ;) > > I can see where you're coming from here. Our definition of the format is > Policy > §5.1, which doesn't actually mention RFC822, defines some things that are not > in that RFC and doesn't include other things that are. I suspect that our > common description of this format as being "pseudo-rfc822" is a (clumsy) > shorthand that at times leads us astray. > > So, I think your bug report exposed some useful inconsistencies in deb822's > handling of filehandles vs other generators and I think we're getting close > to > solving them. Adding handling to the parser for ";"-comments, however, I > think > we should skip. Shall we then tag this bug "wontfix", or close it? I think the main inconsistency point is solved by a recent patch set by Stuart that prefers the native parser unless the Sources or Packages class is explicitly used, and I agree that we should not attempt to implement comment parsing that, while correct RFC822, is not specified in the control format policy. -- John Wright signature.asc Description: Digital signature
Bug#670679: python-debian: deb822 can't parse foreign architecture (package:any) relationships
x27;: 'binutils-dev'})],
> +[rel({'name': 'binutils-multiarch'})],
> +[rel({'name': 'binutils-hppa64'})],
> +[rel({'name': 'binutils-spu'})],
> +[rel({'name': 'binutils-doc'})],
> +[rel({'name': 'binutils-source'})]
> +]
> +}
> self.assertEqual(rel2, pkg2.relations)
> f.close()
>
> --
> 1.9.1
>
> From 9ecd0331f4fa81af4c06cec31cf7e5f66c12ea87 Mon Sep 17 00:00:00 2001
> From: Stuart Prescott
> Date: Sat, 2 Aug 2014 18:12:18 +1000
> Subject: [PATCH 5/6] Allow arch-qualifiers in package relationships
>
> Any relationship is permitted and the relationship is not checked for validity
> just as the rest of the package relation is not checked. The set of qualifiers
> currently accepted in the archive includes :any but dpkg permits even more.
> There are plans to use :native and real arch-names (:i386, :amd64 etc) in the
> future.
> ---
> lib/debian/deb822.py | 2 ++
> tests/test_Packages | 2 +-
> tests/test_Sources | 4 ++--
> tests/test_Sources.iso8859-1 | 4 ++--
> tests/test_deb822.py | 8
> 5 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
> index 07c1dd4..eee7d9c 100644
> --- a/lib/debian/deb822.py
> +++ b/lib/debian/deb822.py
> @@ -883,6 +883,7 @@ class PkgRelation(object):
> # dependency, checking their correctness wrt policy is out of scope
> __dep_RE = re.compile(
> r'^\s*(?P[a-zA-Z0-9.+\-]{2,})'
> +r'(:(?P([a-zA-Z0-9][a-zA-Z0-9-]*)))?'
> r'(\s*\(\s*(?P[>=<]+)\s*'
> r'(?P[0-9a-zA-Z:\-+~.]+)\s*\))?'
> r'(\s*\[(?P[\s!\w\-]+)\])?\s*$')
> @@ -911,6 +912,7 @@ class PkgRelation(object):
> parts = match.groupdict()
> d = {
> 'name': parts['name'],
> +'archqual': parts['archqual'],
> 'version': None,
> 'arch': None
> }
> diff --git a/tests/test_Packages b/tests/test_Packages
> index 6cbee8b..1ace825 100644
> --- a/tests/test_Packages
> +++ b/tests/test_Packages
> @@ -5,7 +5,7 @@ Installed-Size: 4244
> Maintainer: Masayuki Hatta (mhatta)
> Architecture: i386
> Version: 1:4.14-1
> -Depends: file, libc6 (>= 2.7-1), libpaper1, psutils
> +Depends: file:i386, libc6 (>= 2.7-1), libpaper1, psutils
> Recommends: bzip2, lpr | rlpr | cupsys-client, wdiff
> Suggests: emacsen-common, ghostscript, graphicsmagick-imagemagick-compat |
> imagemagick, groff, gv, html2ps, t1-cyrillic, texlive-base-bin
> Filename: pool/main/a/a2ps/a2ps_4.14-1_i386.deb
> diff --git a/tests/test_Sources b/tests/test_Sources
> index f5d53a9..a77aea9 100644
> --- a/tests/test_Sources
> +++ b/tests/test_Sources
> @@ -26,7 +26,7 @@ Version: 2.18.1~cvs20080103-6
> Priority: optional
> Section: devel
> Maintainer: James Troup
> -Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison, flex,
> gettext, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>= 1.4.2-1.1),
> dpatch, file, bzip2, lsb-release
> +Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>=
> 1.4.2-1.1), dpatch, file, bzip2:native, lsb-release
> Architecture: any
> Standards-Version: 3.7.3
> Format: 1.0
> @@ -68,7 +68,7 @@ Version: 0.1.14
> Priority: optional
> Section: devel
> Maintainer: Debian python-debian Maintainers
>
> -Build-Depends: debhelper (>= 5.0.37.2), python, python-setuptools
> +Build-Depends: debhelper (>= 5.0.37.2), python:any, python-setuptools
> Build-Depends-Indep: python-support (>= 0.3)
> Architecture: all
> Standards-Version: 3.8.1
> diff --git a/tests/test_Sources.iso8859-1 b/tests/test_Sources.iso8859-1
> index 253f9d6..af4dcce 100644
> --- a/tests/test_Sources.iso8859-1
> +++ b/tests/test_Sources.iso8859-1
> @@ -26,7 +26,7 @@ Version: 2.18.1~cvs20080103-6
> Priority: optional
> Section: devel
> Maintainer: James Troup
> -Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison, flex,
> gettext, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>= 1.4.2-1.1),
> dpatch, file, bzip2, lsb-release
> +Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>=
> 1.4.2-1.1), dpatch, file, bzip2:native, lsb-release
> Architecture: any
> Standards-Version: 3.7.3
> Format: 1.0
> @@ -68,7 +68,7 @@ Version: 0.1.14
> Priority: optional
> Section: devel
> Maintainer: Debian python-debian Maintainers
>
> -Build-Depends: debhelper (>= 5.0.37.2), python, python-setuptools
> +Build-Depends: debhelper (>= 5.0.37.2), python:any, python-setuptools
> Build-Depends-Indep: python-support (>= 0.3)
> Architecture: all
> Standards-Version: 3.8.1
> diff --git a/tests/test_deb822.py b/tests/test_deb822.py
> index 67606cd..b864609 100755
> --- a/tests/test_deb822.py
> +++ b/tests/test_deb822.py
> @@ -959,7 +959,7 @@ class TestPkgRelations(unittest.TestCase):
> rel1 = {'breaks': [],
> 'conflicts': [],
> 'depends': [
> -[rel({'name': 'file'})],
> +[rel({'name': 'file', 'archqual': 'i386'})],
> [rel({'name': 'libc6', 'version': ('>=', '2.7-1')})],
> [rel({'name': 'libpaper1'})],
> [rel({'name': 'psutils'})]
> @@ -1073,15 +1073,15 @@ class TestPkgRelations(unittest.TestCase):
> [rel({'name': 'dpkg-dev', 'version': ('>=',
> '1.13.9')})],
> [rel({'name': 'autoconf', 'version': ('>=',
> '2.13')})],
> [rel({'name': 'bash'})],
> -[rel({'name': 'bison'})],
> +[rel({'name': 'bison', 'archqual': 'amd64'})],
> [rel({'name': 'flex'})],
> -[rel({'name': 'gettext'})],
> +[rel({'name': 'gettext', 'archqual': 'any'})],
> [rel({'name': 'texinfo'})],
> [rel({'arch': [(True, 'hppa')], 'name':
> 'expect-tcl8.3', 'version': ('>=', '5.32.2')})],
> [rel({'name': 'dejagnu', 'version': ('>=',
> '1.4.2-1.1'), 'arch': None})],
> [rel({'name': 'dpatch'})],
> [rel({'name': 'file'})],
> -[rel({'name': 'bzip2'})],
> +[rel({'name': 'bzip2', 'archqual': 'native'})],
> [rel({'name': 'lsb-release'})]
> ],
> 'build-depends-indep': [],
> --
> 1.9.1
>
> From 844112873929fa6ac0ca8e20a4b38474482e9a80 Mon Sep 17 00:00:00 2001
> From: Stuart Prescott
> Date: Sat, 2 Aug 2014 18:35:52 +1000
> Subject: [PATCH 6/6] Add support for build-profiles
>
> Parse the syntax, creating a list of profiles and whether
> they are positive or negative specifications in the same style as the
> architecture
> restriction list.
>
> The syntactic correctness of the profile name is not enforced.
>
> https://wiki.debian.org/BuildProfileSpec
> ---
> lib/debian/deb822.py | 10 --
> tests/test_Sources | 2 +-
> tests/test_Sources.iso8859-1 | 2 +-
> tests/test_deb822.py | 9 +++--
> 4 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
> index eee7d9c..0b12d3d 100644
> --- a/lib/debian/deb822.py
> +++ b/lib/debian/deb822.py
> @@ -886,7 +886,8 @@ class PkgRelation(object):
> r'(:(?P([a-zA-Z0-9][a-zA-Z0-9-]*)))?'
> r'(\s*\(\s*(?P[>=<]+)\s*'
> r'(?P[0-9a-zA-Z:\-+~.]+)\s*\))?'
> -r'(\s*\[(?P[\s!\w\-]+)\])?\s*$')
> +r'(\s*\[(?P[\s!\w\-]+)\])?\s*'
> +r'(<(?P.+)>)?\s*$')
Optional: Put the ) on the next line so adding more bits doesn't require
changing multiple lines?
> __comma_sep_RE = re.compile(r'\s*,\s*')
> __pipe_sep_RE = re.compile(r'\s*\|\s*')
> __blank_sep_RE = re.compile(r'\s*')
> @@ -906,6 +907,8 @@ class PkgRelation(object):
> archs.append((True, arch))
> return archs
>
> +parse_profiles = parse_archs
> +
> def parse_rel(raw):
> match = cls.__dep_RE.match(raw)
> if match:
> @@ -914,12 +917,15 @@ class PkgRelation(object):
> 'name': parts['name'],
> 'archqual': parts['archqual'],
> 'version': None,
> -'arch': None
> +'arch': None,
> +'restrictions': None,
> }
> if not (parts['relop'] is None or parts['version'] is None):
> d['version'] = (parts['relop'], parts['version'])
> if parts['archs']:
> d['arch'] = parse_archs(parts['archs'])
> +if parts['restrictions']:
> +d['restrictions'] =
> parse_profiles(parts['restrictions'].lower())
> return d
> else:
> warnings.warn('cannot parse package' \
> diff --git a/tests/test_Sources b/tests/test_Sources
> index a77aea9..1ffab0d 100644
> --- a/tests/test_Sources
> +++ b/tests/test_Sources
> @@ -26,7 +26,7 @@ Version: 2.18.1~cvs20080103-6
> Priority: optional
> Section: devel
> Maintainer: James Troup
> -Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>=
> 1.4.2-1.1), dpatch, file, bzip2:native, lsb-release
> +Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo , expect-tcl8.3
> (>= 5.32.2) [hppa] , dejagnu (>= 1.4.2-1.1), dpatch, file,
> bzip2:native, lsb-release
> Architecture: any
> Standards-Version: 3.7.3
> Format: 1.0
> diff --git a/tests/test_Sources.iso8859-1 b/tests/test_Sources.iso8859-1
> index af4dcce..948b190 100644
> --- a/tests/test_Sources.iso8859-1
> +++ b/tests/test_Sources.iso8859-1
> @@ -26,7 +26,7 @@ Version: 2.18.1~cvs20080103-6
> Priority: optional
> Section: devel
> Maintainer: James Troup
> -Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo, expect-tcl8.3 (>= 5.32.2) [hppa], dejagnu (>=
> 1.4.2-1.1), dpatch, file, bzip2:native, lsb-release
> +Build-Depends: dpkg-dev (>= 1.13.9), autoconf (>= 2.13), bash, bison:amd64,
> flex, gettext:any, texinfo , expect-tcl8.3
> (>= 5.32.2) [hppa] , dejagnu (>= 1.4.2-1.1), dpatch, file,
> bzip2:native, lsb-release
> Architecture: any
> Standards-Version: 3.7.3
> Format: 1.0
> diff --git a/tests/test_deb822.py b/tests/test_deb822.py
> index b864609..837966b 100755
> --- a/tests/test_deb822.py
> +++ b/tests/test_deb822.py
> @@ -947,6 +947,8 @@ class TestPkgRelations(unittest.TestCase):
> dict_['arch'] = None
> if 'archqual' not in dict_:
> dict_['archqual'] = None
> +if 'restrictions' not in dict_:
> +dict_['restrictions'] = None
> return dict_
>
> def test_packages(self):
> @@ -1076,8 +1078,11 @@ class TestPkgRelations(unittest.TestCase):
> [rel({'name': 'bison', 'archqual': 'amd64'})],
> [rel({'name': 'flex'})],
> [rel({'name': 'gettext', 'archqual': 'any'})],
> -[rel({'name': 'texinfo'})],
> -[rel({'arch': [(True, 'hppa')], 'name':
> 'expect-tcl8.3', 'version': ('>=', '5.32.2')})],
> +[rel({'name': 'texinfo',
> +'restrictions': [(False, 'profile.stage1'),
> (False, 'profile.cross')]})],
> +[rel({'arch': [(True, 'hppa')], 'name':
> 'expect-tcl8.3',
> +'version': ('>=', '5.32.2'),
> +'restrictions': [(False, 'profile.stage1')]})],
> [rel({'name': 'dejagnu', 'version': ('>=',
> '1.4.2-1.1'), 'arch': None})],
> [rel({'name': 'dpatch'})],
> [rel({'name': 'file'})],
> --
> 1.9.1
>
Overall, LGTM, thanks again!
> --
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-python-debian-maint
--
John Wright
signature.asc
Description: Digital signature
Bug#747031: fixed in python-debian 0.1.22
Hi Stuart, On Wed, Jun 11, 2014 at 10:12:21PM +1000, Stuart Prescott wrote: > Hi John, > > >* python_support: Avoid hashlib dependency, using the built-in _sha or > > _sha1 module (depending on Python version) instead. That way we > > don't link in OpenSSL, which has an incompatible license. > > (Closes: 747031) > > We should be careful that this particular change is not backwards compatible > with wheezy's python: > > $ PYTHONPATH=. python -c 'import debian.debian_support; > debian.debian_support.new_sha1()' > Traceback (most recent call last): > File "", line 1, in > File "debian/debian_support.py", line 50, in new_sha1 > "Built-in sha1 implementation not found; cannot use hashlib" > NotImplementedError: Built-in sha1 implementation not found; cannot use > hashlib implementation because it depends on OpenSSL, which may not be linked > with this library due to license incompatibilities > > (the test suite does fail which would alert a backporter) > > Fiddling around with an internal interface like _sha feels quite wrong too. I > think it's likely to bring pain back to us in the future. For what it's worth, I don't particularly like this solution either. I couldn't find a better one (at least not a tecnhical one - see below). > I'm quite unconvinced by the argument that a GPL'd script can't import > hashlib; I think GPLv3 is quite clear that "hashlib" is a Standard Interface > of the Python programming language and that making use of it is fine; the > language is less precise for GPLv2 but I still don't think there's a problem > there. There are plenty of other GPL'd things in Debian that "import hashlib" > and I don't think anyone's interested in working on this. I actually am convinced by the debian-legal argument that the exception doesn't apply for Debian (because Debian distributes both OpenSSL and python-debian), but the alternative to this hacky crap is to modify our own license to allow linking with OpenSSL. Which honestly is probably not too hard since there were only a handful of contributors to python_support.py. > I've taken this particular issue out of the too-hard-basket and put it back > in > several times already... thanks for taking a crack at it. No problem. Feel free to revert the change if it's causing problems. -- John Wright signature.asc Description: Digital signature
Bug#747173: Make dmesg dump configurable
On Mon, May 26, 2014 at 11:02:21AM +0200, Louis Bouchard wrote: > Hello Juerg, John, > > I have applied your patch and pushed a new branch to alioth : > > http://anonscm.debian.org/gitweb/?p=collab-maint/makedumpfile.git;a=shortlog;h=refs/heads/bug-747173-configurable-dmesg > > John, could you please merge it & sponsor the upload ? > > I did a minor edit to your comment : I do think that it is valuable to have > the > dmesg content in a production environment : this avoids having to send > multi-gigabyte of vmcore just to get the backtrace of what caused the kernel > panic to happen. Merged to master, tagged, pushed, and uploaded to Debian. :-) Thanks Louis for packaging, and Juerg for the patch! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747173: Make dmesg dump configurable
Hi Juerg, On Tue, May 20, 2014 at 10:28:24AM +0200, Juerg Haefliger wrote: > John, > > Any thoughts on this? I haven't had time to look at it (sorry) but it seems like a reasonable feature to add. Louis Bouchard has been actively maintaining makedumpfile, and I believe he is working on adding some features to the kdump-tools script. Louis, can you take a look at this? Juerg filed a wishlist bug including a patch: http://bugs.debian.org/747173 -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506861: xz support for python-debian
On Tue, Jan 14, 2014 at 07:58:02PM +0100, Stefano Zacchiroli wrote: > On Tue, Jan 14, 2014 at 11:17:14PM +1100, Stuart Prescott wrote: > > Neil: your simple patch stops debfile from crashing when it sees xz > > compressed packages but doesn't permit debfile to work with these > > files. A patch for this has now existed in the bts for a while now. > > Ack. > > > I've been very much hoping that someone would look over this patch and > > provide some feedback on it and/or merge it. Perhaps, at this stage, > > we should just upload it and deal with any bugs. > > > > Perhaps I've not made it clear enough in the past, but I am quite > > willing to help out with python-debian maintenance. I would, however, > > be happier if there were some code review of contributions. > > Stuart, thanks a lot for both your patch and your willingness to help > with python-debian maintenance. For one thing, I very much welcome your > help and I encourage you to add yourself to the Uploaders field and > proceed with an upload (see below for a review of your xz patch). > > I can't speak for the python-debian team as a whole but, in fact, I > think we've been *lacking* such a team for the past few years. I'm still > on this list and follow it, but I don't expect to be able to be an > active maintainer for python-debian in the near future. The most active > person over the past few years here has probably been John Wright, which > I'm now Cc:-ing explicitly. John, if you have objections to Stuart > adding himself to the Uploaders please say so. Stuart, please feel free to add yourself to Uploaders. I haven't had much time, unfortunately, for Debian in general recently, but I would love to see python-debian continue to work with files from recent Debian versions. I will try be more on top of python-debian reviews, at the least. If you want another pair of eyes on this patch, I can look at it later this week (or weekend), but I trust Zack's judgement. > Separately, and barring objections from John, please ping me on IRC in a > few days and I'll add you to the alioth group so that you can push to > the Git repo. > > And many thanks for not giving up on us! :-) Ditto. -- John Wright signature.asc Description: Digital signature
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line "[ 0.000000] " to dmesg file
On Sun, Oct 20, 2013 at 10:25:31PM -0400, Alex Vanderpol wrote: > Unfortunately I no longer have any of those crash dumps available to > send you anything, I had sent what I had gotten to the kernel > maintainers previously in an attempt to track down the cause of the > crashing, which I don't believe was ever figured out exactly but was > ultimate fixed in a later kernel version. I don't know if they would > still happen to have it on hand or not, though. > > For what it's worth, there never was a vmcore file created any time > I did get a dump, instead I always got two separate files, one which > is the main core dump and one which is supposed to be the dmesg log > dump which unfortunately was never actually able to be dumped (the > issue I filed this bug report about). If the end result is supposed > to be one vmcore file, I suspect the inability of makedumpfile to > dump the kernel dmesg log prohibited it from combining the two files > into one file. It's always two separate files. They are not meant to be combined - the dmesg dump is just intended for convenience (you can just read the file as text instead of opening a dump with crash). > Using the 'log' command from within crash was ultimately useless as > well, as the kernel log wasn't dumped, therefore there wasn't any > log for crash to open. > > This issue was with kernel 3.11-rc4-amd64 in its stock configuration. Not a Debian package? I'm not sure what you mean when you say stock configuration. Do you mean you ran 'make defconfig' to generate the kernel .config? > I hope what information I am able to give you proves to be at least > somewhat useful. I'm not really sure what you saw. :-/ I'll see if I can reproduce anything with linux-image-3.11-1-amd64_3.11.5-1_amd64 when I have some free time (I lost the VM I use for testing this stuff). It's possible there was a short-lived bug in the kernel itself, causing some corrupt representation of its log buffer. > On 2013-10-20 10:29 PM, John Wright wrote: > >Hi Alex, > > > >On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: > >>Package: makedumpfile > >>Version: 1.5.4-1 > >>Severity: grave > >>Justification: renders package unusable > >> > >>Dear Maintainer, > >> > >>There seems to be a serious issue with makedumpfile that causes it to fail > >>to > >>dump the kernel log when collecting crash dump information. Instead, the > >>program continues to run indefinitely, continually appending the line "[ > >>0.00] " to the file as it seems to attempt to dump the log, which, if > >>left > >>alone for any considerable length of time, can rapidly result in a very > >>large, > >>entirely useless dmesg dump file. > >> > >>I have been trying to collect crash dump information for a crash that's > >>triggered whenever Folding@Home's FahCore_a4 attempts to resume an > >>in-progress > >>work unit, however, every crash dump I've collected has had this problem. > >>The > >>main dump file seems to be dumped without a problem (though crash > >>identifies it > >>as a partial dump, possibly due to the kernel log being dumped into a > >>separate > >>file). > >> > >>I hope you can look into this issue and hopefully it can be sorted out soon. > >Sorry for the long delay in my response. This seems like a serious but > >not actually grave issue, since the core dump does actually exist (even > >though you have to interrupt the dmesg extraction). crash identifies > >the dump as a partial dump because we explicitly ignore zero pages and > >userspace pages. Within crash, you should be able to use the 'log' > >command to get the most recent log messages before the crash...assuming > >crash doesn't break in the same way makedumpfile does. > > > >I will try to reproduce this, but I worry the problem might be somewhat > >specific either to your crash or some other part of your configuration. > >Would you feel comfortable making the vmcore available to me? It would > >also help to know the exact kernel version, and access to a dbg package > >if it's not a stock kernel. > > > >Sorry for the issue and thanks for the report! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719943: makedumpfile: fails to dump kernel log, continually appends the line "[ 0.000000] " to dmesg file
Hi Alex, On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote: > Package: makedumpfile > Version: 1.5.4-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > There seems to be a serious issue with makedumpfile that causes it to fail to > dump the kernel log when collecting crash dump information. Instead, the > program continues to run indefinitely, continually appending the line "[ > 0.00] " to the file as it seems to attempt to dump the log, which, if left > alone for any considerable length of time, can rapidly result in a very large, > entirely useless dmesg dump file. > > I have been trying to collect crash dump information for a crash that's > triggered whenever Folding@Home's FahCore_a4 attempts to resume an in-progress > work unit, however, every crash dump I've collected has had this problem. The > main dump file seems to be dumped without a problem (though crash identifies > it > as a partial dump, possibly due to the kernel log being dumped into a separate > file). > > I hope you can look into this issue and hopefully it can be sorted out soon. Sorry for the long delay in my response. This seems like a serious but not actually grave issue, since the core dump does actually exist (even though you have to interrupt the dmesg extraction). crash identifies the dump as a partial dump because we explicitly ignore zero pages and userspace pages. Within crash, you should be able to use the 'log' command to get the most recent log messages before the crash...assuming crash doesn't break in the same way makedumpfile does. I will try to reproduce this, but I worry the problem might be somewhat specific either to your crash or some other part of your configuration. Would you feel comfortable making the vmcore available to me? It would also help to know the exact kernel version, and access to a dbg package if it's not a stock kernel. Sorry for the issue and thanks for the report! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700418: kdump-tools: default debug kernel search path is incorrect
On Thu, Feb 21, 2013 at 09:27:38AM -0500, David Magda wrote: > On 2013-02-12 09:07, David Magda wrote: > > >In /usr/share/doc/kdump-tools/README.Debian the following text appears: > > > >4. Debug Kernel > > You *should* have a debug kernel in order for makedumpfile to process > > the vmcore file. Without a debug kernel, the transfer process is > > reduced to using "makedumpfile -d 1". Options: > > A) If /usr/lib/debug/vmlinux-$(uname -r) exists, kdump-tools will > > use that kernel. > > B) Explicitly set DEBUG_KERNEL in /etc/default/kdump-tools to > > point to your debug kernel. > > C) None of the above. makedumpfile will still work, but your > > dumpfile will be larger and take longer to save to disk. > > > >However all (?) the default -dbg Debian kernel packages put the kernels > >in /usr/lib/debug/boot/: > [...] > >IMHO it would make sense to change (A) so that things worked automagically. > > > >If someone had a truly custom kernel, then tweaking DEBUG_KERNEL per (B) > >would make sense, but the 'standard' Debian tools should work with the > >standard Debian kernels. > > > >The other options would be to remove the boot/ from the debug kernel path. > > Has anyone had a chance to take a look at this and evaluate if it's > a valid concern, or am I just talking crazy? Sorry, I agree the defaults should match the Debian defaults. When kdump-tools was written there was no such Debian default, so we made one up for the custom distro kdump-tools was originally included in. That said...it looks like version 3.2.39-1 of the linux package added some symlinks to /usr/lib/debug. I'm on the fence about changing kdump-tools - in principle it would be nice if the defaults didn't have to refer to symlinks, but I haven't been able to find much time to work on this stuff recently. I welcome a patch. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696386: makedumpfile fails with elf_readall error : more information
On Thu, Dec 20, 2012 at 02:39:09PM +0100, Bouchard Louis wrote: > I have just completed a subsequent test on Ubuntu 13.04 Raring, which > uses the same version of makedumpfile and libelf1. To my surprize, it > DOES work correctly on Ubuntu. > > Could this be related the the build of the library ? Interesting. That's a possibility, but tracking down the specific difference in Ubuntu's and Debian's toolchains is going to be tricky. Does it work in Ubuntu with Debian's kernel, or vice versa? -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670679: python-debian: deb822 can't parse foreign architecture (package:any) relationships
Hi Stefano, On Sat, Apr 28, 2012 at 12:40:45AM +0200, Stefano Rivera wrote: > Hi submit (2012.04.28_00:33:40_+0200) > > This syntax isn't documented in Debian Policy, that I can see. The only > > mention of it I can find is in https://wiki.ubuntu.com/MultiarchHowto > > Err, > https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships > > SR Thanks for the patchset. I've rebased it against our tip, and combined patches 2 and 3 so that tests pass at each commit. Can you take a look at the branch here: http://anonscm.debian.org/gitweb/?p=pkg-python-debian/python-debian.git;a=shortlog;h=refs/heads/jsw/stefanor-multiarch If this looks good to you, I will merge this into our master branch and close the bug. Otherwise, would you mind pushing a new branch? Thanks! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623177: linux-2.6: Please enable CONFIG_CRASH_DUMP on x86 architectures
On Mon, Jun 11, 2012 at 12:55:19AM +0100, Ben Hutchings wrote: > Thanks a lot for the extra information. I'm convinced and I'll enable > this for the next upload. Wonderful, thank you! (And sorry I didn't include that information from the beginning.) -- John Wright signature.asc Description: Digital signature
Bug#623177: linux-2.6: Please enable CONFIG_CRASH_DUMP on x86 architectures
On Sun, Jun 10, 2012 at 03:02:30PM +0100, Ben Hutchings wrote: > On Sun, 2012-06-10 at 00:44 -0700, John Wright wrote: > > On Sat, Jun 02, 2012 at 07:02:11PM +0100, Ben Hutchings wrote: > > > The help text for this option is: > > > > > > "Generate crash dump after being started by kexec. > > > This should be normally only set in special crash dump kernels > > > which are loaded in the main kernel with kexec-tools into > > > a specially reserved region and then later executed after > > > a crash by kdump/kexec. ..." > > > > > > Are you asking us to add a kdump flavour, as some other distributions > > > do? > > > > It's not necessary to have another flavor. Kernels built with this > > option work just fine as regular kernels too (in fact, the ia64 and > > probably some other kernels are already built this way). As I recall, > > as the kernel is currently built, it can be loaded as a crash kernel, > > and kexec'ed successfully upon kernel panic; however, CONFIG_CRASH_DUMP > > is required to enable /proc/vmcore in the newly booted kernel, which > > contains the memory of the crashed kernel. Then, a tool like > > 'makedumpfile' can read the core, stripping out user and zero pages, and > > write a small dump file that can be analyzed with tools like 'crash'. > > The help text for CRASH_DUMP on x86 says: > > Generate crash dump after being started by kexec. > This should be normally only set in special crash dump kernels > ... > > Since this is not the only use for kexec, I don't believe we should The documentation is misleading. It doesn't cause the kernel to generate any dump; it just enables /proc/vmcore *if* the kernel is kexec'ed as a result of the previous kernel panicking. Nothing special (compared to other kernels) happens in a normal (not-triggered-by-panic) kexec of a CONFIG_CRASH_DUMP=y kernel. > enable this in the currently defined flavours (or that it should have > been enabled for ia64). > > As I said, other distributions have a separate kdump flavour, presumably > for this reason. (Adding Troy, who might have more insight on the historic need for a kdump kernel.) The separate kdump flavors started mainly because some architectures weren't relocatable, so it was impossible to use the same image for your normal kernel and your crash kernel. That hasn't been the case for x86, ia64, or ppc for quite some time. Also, the i386_defconfig and x86_64_defconfig files upstream have had CONFIG_CRASH_DUMP=y since 2008: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=5cb04df8d3f03e37a19f2502591a84156be71772 The upstream kdump documentation talks about using the same kernel for kdump as well: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/kdump/kdump.txt#l112 I think adding another flavor just for CONFIG_CRASH_DUMP is really heavy-weight, especially given that upstream has enabled it by default for four years, and it touches so few pieces of code. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625509: python-debian: please port to Py3k
On Wed, Mar 14, 2012 at 05:06:51PM +0100, Stefano Zacchiroli wrote: > On Sun, Jan 22, 2012 at 04:21:41PM -0800, John Wright wrote: > > On Sun, Jan 22, 2012 at 02:37:55PM +, Colin Watson wrote: > > > I would very much appreciate review of this branch. In case it eases > > > review, I've attached the 31-patch series (!) to this mail. I've tried > > > to arrange it roughly in ascending order of complexity. > > > > Wow. I'll be glad to review them, but I'm not sure when I'll have the > > opportunity. I'll try to make time later this week. > > Heya John, > do you think you'll have time to do the review in the near future? > Just a friendly ping because, unfortunately, I haven't yet look in > enough details to Python 3 to be able to do a review myself. I also don't know when I'll have time... I thought I would a couple of months ago, but things aren't getting any less busy. :-( I also need to take some time to familiarize myself with Python 3. > Still, I'd love to see python-debian porting to python 3 in the archive > ... and I'll be happy to test early versions! I'll see how many patches I can review next weekend. Maybe it'll be worth making an upload to experimental for testing beyond our unit tests. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625509: python-debian: please port to Py3k
On Sun, Jan 22, 2012 at 02:37:55PM +, Colin Watson wrote: > On Wed, Jan 18, 2012 at 10:54:28AM +, Colin Watson wrote: > > On Wed, May 04, 2011 at 03:10:29AM +0200, Tshepang Lekhonkhobe wrote: > > > Can you either make this package capable of running for Python 2 and 3, > > > or make separate packages for it, as python-apt does. > > > > I'm working on this here: > > > > > > http://anonscm.debian.org/gitweb/?p=users/cjwatson/python-debian.git;a=shortlog;h=refs/heads/python3 > > > > I will probably end up depending on the six module, which I uploaded to > > unstable yesterday. It's tiny, so I shouldn't expect this to cause much > > of a problem. > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656288 in python3-apt > > is getting in the way a bit, but I suppose worst case I can just skip > > those tests when running under Python 3 for now. > > I believe this port is now complete, in the git branch above. It passes > all tests provided that a version of python3-apt with the most recent > patch in #656288 is available. > > I would very much appreciate review of this branch. In case it eases > review, I've attached the 31-patch series (!) to this mail. I've tried > to arrange it roughly in ascending order of complexity. Wow. I'll be glad to review them, but I'm not sure when I'll have the opportunity. I'll try to make time later this week. Thanks for the effort! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638849: drop debug kernel requirement
On Mon, Aug 22, 2011 at 04:31:44PM +0400, Konstantin Khlebnikov wrote: > Package: kdump-tools > Version: 1.3.7-2 > > Starting from 2.6.24 kernel provides vmcoreinfo right in vmcore, > so makedumpfile can produce filtered dumps without vmlinux or slecial > vmcoreinfo. > > attached patch drops DEBUG_KERNEL from scripts, configs and documentation. > > Also it adds to kdump-config automatical extracting kernel log buffer (dmesg) > from vmcore, > so kdump produce two files in /var/crash dump.XXX and dmesg.XXX with > human-readable log from crashed kernel. Thank you for the patch! I won't have time to review and test it fully until next week. It still might be useful to provide a symlink in the dump directory to where a debug kernel might be expected to live, to make running the crash tool on those dumps a little more straightforward. I'll start thinking about the best way to do that. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631392: Was this uploaded?
On Mon, Jul 18, 2011 at 07:15:57PM -0400, Barry Warsaw wrote: > Hi. Was this change uploaded? I don't see it in 0.1.20 and I don't see any > newer versions. I'd love to merge this change into Ubuntu to knock one more > python-support package off my list. :) Sorry, I've been neglectful. :( Uploading 0.1.21 tonight. -- John Wright signature.asc Description: Digital signature
Bug#631392: Acknowledgement (python-debian: convert to dh_python2?)
On Thu, Jun 23, 2011 at 04:03:33PM +0100, Colin Watson wrote:
> I'm told that ${python:Breaks} is no longer used (cf. python-defaults
> 2.6.6-12 changelog), so feel free to drop that line from my patch.
Thanks, for the patch, Colin. I applied it without the ${python:Breaks}
line.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625672: Patch
Hi Tshepang, On Fri, May 20, 2011 at 02:47:44PM +0200, Tshepang Lekhonkhobe wrote: > > >From e8db1d70d21858bba4cbc0881eff745b4a534715 Mon Sep 17 00:00:00 2001 > From: Tshepang Lekhonkhobe > Date: Wed, 4 May 2011 13:34:20 +0200 > Subject: [PATCH 1/2] test_changelog.py: close open files > > --- > tests/test_changelog.py | 71 ++ > 1 files changed, 52 insertions(+), 19 deletions(-) Thanks for working on this. Sorry it took so long to respond. I have applied your patch. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623470: Configuring kdump-tools fails when there is no crashkernel= in the kernel cmdline
On Wed, Apr 20, 2011 at 05:28:09PM +0300, Sami Liedes wrote: > Package: kdump-tools > Version: 1.3.7-1 > Severity: serious > > Hi, > > kdump-tools fails to configure on my laptop: > > > Setting up kdump-tools (1.3.7-1) ... > Starting kdump-tools: no crashkernel= parameter in the kernel cmdline ... > failed! > invoke-rc.d: initscript kdump-tools, action "start" failed. > dpkg: error processing kdump-tools (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > kdump-tools > > > I don't think the command line I used to boot the kernel should > prevent a package from configuring. The command line: > > > $ cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-2.6.38.3 root=/dev/mapper/rootvg-root ro > Thanks for the bug report. You're right, the package should not fail to configure. I'll modify the init script so that it prints a warning and exits with status 0 in this case. -- John Wright signature.asc Description: Digital signature
Bug#623177: linux-2.6: Please enable CONFIG_CRASH_DUMP on x86 architectures
Source: linux-2.6 Severity: wishlist Tags: patch Now that we ship debug info, missing CONFIG_CRASH_DUMP=y is the only thing preventing users of stock Debian kernels from easily taking crash dumps with makedumpfile/kdump-tools and analyzing them with the crash utility. I have built a kernel with the attached patch (against dists/sid/linux-2.6/debian) to verify that it builds and that it allows makedumpfile to successfuly take a crash dump. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- John Wright >From f3ac73731480704de0c46ada854f88122bed834b Mon Sep 17 00:00:00 2001 From: John Wright Date: Sun, 17 Apr 2011 20:35:17 -0700 Subject: [PATCH] Enable CONFIG_CRASH_DUMP for x86 architectures --- config/kernelarch-x86/config |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/config/kernelarch-x86/config b/config/kernelarch-x86/config index c852cd3..b9993b2 100644 --- a/config/kernelarch-x86/config +++ b/config/kernelarch-x86/config @@ -46,7 +46,7 @@ CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR=y CONFIG_KEXEC=y -# CONFIG_CRASH_DUMP is not set +CONFIG_CRASH_DUMP=y # CONFIG_KEXEC_JUMP is not set CONFIG_RELOCATABLE=y CONFIG_HOTPLUG_CPU=y -- 1.7.4.4
Bug#623011: python-debian: FTBFS: Test failure (missing Build-Depends?)
On Sat, Apr 16, 2011 at 08:47:51AM -0700, Daniel Schepler wrote:
> Source: python-debian
> Version: 0.1.19
> Severity: serious
>
> From my pbuilder build log:
>
> ...
> # run the tests
> cd tests && ./test_deb822.py
> ...
> --
> Ran 39 tests in 0.165s
>
> OK
> cd tests && ./test_debfile.py
> ..
> --
> Ran 10 tests in 0.220s
>
> OK
> cd tests && ./test_debtags.py
> ...
> --
> Ran 3 tests in 0.006s
>
> OK
> cd tests && ./test_changelog.py
> ..
> --
> Ran 14 tests in 0.031s
>
> OK
> cd tests && ./test_debian_support.py
> .E
> ==
> ERROR: testversions (__main__.VersionTests)
> --
> Traceback (most recent call last):
> File "./test_debian_support.py", line 77, in testversions
> ValueError, cls, 'a1:1.8.8-070403-1~priv1')
> File "/usr/lib/python2.6/unittest.py", line 336, in failUnlessRaises
> callableObj(*args, **kwargs)
> File "../lib/debian/debian_support.py", line 170, in __init__
> raise NotImplementedError("apt_pkg not available; install the "
> NotImplementedError: apt_pkg not available; install the python-apt package
>
> ------
> Ran 6 tests in 0.011s
>
> FAILED (errors=1)
> make: *** [build-stamp] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
Crap. Sorry. Will fix this tonight.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619997: python-debian: BaseVersion is not strict enough
tags 619997 + pending thanks On Tue, Mar 29, 2011 at 02:48:00PM +1100, Steve Kowalik wrote: > Package: python-debian > Version: 0.1.17~bzr184~launchpad1 > Severity: normal > Tags: patch > > Hi, > > The BaseVersion class in debian_support contains an re_valid_version > regular expression. It isn't quite strict enough, to quote from Policy > 5.6.12: "if there is no epoch then colons are not allowed.". > > Find attached a patch that corrects that. Thanks for the patch! Committed (just slightly modified): http://git.debian.org/?p=pkg-python-debian/python-debian.git;a=commitdiff;h=667c5f8cec25837a728be4d2919ed3d1fd418683 -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597120: [PATCH] Avoid dumping unparseable data
On Mon, Sep 20, 2010 at 10:37:08AM -0700, Jelmer Vernooij wrote: > Hi John, > > On Sat, 2010-09-18 at 02:15 -0600, John Wright wrote: > > Add an input validation method that is called by the default __setitem__, > > and add some validation at output time for multivalued fields (since > > their input is a mutable list which makes it unsuitable for validation > > at intput time). > "Changes" in the changes file often contains empty lines, and I think we > should keep being able to generate files like that. I haven't actually > tried but from reading your patch it looks like it would also refusing > setting a field with empty lines even if it is the last one? Really? It could contain lines like ' .\n', but never just '\n'... Any tool creating a .changes file with truly empty lines is broken, and I'm pretty sure deb822 would refuse to read any data after the first blank line, anyway, with or without this patch. -- John Wright signature.asc Description: Digital signature
Bug#597249: [PATCH] Allow ':' as the first character of a value
The regular expression that matched keys was too loose, so things like
Foo: : bar
would get parsed as
{'Foo:': 'bar'}
instead of the correct value (which is also returned by both apt_pkg and
the email package),
{'Foo': ': bar'}
Closes: #597249
---
debian/changelog |1 +
lib/debian/deb822.py |8 +---
tests/test_deb822.py |8
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 492b5df..4010029 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
python-debian (0.1.19) UNRELEASED; urgency=low
* Avoid dumping unparseable data. (Closes: #597120)
+ * Allow ':' as the first character of a value. (Closes: #597249)
-- John Wright Sat, 18 Sep 2010 00:47:04 -0600
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index fc87124..47c921d 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -317,9 +317,11 @@ class Deb822(Deb822Dict):
###
def _internal_parser(self, sequence, fields=None):
-single = re.compile("^(?P\S+)\s*:\s*(?P\S.*?)\s*$")
-multi = re.compile("^(?P\S+)\s*:\s*$")
-multidata = re.compile("^\s(?P.+?)\s*$")
+# The key is non-whitespace, non-colon characters before any colon.
+key_part = r"^(?P[^: \t\n\r\f\v]+)\s*:\s*"
+single = re.compile(key_part + r"(?P\S.*?)\s*$")
+multi = re.compile(key_part + r"$")
+multidata = re.compile(r"^\s(?P.+?)\s*$")
wanted_field = lambda f: fields is None or f in fields
diff --git a/tests/test_deb822.py b/tests/test_deb822.py
index 64fd77a..b03b13f 100755
--- a/tests/test_deb822.py
+++ b/tests/test_deb822.py
@@ -753,6 +753,14 @@ Description: python modules to work with Debian-related
data formats
d['Files'] = [{'md5sum': 'deadbeef', 'size': '9605', 'name': 'bad\n'}]
self.assertRaises(ValueError, d.get_as_string, 'files')
+def test_bug597249_colon_as_first_value_character(self):
+"""Colon should be allowed as the first value character. See #597249.
+"""
+
+data = 'Foo: : bar'
+parsed = {'Foo': ': bar'}
+self.assertWellParsed(deb822.Deb822(data), parsed)
+
class TestPkgRelations(unittest.TestCase):
--
1.7.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597120: [PATCH] Avoid dumping unparseable data
Add an input validation method that is called by the default __setitem__,
and add some validation at output time for multivalued fields (since
their input is a mutable list which makes it unsuitable for validation
at intput time).
Closes: #597120
---
debian/changelog |6 ++
lib/debian/deb822.py | 45 ++---
tests/test_deb822.py | 28
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 0292524..492b5df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-debian (0.1.19) UNRELEASED; urgency=low
+
+ * Avoid dumping unparseable data. (Closes: #597120)
+
+ -- John Wright Sat, 18 Sep 2010 00:47:04 -0600
+
python-debian (0.1.18) unstable; urgency=low
* Support installation together with older versions of python-apt.
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index a0cad69..fc87124 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -406,8 +406,9 @@ class Deb822(Deb822Dict):
value = self.get_as_string(key)
if not value or value[0] == '\n':
# Avoid trailing whitespace after "Field:" if it's on its own
-# line or the value is empty
-# XXX Uh, really print value if value == '\n'?
+# line or the value is empty. We don't have to worry about the
+# case where value == '\n', since we ensure that is not the
+# case in __setitem__.
entry = '%s:%s\n' % (key, value)
else:
entry = '%s: %s\n' % (key, value)
@@ -588,6 +589,31 @@ class Deb822(Deb822Dict):
return self.gpg_info
+def validate_input(self, key, value):
+"""Raise ValueError if value is not a valid value for key
+
+Subclasses that do interesting things for different keys may wish to
+override this method.
+"""
+
+# The value cannot end in a newline (if it did, dumping the object
+# would result in multiple stanzas)
+if value.endswith('\n'):
+raise ValueError("value must not end in '\\n'")
+
+# Make sure there are no blank lines (actually, the first one is
+# allowed to be blank, but no others), and each subsequent line starts
+# with whitespace
+for line in value.splitlines()[1:]:
+if not line:
+raise ValueError("value must not have blank lines")
+if not line[0].isspace():
+raise ValueError("each line must start with whitespace")
+
+def __setitem__(self, key, value):
+self.validate_input(key, value)
+Deb822Dict.__setitem__(self, key, value)
+
###
# XXX check what happens if input contains more that one signature
@@ -892,6 +918,16 @@ class _multivalued(Deb822):
for line in filter(None, contents.splitlines()):
updater_method(Deb822Dict(zip(fields, line.split(
+def validate_input(self, key, value):
+if key.lower() in self._multivalued_fields:
+# It's difficult to write a validator for multivalued fields, and
+# basically futile, since we allow mutable lists. In any case,
+# with sanity checking in get_as_string, we shouldn't ever output
+# unparseable data.
+pass
+else:
+Deb822.validate_input(self, key, value)
+
def get_as_string(self, key):
keyl = key.lower()
if keyl in self._multivalued_fields:
@@ -909,13 +945,16 @@ class _multivalued(Deb822):
field_lengths = {}
for item in array:
for x in order:
-raw_value = str(item[x])
+raw_value = unicode(item[x])
try:
length = field_lengths[keyl][x]
except KeyError:
value = raw_value
else:
value = (length - len(raw_value)) * " " + raw_value
+if "\n" in value:
+raise ValueError("'\\n' not allowed in component of "
+ "multivalued field %s" % key)
fd.write(" %s" % value)
fd.write("\n")
return fd.getvalue().rstrip("\n")
diff --git a/tests/test_deb822.py b/tests/test_deb822.py
index 891f4cd..64fd77a 100755
--- a/tests/test_deb822.py
+++ b/tests/test_deb822.py
@@ -726,6 +726,34 @@ Description: python modules to work with Debian-related
data formats
self.assertEqual(p2['uploaders'],
Bug#597120: python-debian: Changes: Should raise exception when serializing invalid data
On Thu, Sep 16, 2010 at 09:14:28PM +0200, Jelmer Vernooij wrote:
> Package: python-debian
> Version: 0.1.17~bzr184~launchpad1
> Severity: normal
>
>
> The Changes() object (but probably other deb822-style objects as well)
> don't handle the situation very well when a field that contains empty
> lines is followed by another field:
>
> #!/usr/bin/python
> from debian.deb822 import Changes
> x = Changes()
> x["Changes"] = """Foo
>
> Bar
> """
> x["Format"] = "1.8"
> y = Changes(x.dump())
> print y["Format"]
>
> It would be nice if an exception was raised instead of an invalid changes file
> being written.
I actually had a patch out for review about a year ago that would have
fixed this problem at __setitem__ time (it wouldn't have let you set
x["Changes"] to that value). The patch was part of a cleanup series I
never got around to pushing... I've reattached it here, but it probably
doesn't quite apply anymore. I'll work on it over the weekend.
--
John Wright
>From bf321ad6fbdd0541d3b972ab8ec090f4d54d50ef Mon Sep 17 00:00:00 2001
From: John Wright
Date: Wed, 29 Jul 2009 15:17:27 +0200
Subject: [PATCH] deb822: Validate input in Deb822.__setitem__
Try to catch input that would result in multiple stanzas or unparseable
data when dumping the Deb822 object.
This patch also clarifies a comment related to this, and removes an XXX
comment that it addreses.
---
debian_bundle/deb822.py | 35 ---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/debian_bundle/deb822.py b/debian_bundle/deb822.py
index dd1d201..ca35668 100644
--- a/debian_bundle/deb822.py
+++ b/debian_bundle/deb822.py
@@ -358,10 +358,12 @@ class Deb822(Deb822Dict):
else:
return_string = False
for key, value in self.iteritems():
+# We want one space between the "Field:" and value, unless
+# value starts with a newline (i.e. the value itself started on
+# the line *after* the field name in the control file), or is
+# empty. In that case, we avoid trailing whitespace by by not
+# including a space after the colon.
if not value or value[0] == '\n':
-# Avoid trailing whitespace after "Field:" if it's on its own
-# line or the value is empty
-# XXX Uh, really print value if value == '\n'?
fd.write('%s:%s\n' % (key, value))
else:
fd.write('%s: %s\n' % (key, value))
@@ -538,6 +540,33 @@ class Deb822(Deb822Dict):
return self.gpg_info
+def validate_input(self, key, value):
+"""Raise ValueError if value is not a valid value for key
+
+Subclasses that do interesting things for different keys may wish to
+override this method.
+"""
+
+strvalue = str(value)
+
+# The value cannot end in a newline (if it did, dumping the object
+# would result in multiple stanzas)
+if strvalue.endswith('\n'):
+raise ValueError("value must not end in '\\n'")
+
+# Make sure there are no blank lines (actually, the first one is
+# allowed to be blank, but no others), and each subsequent line starts
+# with whitespace
+for line in strvalue.splitlines()[1:]:
+if not line:
+raise ValueError("value must not have blank lines")
+if not line[0] in string.whitespace:
+raise ValueError("each line must start with whitespace")
+
+def __setitem__(self, key, value):
+self.validate_input(key, value)
+Deb822Dict.__setitem__(self, key, value)
+
###
# XXX check what happens if input contains more that one signature
--
1.6.3.3
Bug#585393: Problem in Danish DDTP translation (or in debian_bundle deb822?)
Hi Andreas,
Thanks for the report!
On Mon, Sep 13, 2010 at 09:50:08AM +0200, Andreas Tille wrote:
> Hi,
>
> the DDTP gatherer for UDD[1] produced an error in a Danish translation
> which contains in line 3048:
>
> Description-da: : Islamic hijri date and prayer time utilities
>
> I fixed this in the DDTP webform and thus the problem might vanish
> sooner or later but I wonder if this is another case of not robust
> parsing. I'm not totally sure about RFC 822 and so I don't know what
> the correct behaviour in cases like this should be but the double ':'
> obviosely confuses the parser and leads to a KeyError "Key
> Description-da not found". I just catched this exception in the
> ddtp_gatherer code but I wonder how to solve this cleanly.
>
> The problem is in
>
>
> http://ddtp.debian.net/Translation_udd/dists/squeeze/main/i18n/Translation-da.gz
> (as well as in
>
> http://ddtp.debian.net/Translation_udd/dists/sid/main/i18n/Translation-da.gz )
>
> and I think it should properly parse the Description-da key or
> at least issue a warning about bogus data.
It should definitely have parsed it as
{'Description-da': ': Islamic hijri date and prayer time utilities'}
instead of
{'Description-da:': 'Islamic hijri date and prayer time utilities'}
> PS: If you regard this problem as to different from the previousely
> reported one I can open a new bug report.
Both the apt_pkg implementation and the standard message library parse
it as the first dict above, so I regard this as a bug in the native
deb822 parser. Would you mind opening a new bug to track this? (I
don't mind opening it if you don't get to it, but I probably won't get
to it for a couple of days.)
In the meantime, if you have python-apt installed, and you're using
deb822.Deb822.iter_paragraphs (without a use_apt_pkg=False argument) to
iterate through all of the paragraphs in the Translation file, you
shouldn't hit this.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594411: makedumpfile: kdump-config reports some warnings as failures
notfound 594411 1.3.3-0ubuntu4 found 594411 1.3.4-1 thanks Hi Dave, On Wed, Aug 25, 2010 at 01:40:27PM -0600, dave medberry wrote: > /usr/sbin/kdump-config reports some warnings as failures via log_failure_msg. > Convert those three to a single log_warning_msg. Thanks for the report and patch! I wound up using "echo" directly for the first two lines, since embedded newlines in the string didn't make it to the printed message. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593525: python-debian: Please add a Control object
Hi Benjamin,
On Thu, Aug 19, 2010 at 01:25:30AM +0200, Benjamin Drung wrote:
> Package: python-debian
> Version: 0.1.16
> Severity: wishlist
>
> I want to parse a debian/control file and found no 'Control' object that
> represents a debian/control file. I had to create my own Crontol object that
> contains a list of Deb822 objects:
>
> def get_blocks(blocks, line):
> if line.strip() == "":
> blocks.append(list())
> else:
> blocks[-1].append(line)
> return blocks
>
> lines = open("debian/control").readlines()
> blocks = reduce(get_blocks, lines, [[]])
> self.blocks = map(debian.deb822.Deb822, blocks)
>
> Please add a Control object.
The classes in the deb822 packages each represent one "paragraph" of a
multi-paragraph file. What you probably want is the iter_paragraphs
method on Deb822 (and hence all of its subclasses). It yields one
object for each paragraph in the file. Control files have no special
multivalued fields, so the Deb822 class should work fine:
for paragraph in deb822.Deb822.iter_paragraphs(open('debian/control')):
# paragraph is a Deb822 object.
print paragraph.items()
We could probably use some better documentation for new users
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#585393: Please be more robust against bogus data in a deb822 file
Hi Michael,
On Thu, Jun 10, 2010 at 10:54:39AM +0200, Michael Vogt wrote:
> Package: python-debian
> Version: 0.1.16
> Severity: normal
>
> It appears that the deb822.Deb822.iter_paragraph method gets confused
> if there are bogus entries (like a single line) in the file. Below is
> a test that shows the behavior. Depending on the policy the excpeted
> value is either 2 or 3 (2 if we want to discard invalid stanzas).
What is your use case for this? I'm having a hard time seeing a good
way to handle bogus data consistently. What should the parser yield
when it encounters a bogus stanza?
> It appears that the problem is "while len(x) != 0" in deb822.py, that
> will make the parser stop on the first bogus line. Attached is a
> possible patch for this that makes the EOF handling explicit.
It should be noted that this behavior is specific to the native parser
(which is used when you specify use_apt_pkg=False or you don't have
python-apt installed). When iter_paragraphs uses apt_pkg, it returns a
bogus Deb822 object for the bogus line. Because of apt_pkg's TagParser
implementation, it may appear to have a key corresponding to the bogus
line, but actually trying to get the value for that key will raise
KeyError. This is not good behavior - it breaks the map interface - but
unless we check for validity of the data (which would defeat the purpose
of using apt_pkg), I don't know how do make it better.
Interestingly, with your patch, the native parser returns an empty
Deb822 object (essentially {}). This probably is the best behavior we
can ask for - although I think it should at least raise a warning, and
the behavior should be documented. And...it would be really nice if we
could make the apt_pkg one do the same thing.
Any ideas?
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590805: Updated patch
On Mon, Aug 02, 2010 at 10:24:24PM +0200, Jelmer Vernooij wrote: > On Sun, 2010-08-01 at 01:40 -0700, John Wright wrote: > > On Fri, Jul 30, 2010 at 12:45:07PM +0200, Jelmer Vernooij wrote: > > > Attached patch updates the changelog as well and removes the conflict > > > with older versions of apt. > > Thanks - how about this one? It's a little simpler since the only thing > > we use apt_pkg for in deb822 is TagFile. > Nice, I hadn't thought of that. > > > Also...are you just using the deb822 module on its own? There are > > plenty of dependencies in python-debian that aren't satisfiable in > > Dapper. Also, I just added a feature that depends on UnicodeWarning > > being available, but that's only in python2.5. Thinking about it, > > though, it's better to make a new warning class anyway, hence the second > > patch. With both patches, I think at least deb822 should work fine in a > > Dapper environment. > We're using Python2.5 on Hardy at the moment, and will hopefully be > switching to the next LTS (Lucid) in a couple of months. Sorry if I said > dapper. Ah, ok. I'm rethinking the second patch - UnicodeWarning, according to the Python documentation, is actually intended as a base category for unicode related warnings, which this is...and if you don't need python2.4 support, there's no need to rip it out. (The "What's new in Python 2.5" document suggested that the warning was intended for a very specific problem, but the warning categories documentation makes it seem more general.) > > Shall I commit? > Please do, thanks! Ok, no problem. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590805: Updated patch
On Fri, Jul 30, 2010 at 12:45:07PM +0200, Jelmer Vernooij wrote:
> Attached patch updates the changelog as well and removes the conflict
> with older versions of apt.
Thanks - how about this one? It's a little simpler since the only thing
we use apt_pkg for in deb822 is TagFile.
Also...are you just using the deb822 module on its own? There are
plenty of dependencies in python-debian that aren't satisfiable in
Dapper. Also, I just added a feature that depends on UnicodeWarning
being available, but that's only in python2.5. Thinking about it,
though, it's better to make a new warning class anyway, hence the second
patch. With both patches, I think at least deb822 should work fine in a
Dapper environment.
Shall I commit?
--
John Wright
From 67702928d49e3381f8c39c954da231c1ce0c82a1 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Sun, 1 Aug 2010 01:06:42 -0700
Subject: [PATCH 1/2] Support installation together with older versions of python-apt
The deb822 module only uses apt_pkg for its TagFile interface, which is
only supported in later versions of python-apt. But it's simple enough
to detect whether TagFile is available and fall back to the native
parser, rather than conflicting with earlier versions of python-apt.
Original patch by Jelmer Vernooij.
Closes: #590805
---
debian/changelog |7 +++
debian/control |4 ++--
lib/debian/deb822.py |4 +++-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 7e1188a..5d164a5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-debian (0.1.18) UNRELEASED; urgency=low
+
+ * Support installation together with older versions of python-apt.
+Original patch by Jelmer Vernooij. (Closes: #590805)
+
+ -- John Wright Sun, 01 Aug 2010 01:01:41 -0700
+
python-debian (0.1.17) unstable; urgency=low
[ James Westby ]
diff --git a/debian/control b/debian/control
index d52ab3e..e8ad071 100644
--- a/debian/control
+++ b/debian/control
@@ -20,10 +20,10 @@ Depends: ${python:Depends}, ${misc:Depends}, python-chardet
Recommends: python-apt
Suggests: gpgv
Provides: python-deb822
-Conflicts: python-deb822, python-apt (<< 0.7.94~)
+Conflicts: python-deb822
Replaces: python-deb822
Description: Python modules to work with Debian-related data formats
- This package provides Python modules that abstract many formats of Debian
+ This package provides Python modules that abstract many formats of Debian
related files. Currently handled are:
* Debtags information (debian.debtags module)
* debian/changelog (debian.changelog module)
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 1a21e62..a0cad69 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -26,8 +26,10 @@ from deprecation import function_deprecated_by
try:
import apt_pkg
+# This module uses apt_pkg only for its TagFile interface.
+apt_pkg.TagFile
_have_apt_pkg = True
-except ImportError:
+except (ImportError, AttributeError):
_have_apt_pkg = False
import chardet
--
1.7.1
From 251967b8cf08cfb7acde8602977b83a2f8ec2619 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Sun, 1 Aug 2010 01:25:36 -0700
Subject: [PATCH 2/2] Use our own warning class when auto-detecting string encoding
We used UnicodeWarning initially, but that has specific meaning in the
Python documentation. Furthermore, it's not available in Python 2.4,
and while for Debian we don't need to support older Python versions,
this is the first 2.5-specific dependency in the deb822 module, and it
doesn't provide any benefit.
---
debian/changelog |1 +
lib/debian/deb822.py |7 ++-
tests/test_deb822.py |3 ++-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 5d164a5..01f7732 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ python-debian (0.1.18) UNRELEASED; urgency=low
* Support installation together with older versions of python-apt.
Original patch by Jelmer Vernooij. (Closes: #590805)
+ * Use our own warning class when auto-detecting string encoding.
-- John Wright Sun, 01 Aug 2010 01:01:41 -0700
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index a0cad69..500cbda 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -42,6 +42,11 @@ import warnings
import StringIO
import UserDict
+
+class Deb822EncodingWarning(Warning):
+"""Attempting to detect string encoding using chardet"""
+
+
class TagSectionWrapper(object, UserDict.DictMixin):
"""Wrap a TagSection object, using its find_raw method to get field values
@@ -188,7 +193,7 @@ class Deb822Dict(object, UserDict.DictMixin):
# user specified. Try detecting it.
warnings.warn('decoding from %s failed; attempting to detect '
Bug#590805: python-debian: Older versions of apt_pkg don't have TagFile
Hi Jelmer, On Thu, Jul 29, 2010 at 12:51:24PM +0200, Jelmer Vernooij wrote: > Package: python-debian > Version: 0.1.16ubuntu1 > Severity: normal > > Older versions of apt_pkg don't have a TagFile class, making the > python-debian testsuite fail with these versions of apt_pkg. > > Attached patch makes python-debian only use apt_pkg for iterating over > deb822 style paragraphs using apt_pkg if TagFile is present. Thanks for the patch! But... python-debian actually conflicts with python-apt (<< 0.7.94~), since versions before that either don't have TagFile or have a broken implementation. Are you also suggesting getting rid of the conflicts given this patch? I'm just a bit confused about what problem you're trying to solve, because with only this patch, a system with old python-apt could run the test suite and build the package, but the resulting package couldn't be installed on that system. :) (FWIW, I'm actually ok with removing the conflicts, since I think the TagFile interface is the only reason I added it in the first place. I'm not really worried about someone having the one broken version of python-apt installed.) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586021: python-debian: patch for #586021
Hi Sean,
On Sat, Jun 19, 2010 at 12:36:09PM +0200, sean finney wrote:
> Package: python-debian
> Version: 0.1.16
> Severity: normal
>
> hi,
>
> attached is a patch that does something similar to what i was suggesting
> earlier.
Thanks for your patch. Sorry it took me so long to get to it - I've
been moving and getting settled into a new job.
I wound up going with a different solution, using the python-chardet
package to try to auto-detect the character encoding if the default
decode failed. This way the user usually won't have to worry at all
about encoding issues. It works for me on the etch Sources file.
I've attached the patch I committed, and I'm about to upload. Feel free
to reopen the bug if it doesn't solve your problem!
--
John Wright
From c888992ee90e0e4cff61fedce395b7c40a0f2e8d Mon Sep 17 00:00:00 2001
From: John Wright
Date: Sat, 24 Jul 2010 23:57:07 -0700
Subject: [PATCH] deb822: Use chardet to try to detect character encodings as necessary
This is only used when the specified encoding doesn't work. It's mainly
useful for files containing multiple deb822 paragraphs with mixed
encodings, like etch's Sources file.
To make this consistent, the pure Python parser now just stores the raw
string, putting off the unicode conversion until the user tries to get
an item.
---
debian/changelog |4
debian/control|4 ++--
lib/debian/deb822.py | 37 +++--
tests/test_Sources.mixed_encoding | 34 ++
tests/test_deb822.py | 24
5 files changed, 91 insertions(+), 12 deletions(-)
create mode 100644 tests/test_Sources.mixed_encoding
diff --git a/debian/changelog b/debian/changelog
index 9042957..2637242 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,10 @@ python-debian (0.1.17) UNRELEASED; urgency=low
[ John Wright ]
* test_deb822.py: Make test_gpg_info more robust (Closes: #582878)
+ * deb822: Use chardet to try to detect character encodings as necessary
+- This is only used when the specified encoding doesn't work. It's mainly
+ useful for files containing multiple deb822 paragraphs with mixed
+ encodings, like etch's Sources file. (Closes: #586021)
-- John Wright Fri, 25 Jun 2010 11:20:22 -0600
diff --git a/debian/control b/debian/control
index 3315ae7..d52ab3e 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Uploaders: Adeodato Simó ,
Reinhard Tartler ,
Stefano Zacchiroli ,
John Wright
-Build-Depends: debhelper (>= 5.0.37.2), python, python-setuptools
+Build-Depends: debhelper (>= 5.0.37.2), python, python-setuptools, python-chardet
Build-Depends-Indep: python-support (>= 0.3)
Standards-Version: 3.8.4
Vcs-Browser: http://git.debian.org/?p=pkg-python-debian/python-debian.git
@@ -16,7 +16,7 @@ Vcs-Git: git://git.debian.org/git/pkg-python-debian/python-debian.git
Package: python-debian
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python:Depends}, ${misc:Depends}, python-chardet
Recommends: python-apt
Suggests: gpgv
Provides: python-deb822
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 68af3d2..1a21e62 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -4,7 +4,7 @@
# (.changes, .dsc, Packages, Sources, etc)
#
# Copyright (C) 2005-2006 dann frazier
-# Copyright (C) 2006-2008 John Wright
+# Copyright (C) 2006-2010 John Wright
# Copyright (C) 2006 Adeodato Simó
# Copyright (C) 2008 Stefano Zacchiroli
#
@@ -30,10 +30,13 @@ try:
except ImportError:
_have_apt_pkg = False
+import chardet
import new
import re
import string
import sys
+import warnings
+
import StringIO
import UserDict
@@ -176,7 +179,25 @@ class Deb822Dict(object, UserDict.DictMixin):
if isinstance(value, str):
# Always return unicode objects instead of strings
-value = value.decode(self.encoding)
+try:
+value = value.decode(self.encoding)
+except UnicodeDecodeError, e:
+# Evidently, the value wasn't encoded with the encoding the
+# user specified. Try detecting it.
+warnings.warn('decoding from %s failed; attempting to detect '
+ 'the true encoding' % self.encoding,
+ UnicodeWarning)
+result = chardet.detect(value)
+try:
+value = value.decode(result['encoding'])
+except UnicodeDecodeError:
+raise e
+else:
+# Assume the rest of the paragraph is in this encoding as
+# well (there's no sense in repeating this exercise for
+
Bug#587137: python-debian: FTBFS: failed test
tags 587137 + pending thanks On Fri, Jun 25, 2010 at 01:24:46PM +0100, James Westby wrote: > On Fri, 25 Jun 2010 12:17:48 +0200, Lucas Nussbaum > wrote: > > > == > > > FAIL: test_tar_bz2 (__main__.TestDebFile) > > > -- > > > Traceback (most recent call last): > > > File "./test_debfile.py", line 140, in test_tar_bz2 > > > './usr/share/locale/bg/') > > > AssertionError: './usr/share/locale/bg' != './usr/share/locale/bg/' > > > > > > -- > > > Ran 10 tests in 0.144s > > > > > > FAILED (failures=2) > > > make: *** [build-stamp] Error 1 > > My patch to the list a couple of weeks ago was intended to address these > issues. > > I haven't committed my patch to git yet, as I couldn't bring myself to > fight with git to make sure it pushed the right thing, and I can't > upload anyway. > > If someone wants to upload with the patch that would be great. I just committed and pushed it. I'm planning on working on #586021 in the next few days, so I'll hold off actually uploading for now. John -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586443: [Piuparts-devel] Bug#586443: Bug#586443: piuparts: python DeprecationWarning (sets / debian_bundle)
Hi Holger, On Sun, Jun 20, 2010 at 09:46:02AM +0200, Holger Levsen wrote: > Hi John, > > On Sonntag, 20. Juni 2010, John Wright wrote: > > Sorry; we (the python-debian team) probably should have given some time > > where loading debian_bundle didn't raise a DeprecationWarning. Anyway, > > the attached patch should squelch both warnings. > > Thanks you for that. > > The "import sets" change is unrelated, I assume. Does that work with python > 2.5 as well? Sorry, yes, it's unrelated to the python-debian debian_bundle deprecation. Python < 2.4 didn't have a built-in set type, hence the import sets business (I wrote that chunk to be compatible with python2.3 at the time). So yes, using set instead of sets.Set will work with python2.5. -- John Wright signature.asc Description: Digital signature
Bug#586443: [Piuparts-devel] Bug#586443: Bug#586443: piuparts: python DeprecationWarning (sets / debian_bundle)
tags 586443 + patch thanks On Sat, Jun 19, 2010 at 07:14:29PM +0200, Holger Levsen wrote: > Hi Roland, > > thanks for your bugreport! > > On Samstag, 19. Juni 2010, Roland Stigge wrote: > > # piuparts asp_1.8-7_i386.changes > > /usr/sbin/piuparts:48: DeprecationWarning: the sets module is deprecated > > import sets > > /usr/sbin/piuparts:53: DeprecationWarning: please use 'debian' instead of > > 'debian_bundle' from debian_bundle import deb822 > > Guessed: debian > > the problem is that piuparts.d.o runs piuparts on lenny, where no > debian_bundle exists. > > I assume the module should be loaded conditionally. Sorry; we (the python-debian team) probably should have given some time where loading debian_bundle didn't raise a DeprecationWarning. Anyway, the attached patch should squelch both warnings. -- John Wright Index: piuparts.py === --- piuparts.py (revision 689) +++ piuparts.py (working copy) @@ -45,13 +45,15 @@ import stat import re import pickle -import sets import subprocess import unittest import urllib import uuid -from debian_bundle import deb822 +try: +from debian import deb822 +except ImportError: +from debian_bundle import deb822 class Defaults: @@ -1445,7 +1447,7 @@ def offending_packages(meta_infos, file_owners): """Return a Set of offending packages.""" -pkgset = sets.Set() +pkgset = set() for name, data in meta_infos: if name in file_owners: for pkg in file_owners[name]:
Bug#586021: python-debian: can deb822.Sources can not handle Sources file with mixed data
On Tue, Jun 15, 2010 at 09:20:31PM +0200, sean finney wrote: > Package: python-debian > Version: 0.1.16 > Severity: important > > I was updating the codebase for the debian patch tracker, and have stumbled > across what i believe is a regression. Now that python-debian uses unicode > internally (since 0.1.15 it seems), if a Sources file contains both utf-8 > and latin-1 encoded maintainer names (like the etch Sources file does), > then it seems impossible to produce output from the resulting Sources > instance. Ah, yuck. :( I can think of two possible solutions: * Accept 'raw' as a Deb822 constructor encoding argument, or add a raw_strings keyword argument, that turns off the unicode behavior - Con: old code still breaks with mixed data - you have to change your code to use the new constructor argument - Pro: most consistent results (raw strings are only returned if you explicitly ask for them) * Wrap unicode stuff in try/except, and use the raw string if something goes wrong - Con: not as consistent results as above option - Pro: old code works out-of-box with mixed data Which one do you think makes more sense? -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#581235: udev: net.agent elevated priority causes sshd and dhclient3 to run at nice level -2
Package: udev
Version: 153-2
Severity: normal
Tags: patch
When /etc/network/interfaces has an allow-hotplug interface like
allow-hotplug eth0
iface eth0 inet dhcp
then udev calls ifup, via the /lib/udev/net.agent script on that
interface when it is discovered. But udev helper scripts all run at
nice priority -2 (see the UDEV_PRIORITY #define in udev/udevd.c, and the
call to setpriority() in worker_new()). This would be fine, except that
ifup can start long-running daemons like dhclient3, and it runs all the
scripts in /etc/network/if-up.d, and at least one of those
(openssh-server) runs a daemon's init script with the "restart" target.
This results in some daemons like sshd and dhclient3 running with nice
priority -2.
I don't believe this is an intended effect - I certainly didn't expect
sshd (and hence all processes started or services restarted by a user
ssh-ing in) to run at an elevated scheduling priority. The following
patch to net.agent causes it to set its nice priority to 0 before trying
to do anything else.
--- net.agent.orig 2010-05-11 14:50:38.0 -0600
+++ net.agent 2010-05-11 14:57:18.0 -0600
@@ -3,6 +3,10 @@
# run /sbin/{ifup,ifdown} with the --allow=hotplug option.
#
+# Since running ifup can result in restarting daemons, we should reset our nice
+# priority
+renice -n 0 $$
+
. /lib/udev/hotplug.functions
if [ -z "$INTERFACE" ]; then
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-3-amd64 (SMP w/16 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 udev depends on:
ii debconf [debconf-2.0]1.5.32 Debian configuration management sy
ii libc62.10.2-6Embedded GNU C Library: Shared lib
ii libselinux1 2.0.94-1SELinux runtime shared libraries
ii libusb-0.1-4 2:0.1.12-14 userspace USB programming library
ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip
ii util-linux 2.16.2-0Miscellaneous system utilities
Versions of packages udev recommends:
ii pciutils 1:3.1.7-3 Linux PCI Utilities
ii usbutils 0.87-1+b1 Linux USB utilities
udev suggests no packages.
-- debconf information:
udev/new_kernel_needed: false
udev/title/upgrade:
udev/reboot_needed:
--
+-----+
| John Wright |
| Hewlett-Packard Telco Platform Software |
+-+
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561415: jackd2 in unstable
Hi Adrian, On Mon, May 03, 2010 at 08:46:15PM +0200, Adrian Knoth wrote: > severity 561415 important > quit > > Hi! > > We've switched from jackd1 to jackd2 in unstable, so fmit can't be used > any longer without the patch if you want/need jack inputs. Thanks, I'll take care of that this week. Sorry I've been sitting on this - fmit could probably use a maintainer who uses it on a regular basis. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
reassign 562398 libdebian-installer4-udeb
found 562398 0.69
retitle 562398 libdebian-installer: strange behavior with more than one version
of a package in a Packages file
affects 562398 + anna
tags 562398 + patch
thanks
On Sun, May 02, 2010 at 03:08:08PM -0600, John Wright wrote:
> Specifically, what happens is that anna unpacks all the packages in one
> batch, and then it configures all of them. But while unpacking another
> version of a package while another vesrion is in an
> unpacked-but-not-configured state is ok, it's not ok to configure a
> package that's already in the configured state. So if a package is in
> the list twice, it fails at the second configure for that package.
Here's what's happing in libd-i: Upon encountering a Packages stanza
with the same Package field as one it's previously seen,
di_packages_parser_read_name sets the data pointer the rest of the
parsing functions will use to the previously-used di_packages pointer.
At first glance, this would appear simply to prefer packages that appear
later in the Packages file, irrespective of version. Unfortunately, it
appends the di_package to the package list
(&parser->data->packages->list) whether it's a newly allocated one or an
old one. So while only one actual di_package exists for a particular
package name, it might appear multiple times in the list.
The simple way to fix the anna issue is to make sure we only append
newly allocated di_package objects to the list. But it would be nice to
favor new versions rather than whatever shows up latest in the Packages
file (for example, to facilitate #389430 or LP#234486).
I've attached a quick reproducer to demonstrate the issue, and a patch.
I would prefer if the version comparison could happen during the
Packages file parsing, rather than after the fact (since this way
requires creating a temporary hash table and traversing the list a
couple of extra times), but that change would seem to be very invasive.
In any case, after pounding my head for a couple of hours, I couldn't
figure out how to do it any better with the current parsing
infrastructure. :)
--
John Wright
#include
#include
#include
int main(int argc, char **argv)
{
di_packages_allocator *allocator = di_system_packages_allocator_alloc();
di_packages *packages;
di_package *package, *last_package = NULL;
di_slist_node *node;
const char *packages_file;
if (argc == 2)
packages_file = argv[1];
else {
printf("Usage: %s \n", argv[0]);
return 1;
}
packages = di_system_packages_read_file(packages_file, allocator);
for (node = packages->list.head; node; node = node->next) {
package = node->data;
if (!package)
printf("package == NULL\n");
if (package == last_package)
printf("Eek! package == last_package\n");
printf("Package: %s\n", package->package);
printf("Version: %s\n", package->version);
printf("\n");
last_package = package;
}
return 0;
}
Package: baz
Version: 0.0~hpde1
Package: bang
Version: 0.133
Package: baz
Version: 0.0hpde1
Package: foo
Version: 1.2.3
Package: foo
Version: 1.2.3hpde1
Package: bar
Version: 2.3.4hpde1
Package: bar
Version: 2.3.4
Package: baz
Version: 0.1
>From 64d06247e4fdb35fd7f33eb7020ec84584e23b42 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Sun, 2 May 2010 22:15:11 -0600
Subject: [PATCH] Filter out old versions after parsing a Packages file
The previous behavior favored packages showing up later in the Packages
file rather than packages with later versions, and wound up putting
multiple entries for the same package in the di_packages list. This
patch ensures a new di_package is created for each stanza, and then
filters out all but the latest versions before returning the di_packages
pointer.
There's a small memory leak for each di_slist_node corresponding to an
old package version. It can't be helped, as far as I can tell, because
of how the memory for those are allocated (using mem_chunk). The bulk
of the memory used for those is freed, just not the di_slist_node glue.
This patch also fixes a bug in di_hash_table_insert, where the key was
not being reset after potentially destroying the old key and changing
the value for a key (which may contain the key itself).
---
include/debian-installer/packages.h |4 ++
src/hash.c |1 +
src/packages.c | 69 +++
src/packages_parser.c |8 +++-
4 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/include/debian-installer/packages.h b/include/debian-installer/packages.h
index c5e4576..0d7dd1c 100644
--- a/include/debian-installer/packages.h
+++ b/include/debian-installer/packages.h
@@ -71,6 +71,10 @@ void di_p
Bug#562398: anna: fails if multiple versions of a udeb in Packages file
On Thu, Dec 24, 2009 at 01:30:04PM +0100, Frans Pop wrote: > On Thursday 24 December 2009, Frans Pop wrote: > > So the error is probably the result of anna trying to install the same > > package twice. > > The exit code of anna was 8, which matches an error during unpack or > configure. I've run into this with a custom installer suite with udebs overriding those in lenny's main/debian-installer. My solution at the time was just to filter the Packages file in net-retriever so that anna was only given one version of any particular package. (Ubuntu did something similar, see [1].) However, it should probably be fixed in anna or libdebian-installer itself. :) Specifically, what happens is that anna unpacks all the packages in one batch, and then it configures all of them. But while unpacking another version of a package while another vesrion is in an unpacked-but-not-configured state is ok, it's not ok to configure a package that's already in the configured state. So if a package is in the list twice, it fails at the second configure for that package. I'm trying to better understand anna and libd-i to come up with a suitable patch... [1]: https://bugs.launchpad.net/ubuntu/+source/net-retriever/+bug/234486 -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579651: python-debian: No public API for getting ChangeBlocks from a Changelog
forcemerge 539334 579651 thanks Hi Barry, On Thu, Apr 29, 2010 at 10:48:10AM -0400, Barry Warsaw wrote: > Package: python-debian > Version: 0.1.14ubuntu2 > Severity: important > > > As far as I can tell, there is no public API to get ChangeBlock objects given > a Changelog object. I can use changelog._blocks although that is non-public. > I want to get ChangeBlocks because I want the .changes for a particular > change. This is fixed in version 0.1.15, by making Changelog objects iterable (see [bug 539334][1]). You can download the latest version from [p.d.o][2]. Unless you have verified that a bug is not Ubuntu-specific, you should usually use [Ubuntu's bug reporting tools][3] to file bugs against packages in that distribution. I believe there is a mechanism to ask them to sync a package with Debian in order to fix bugs like this one, but I'm not really familiar with it. You mention wanting to get the .changes for a particular version. Currently the Changelog/ChangeBlock class probably exposes enough information to generate such a file, but it doesn't actually generate a .changes file like from 'dpkg-genchanges'. Feel free to file a wishlist bug via reportbug. Patches are always welcome, too. :) If you do work on it, it would probably be ideal if the method returned a debian.deb822.Changes object. Also note that .changes files can (and often do, in Ubuntu's case) contain changes from a range of versions. I hope you have found python-debian useful! [1]: http://bugs.debian.org/539334 [2]: http://packages.debian.org/sid/python-debian [3]: https://help.ubuntu.com/community/ReportingBugs -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576888: proftpd: inconsistent timezones during DST in logs after chroot
Package: proftpd-basic Version: 1.3.2e-4 Severity: minor Tags: patch Hello, If proftpd is configured to chroot(), e.g. with an stanza or with the DefaultRoot directive, it first sets the TZ variable so that glibc will have something to work with. (See [1] for more information, and pr_auth_chroot() in src/auth.c for the implementation.) Unfortunately, it always picks the non-daylight-savings timezone, so log messages printed after it sets TZ are inconsistent during DST. It's actually pretty simple to determine whether DST is in effect, and the name of the DST timezone from tzname[1]; however, glibc doesn't actually recognize that as a timezone (at least for me - rather than MDT, it wants MST7MDT). Luckily, there's a simple solution that should always work for Debian: set the TZ variable to ":/etc/localtime". I have attached a patch that adds the appropriate directive to the proftpd.conf template with a comment. [1]: http://www.proftpd.org/docs/howto/Timestamps.html -- +-----+ | John Wright | | Hewlett-Packard Telco Platform Software | +-+ >From 83c5b7c053ee8e3b8a53053ae51a493c554027eb Mon Sep 17 00:00:00 2001 From: John Wright Date: Wed, 7 Apr 2010 18:47:17 -0600 Subject: [PATCH] Use consistent timezone in logs Before chroot()ing, if the TZ environment variable isn't set, proftpd will set it to the first element of the tzname global variable, which represents the non-DST timezone. So during DST, all logs after the variable change will be have incorrect timestamps. Unfortunately, while it's easy to determine whether DST is in effect, and to get the name of that timezone, glibc doesn't actually recognize it as a valid timezone. But on Debian systems, we can just set the TZ environment variable to :/etc/localtime to solve the problem. --- debian/templates/proftpd.conf |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/debian/templates/proftpd.conf b/debian/templates/proftpd.conf index 12137f5..2cd0989 100644 --- a/debian/templates/proftpd.conf +++ b/debian/templates/proftpd.conf @@ -85,6 +85,12 @@ AllowOverwrite on # # UseSendFile off +# In order to keep log file dates consistent after chroot, use timezone info +# from /etc/localtime. If this is not set, and proftpd is configured to +# chroot (e.g. DefaultRoot or ), it will use the non-daylight +# savings timezone regardless of whether DST is in effect. +SetEnv TZ :/etc/localtime + TransferLog /var/log/proftpd/xferlog SystemLog /var/log/proftpd/proftpd.log -- 1.6.6
Bug#570686: makedumpfile: FTBFS: makedumpfile.c:1454: error: 'KVBASE' undeclared (first use in this function)
reassign 570686 buildd.debian.org retitle 570686 buildd.debian.org: Please add makedumpfile to Packages-arch-specific severity 570686 normal tags 570686 + patch thanks Hi Kurt, On Sat, Feb 20, 2010 at 07:16:09PM +0100, Kurt Roeckx wrote: > Source: makedumpfile > Version: 1.3.4-1 > Severity: important > > Hi, > > There was an error while trying to autobuild your package: > > > Start Time: 20091217-2025 > > [...] > > > Build-Depends: debhelper (>= 7.0.50), libelf-dev, libz-dev, libdw-dev (>= > > 0.141-2ubuntu1), quilt (>= 0.46-7) > > [...] > > > Toolchain package versions: libc6.1-dev_2.10.2-2 linux-libc-dev_2.6.32-1 > > g++-4.4_4.4.2-5 gcc-4.4_4.4.2-5 binutils_2.20-4 libstdc++6_4.4.2-5 > > libstdc++6-4.4-dev_4.4.2-5 > > [...] > > > gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > > -D_LARGEFILE64_SOURCE -DVERSION='"1.3.4"' -DRELEASE_DATE='"09 October > > 2009"' -D__alpha__ x86.o x86_64.o ia64.o ppc64.o -o makedumpfile > > makedumpfile.c -ldw -lelf -lz > > makedumpfile.c: In function 'readmem': > > makedumpfile.c:414: warning: implicit declaration of function > > 'vaddr_to_paddr' > > makedumpfile.c:440: warning: implicit declaration of function 'kvtop_xen' > > makedumpfile.c: In function 'is_kvaddr': > > makedumpfile.c:1454: error: 'KVBASE' undeclared (first use in this function) > > makedumpfile.c:1454: error: (Each undeclared identifier is reported only > > once > > makedumpfile.c:1454: error: for each function it appears in.) > > makedumpfile.c: In function 'get_die_type': > > makedumpfile.c:1489: warning: 'dwarf_formref' is deprecated (declared at > > /usr/include/elfutils/libdw.h:433) > > makedumpfile.c: In function 'get_debug_info': > > makedumpfile.c:1975: warning: 'elf_getshstrndx' is deprecated (declared at > > /usr/include/libelf.h:275) > > makedumpfile.c: In function 'initial': > > makedumpfile.c:3791: warning: implicit declaration of function > > 'get_phys_base' > > makedumpfile.c:3872: warning: implicit declaration of function > > 'get_machdep_info' > > makedumpfile.c:3878: warning: implicit declaration of function > > 'get_versiondep_info' > > makedumpfile.c: In function 'get_xen_info': > > makedumpfile.c:6317: warning: implicit declaration of function > > 'get_xen_info_arch' > > make[1]: *** [makedumpfile] Error 1 > > make[1]: Leaving directory > > `/build/buildd-makedumpfile_1.3.4-1-alpha-MSCLu3/makedumpfile-1.3.4' > > dh_auto_build: make -j1 returned exit code 2 > > make: *** [build] Error 2 > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > A full build log can be found at: > http://buildd.debian.org/build.php?arch=alpha&pkg=makedumpfile&ver=1.3.4-1 makedumpfile does not have support for alpha (a fact which has always been documented by including only the actually supported architectures in the control file). It sounds like Packages-arch-specific needs to be updated. buildd team: makedumpfile supports a subset of architectures that Linux runs on, as it needs explicit knowledge of the location and layout of certain kernel structures on each architecture. I've attached a patch to update Packages-arch-specific for makedumpfile. Kurt: if you would specifically like to see makedumpfile support alpha, please file a new wishlist bug. See makedumpfile.h, ia64.c, ppc64.c, x86_64.c, and x86.c for examples of what would need to happen to support a new architecture. -- John Wright From adff3ad46f9e1330db02d06181defd34b410bbc2 Mon Sep 17 00:00:00 2001 From: John Wright Date: Sun, 21 Mar 2010 01:07:25 -0600 Subject: [PATCH] Add makedumpfile makedumpfile supports a subset of architectures that Linux runs on, as it needs explicit knowledge of the location and layout of certain kernel structures on each architecture. --- Packages-arch-specific |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Packages-arch-specific b/Packages-arch-specific index 46495cf..cd12239 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -201,6 +201,7 @@ ltrace: i386 m68k arm armel powerpc s390 sparc ia64 amd64 lpia# [p] need %lustre: i386 powerpc amd64 ia64 # ANAIS, no upstream support %mac-fdisk: m68k powerpc # Apple Mac fdisk %m68kboot: m68k # m68k boot loader +%makedumpfile: amd64 i386 ia64 powerpc # not yet ported to other platforms mbr: i386 amd64 lpia # i386 boot loader %mcelog: i386 amd64 # [ANAIS] memtest86: i386 amd64 lpia kfreebsd-i386 kfreebsd-amd64 hurd-i386 # i386 memory tester (bypasses OS entirely) -- 1.5.6.5 signature.asc Description: Digital signature
Bug#573945: Please use the warnings system to report deprecation warnings
On Tue, Mar 16, 2010 at 12:08:21PM +, Enrico Zini wrote: > On Mon, Mar 15, 2010 at 07:42:20PM -0600, John Wright wrote: > > > > At least a mail to the reverse dependencies warning of things before the > > > deprecation is introduced would have been really, really appreciated. > > > > Sorry about that. I'll send a mail out soon (I'm sorry it's not as > > helpful after the fact). We could disable the deprecation warning for > > a while as well, if needed. > > No, it's ok, it's a trivial enough change and the most constructive > thing to do is just to fix apt-xapian-index. I've been away all day > yesterday, so I couldn't do it. > > Just to recap and confirm, it's: > > 1. s/debian_bundle/debian > 2. Depends: python-debian >= 0.1.15 > > nothing else? Right, those two changes are all you need. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573945: Please use the warnings system to report deprecation warnings
tags 573945 + pending
thanks
On Mon, Mar 15, 2010 at 09:36:17AM +0100, Enrico Zini wrote:
> Package: python-debian
> Version: 0.1.15
> Severity: normal
>
> Hello,
>
> thanks for python-debian. I appreciate the importance of dropping the
> "_bundle" bit. However, the way it has been done is causing trouble: see
> #573935.
>
> update-apt-xapian-index is run on a cronjob every week. Such warnings
> spam people. I added this code to prevent it, because python-apt was
> introducing about 2 new deprecation warnings every week, and warnings
> are useful in the terminal when you are developing, but don't belong in
> a cron job in production system:
>
> if options.quiet:
> aptprogress = AptSilentProgress()
> progress = SilentProgress()
> warnings.filterwarnings("ignore","")
>
> However, much to my desperation, python-debian prints the warning in
> this way:
>
> sys.stderr.write("WARNING: the 'debian_bundle' package is *DEPRECATED*; "
>"use the 'debian' package\n")
>
> the same happens, grep told me, in deb822.py:
>
> print >> sys.stderr, "WARNING:",\
> "the 'deb822' top-level module is *DEPRECATED*,", \
> "please use 'debian.deb822'"
You're right, this is inconsiderate behavior on python-debian's part. I
hadn't thought about the deprecation warning spamming users because of
reverse dependencies running in cron. I've changed the code to use
warnings.warn instead.
> Besides this, in the last 4 months all the time I could possibly
> dedicate to apt-xapian-index has been spent chasing deprecation warnings
> being introduced all of a sudden and out of the blue by dependencies.
>
> At least a mail to the reverse dependencies warning of things before the
> deprecation is introduced would have been really, really appreciated.
Sorry about that. I'll send a mail out soon (I'm sorry it's not as
helpful after the fact). We could disable the deprecation warning for
a while as well, if needed.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538376: time to include the patch?[
On Thu, Mar 11, 2010 at 09:30:26AM +0100, sean finney wrote: > On Wed, Mar 10, 2010 at 05:27:56PM -0700, John Wright wrote: > > On Wed, Mar 10, 2010 at 11:12:29PM +0100, sean finney wrote: > > > the blocking bug has been fixed in python-apt, so how about getting > > > this fix uploaded? > > > > I'm waiting on one more fix from python-apt (#572596). That fix is > > uploaded now; I just don't want to break everybody who upgrades > > python-debian while waiting on buildd's to build python-apt. > > why not introduce a conflict or dependency? if it won't work with > that version you should document it, lest backports or testing transitions > risk causing problems for people. Yes, I already did that (Conflicts: python-apt (< 0.7.94~)). The point is until the new python-apt is built everywhere, installing the new version of python-debian will remove python-apt on all architectures but amd64. I'd rather wait and avoid that transition issue. I've also got one more patch I'm waiting for team review on, which would close #573009 and #562257. I still expect to upload this weekend. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562257: [PATCH] debian_support: Add a native Python Version class
Based on the DpkgVersion class by Raphael Hertzog in
svn://svn.debian.org/qa/trunk/pts/www/bin/common.py r2361
Closes: #562257, #573009
---
debian_bundle/debian_support.py | 176 ---
1 files changed, 146 insertions(+), 30 deletions(-)
diff --git a/debian_bundle/debian_support.py b/debian_bundle/debian_support.py
index 6543206..e13a251 100644
--- a/debian_bundle/debian_support.py
+++ b/debian_bundle/debian_support.py
@@ -23,8 +23,13 @@ import hashlib
import types
from deprecation import function_deprecated_by
-import apt_pkg
-apt_pkg.init()
+
+try:
+import apt_pkg
+apt_pkg.init()
+__have_apt_pkg = True
+except ImportError:
+__have_apt_pkg = False
class ParseError(Exception):
"""An exception which is used to signal a parse failure.
@@ -58,24 +63,24 @@ class ParseError(Exception):
printOut = function_deprecated_by(print_out)
-class Version:
-"""Version class which uses the original APT comparison algorithm."""
+class AptPkgVersion(object):
+"""Represents a Debian package version, using apt_pkg.VersionCompare"""
def __init__(self, version):
"""Creates a new Version object."""
-t = type(version)
-if t == types.UnicodeType:
-version = version.encode('UTF-8')
+if not isinstance(version, (str, unicode)):
+raise ValueError, "version must be a string or unicode object"
+
+if isinstance(version, unicode):
+self.__as_string = version.encode("utf-8")
else:
-assert t == types.StringType, `version`
-assert version <> ""
-self.__asString = version
+self.__as_string = version
def __str__(self):
-return self.__asString
+return self.__as_string
def __repr__(self):
-return 'Version(%s)' % `self.__asString`
+return "%s('%s')" % (self.__class__.__name__, self)
def __cmp__(self, other):
return apt_pkg.VersionCompare(str(self), str(other))
@@ -83,8 +88,118 @@ class Version:
def __hash__(self):
return hash(str(self))
+# NativeVersion based on the DpkgVersion class by Raphael Hertzog in
+# svn://svn.debian.org/qa/trunk/pts/www/bin/common.py r2361
+class NativeVersion(object):
+"""Represents a Debian package version, with native Python comparison"""
+
+re_all_digits_or_not = re.compile("\d+|\D+")
+re_digits = re.compile("\d+")
+re_digit = re.compile("\d")
+re_alpha = re.compile("[A-Za-z]")
+re_epoch_and_version = re.compile("(\d*):(.+)")
+re_version_and_revision = re.compile("(.+)-(.*)")
+
+def __init__(self, version):
+result = self.re_epoch_and_version.match(version)
+if result is not None:
+self.epoch = int(result.group(1))
+version = result.group(2)
+self.no_epoch = False
+else:
+self.epoch = 0
+self.no_epoch = True
+result = self.re_version_and_revision.match(version)
+if result is not None:
+self.version = result.group(1)
+self.revision = result.group(2)
+self.no_revision = False
+else:
+self.version = version
+self.revision = "0"
+self.no_revision = True
-version_compare = apt_pkg.VersionCompare
+def __str__(self):
+version = ""
+if not self.no_epoch:
+version += self.epoch + ":"
+version += self.version
+if not self.no_revision:
+version += "-" + self.revision
+return version
+
+def __repr__(self):
+return "%s('%s')" % (self.__class__.__name__, self)
+
+def __cmp__(self, other):
+res = cmp(self.epoch, other.epoch)
+if res != 0:
+return res
+res = self._version_cmp_part(self.version, other.version)
+if res != 0:
+return res
+return self._version_cmp_part(self.revision, other.revision)
+
+@classmethod
+def _order(cls, x):
+"""Return an integer value for character x"""
+if x == '~':
+return -1
+elif cls.re_digit.match(x):
+return int(x) + 1
+elif cls.re_alpha.match(x):
+return ord(x)
+else:
+return ord(x) + 256
+
+@classmethod
+def _version_cmp_string(cls, va, vb):
+la = [cls._order(x) for x in va]
+lb = [cls._order(x) for x in vb]
+while la or lb:
+a = 0
+b = 0
+if la:
+a = la.pop(0)
+if lb:
+b = lb.pop(0)
+res = cmp(a, b)
+if res != 0:
+return res
+return 0
+
+@classmethod
+def _version_cmp_part(cls, va, vb):
+la = cls.re_all_digits_or_not.findall(va)
+lb = cls.re_all_digits_or_not.findall(vb)
+while la or lb:
+a = "0"
+b = "0"
+if la:
+a = la.pop
Bug#538376: time to include the patch?
Hi Sean, On Wed, Mar 10, 2010 at 11:12:29PM +0100, sean finney wrote: > the blocking bug has been fixed in python-apt, so how about getting > this fix uploaded? I'm waiting on one more fix from python-apt (#572596). That fix is uploaded now; I just don't want to break everybody who upgrades python-debian while waiting on buildd's to build python-apt. Hopefully that won't take long, and we'll have an upload this weekend at the latest. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573090: svn-load: should check error condition from overlay_files()
Package: svn-load Version: 1.2-1 Severity: normal Hi Dann, I was trying to load upstream source into a vendor branch that initially had broken source - symlinks in the upstream source were followed, so the branch had directories instead of symlinks. jswri...@neptune:~/tmp$ svn-load $s/hpde branches/packages/module-init-tools/debian.org -t tags/packages/module-init-tools/3.4-1 module-init-tools/ Can't replace directory /tmp/svn-load8cgmRQ/working/module-init-tools/tests/data/32 with file /home/jswright/tmp/module-init-tools/module-init-tools/tests/data/32. Unfortunately, although it complained about not being able to replace a directory with a file, it chugged along and made a tag for me of the broken source tree. It looks like overlay_files() returns False in that case, although it doesn't ever seem to return True. One solution would be to make it return True in case of no errors, and check for the return value in the main program. Or maybe make overlay_files() raise an exception on an error. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages svn-load depends on: ii python2.5.4-5An interactive high-level object-o ii python-svn1.7.2-1A(nother) Python interface to Subv svn-load recommends no packages. svn-load 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#365349: linux-image-*-dbg for squeeze?
Hi Lucas, On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: > On 04/03/10 at 16:40 -0700, John Wright wrote: > > Hi kernel team, > > > > (Cc-ing -devel to get more eyes on the subject, since I'm soliciting > > ideas here... See [1] for some context.) > > > > What would it take to get kernel debuginfo into squeeze? As I > > understand it, the main blockers were [2]: > > Hi John, > > I raised the same question a few weeks ago. See the thread starting at > http://lists.debian.org/debian-devel/2010/02/msg00403.html Agh, I totally missed that discussion. Sorry to bring it back up in a new thread... > Summary: > - Some buildds for slow arches are hosted on DSL lines, making it > unpractical to upload very large kernel images (my -dbg .deb takes > 424 MB on amd64). > => Support could be limited to fast arches with well-connected > buildds: i386, amd64, powerpc, s390 and ia64 > > - Archive space problem > => Support could be limited to some flavours (like, only the standard > one, for a start) I think we could live with those compromises. :) > - Buildd disk space: not a problem on the fast arches > > So, the major blockers seem to be network bandwidth (to upload the > packages) and increased build time for the kernel maintainers. See > http://lists.debian.org/debian-devel/2010/02/msg00472.html > http://lists.debian.org/debian-devel/2010/02/msg00478.html > > I wonder what we (as Debian) could do about it. Would it make sense to > sponsor a very fast machine that the kernel team could use to build the > kernels and upload from, replacing kernel-archive.buildserver.net ? Makes sense to me, especially if it had good connectivity to ftp-master. What would it take to make this happen? And would it make building debug info more palatable to the kernel team? > > Another alternative would be to turn on the CONFIG_DEBUG_INFO and > > CONFIG_KPROBES options, but strip the kernel and modules, but at least > > provide some script a user could run to rebuild the kernel with the same > > options and compiler to get the debug symbols. Or maybe upload the > > debuginfo packages to a separate archive? There was some discussion > > about a large data archive a few years ago, and Joerg mentioned in May > > 2008 that such an archive setup was only a couple weeks out [3]. But I > > haven't heard anything since then... > > It isn't that complicated to build your own kernel image with debuginfo, > and it takes 30 mins on a fast 8-cores system. My notes: > apt-get install linux-image-2.6.32-3-amd64 linux-source-2.6.32 kernel-package > tar xf /usr/src/linux-source-2.6.32.tar.bz2 > cd linux-source-2.6.32 > cp /boot/config-2.6.32-3-amd64 .config > edit .config: > CONFIG_KPROBES=y > CONFIG_DEBUG_INFO=y > make oldconfig > export PATH="/usr/lib/ccache:$PATH" > make-kpkg -j 16 --append-to-version +kprobes --revision=1 --initrd binary-arch True, but it doesn't give you debug data you can use with the kernel Debian actually ships (although it might if CONFIG_KPROBES=y and CONFIG_DEBUG_INFO=y in the real kernel, but it were stripped...). Part of the appeal is being able to use systemtap and crash without also basically having to be your own kernel maintainer. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552190: python-debian: python DeprecationWarning
Hi Julian, On Wed, Mar 03, 2010 at 08:07:51PM +0100, Julian Andres Klode wrote: > Am Mittwoch, den 17.02.2010, 16:34 -0700 schrieb John Wright: > > On Wed, Feb 17, 2010 at 11:54:22AM +0100, Julian Andres Klode wrote: > > > On Thu, Jan 28, 2010 at 03:24:37PM -0700, John Wright wrote: > > > > I have a branch that uses the new TagFile interface. I'll try to merge > > > > that in and upload this week or weekend. I also had a "fix" to ignore > > > > the DeprecationWarning in my local git tree, but I never got around to > > > > pushing or uploading. Sorry about that. > > > > > > > > Thanks for the reminder! > > > > > > You might want to wait for 0.7.93.2 and use the iterator API therein, > > > which does not even use shared storage and should thus be more useful > > > for python-debian. > > > > Ok. Right now we're avoiding shared storage by using a TagFile instance > > for each Deb822 instance returned by its iter_paragraphs class method. > > But it would be nice not to have to do that. :) > > > > I'm not sure if we'll wait, but I'll definitely be converting deb822 to > > the new interface when it's available. > > The new interface is available since 0.7.93.2, and provides a one-time > iterable tagfile (TagFile is an iterator itself; just like file is). > > for section in tagfile: > print section[key] > > Each 'section' refers to a single objects with its own data. Thus you > can also do things like:: > > sections = list(tagfile) I tried this, and ran into corruption if tagfile had more than 30 or 40 paragraphs... See #572596 [1]. For what it's worth, I like the interface a lot better, so I'll be glad to use it once it all works right. :) [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572596 -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572596: python-apt: TagSection corruption when iterating through a TagFile
On Thu, Mar 04, 2010 at 07:01:33PM -0700, John Wright wrote:
> # This prints nothing
> print "Testing while iterating"
> test_keys(deb822_objs, apt_pkg.TagFile(open("/tmp/test_Packages")))
>
> # This has errors, apt_pkg data is corrupt
> print "Testing after making a list from the iterator"
> test_keys(deb822_objs, list(apt_pkg.TagFile(open("/tmp/test_Packages"
>
> # This doesn't have an error for me
> print "Testing after making a list out of only the first 30 entries"
> shorter = []
> sections = iter(apt_pkg.TagFile(open("/tmp/test_Packages")))
> for i in range(30):
> shorter.append(sections.next())
> test_keys(deb822_objs, shorter)
>
> # This doesn't have an error for me
Oops, I mean this *does* have an error for me (as you could see from the
command's output.
> print "Testing after making a list out of only the first 35 entries"
> shorter = []
> sections = iter(apt_pkg.TagFile(open("/tmp/test_Packages")))
> for i in range(35):
> shorter.append(sections.next())
> test_keys(deb822_objs, shorter)
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572596: python-apt: TagSection corruption when iterating through a TagFile
Package: python-apt
Version: 0.7.93.3
Severity: important
Hello,
While trying to convert deb822 in python-debian to use the TagParser
iterator API (rather than an ugly hack to avoid using shared storage), I
ran into this little bug. It seems that after somewhere between 30 or
40 paragraphs (I assume this depends on the size of the paragraphs), old
section instances become corrupt.
Here's a reproducer:
#!/usr/bin/python
import apt_pkg; apt_pkg.init()
from debian_bundle import deb822
deb822_objs = list(deb822.Deb822.iter_paragraphs(open("/tmp/test_Packages"),
use_apt_pkg=False))
def test_keys(iter1, iter2):
iter1 = iter(iter1)
for section in iter2:
d = iter1.next()
if section.keys() != d.keys():
print "key mismatch:", section.keys(), "!=", d.keys()
# This prints nothing
print "Testing while iterating"
test_keys(deb822_objs, apt_pkg.TagFile(open("/tmp/test_Packages")))
# This has errors, apt_pkg data is corrupt
print "Testing after making a list from the iterator"
test_keys(deb822_objs, list(apt_pkg.TagFile(open("/tmp/test_Packages"
# This doesn't have an error for me
print "Testing after making a list out of only the first 30 entries"
shorter = []
sections = iter(apt_pkg.TagFile(open("/tmp/test_Packages")))
for i in range(30):
shorter.append(sections.next())
test_keys(deb822_objs, shorter)
# This doesn't have an error for me
print "Testing after making a list out of only the first 35 entries"
shorter = []
sections = iter(apt_pkg.TagFile(open("/tmp/test_Packages")))
for i in range(35):
shorter.append(sections.next())
test_keys(deb822_objs, shorter)
If I run it on test_Packages from #571470 [1], I get output like:
Testing while iterating
Testing after making a list from the iterator
key mismatch: ['Package', 'pliance-checker\nPri', 'ority', '\nSection',
'alled-Size', '@gmail.com>\nArchit', 'ecture', 'sion', ' pool/main/a',
'/abi-compliance-checker/abi-compliance-ch', 'ecker_1.6-1_all.deb\nSize',
'4a3436442d147c3af44f98a66\nSHA1', 'SHA256', ' by examining the shared
objects\n (.so) files themselves,'] != ['Package', 'Priority', 'Section',
'Installed-Size', 'Maintainer', 'Architecture', 'Version', 'Filename', 'Size',
'MD5sum', 'SHA1', 'SHA256', 'Description', 'Tag']
key mismatch: ['le with a variety of plugi', 'ns.\n .\n This packag', 'e
includes many of', ' the available impor', 't/export plugins allowing\n AbiWord
to interact with ODT, WordPerfect, and other formats. It also\n inclu', 'des
tools plugins, o', 'ffering live co', 'llaboration with A', 'biWord users\n on
Linux and Windows (using', ' TCP or Jabber/XMPP), web translation and', '\n
dictionary support, and more.\n .\n Additional plugin', 's that require
significant amounts of extr', 'a software to\n function are in the various
abiword-plugin-* packa', 'ges.\nHomepag', 'e', 'ce', 'oolkit', 'with-format',
'Homepage', 'Tag'] != ['Package', 'Priority', 'Section', 'Installed-Size',
'Maintainer', 'Architecture', 'Source', 'Version', 'Replaces', 'Provides',
'Depends', 'Conflicts', 'Filename', 'Size', 'MD5sum', 'SHA1', 'SHA256',
'Description', 'Homepage', 'Tag']
Testing after making a list out of only the first 30 entries
Testing after making a list out of only the first 35 entries
key mismatch: ['Package', 'pliance-checker\nPri', 'ority', '\nSection',
'alled-Size', '@gmail.com>\nArchit', 'ecture', 'sion', ' pool/main/a',
'/abi-compliance-checker/abi-compliance-ch', 'ecker_1.6-1_all.deb\nSize',
'4a3436442d147c3af44f98a66\nSHA1', 'SHA256', ' by examining the shared
objects\n (.so) files themselves,'] != ['Package', 'Priority', 'Section',
'Installed-Size', 'Maintainer', 'Architecture', 'Version', 'Filename', 'Size',
'MD5sum', 'SHA1', 'SHA256', 'Description', 'Tag']
key mismatch: ['le with a variety of plugi', 'ns.\n .\n This packag', 'e
includes many of', ' the available impor', 't/export plugins allowing\n AbiWord
to interact with ODT, WordPerfect, and other formats. It also\n inclu', 'des
tools plugins, o', 'ffering live co', 'llaboration with A', 'biWord users\n on
Linux and Windows (using', ' TCP or Jabber/XMPP), web translation and', '\n
dictionary support, and more.\n .\n Additional plugin', 's that require
significant amounts of extr', 'a software to\n function are in the various
abiword-plugin-* packa', 'ges.\nHomepag', 'e', 'ce', 'oolkit', 'with-format',
'Homepage', 'Tag'] != ['Package', 'Priority', 'Section', 'Installed-Size',
'Maintainer', 'Architecture', 'Source', 'Version', 'Replaces', 'Provides',
'Depends', 'Conflicts', 'Filename', 'Size', 'MD5sum', 'SHA1', 'SHA256',
'Description', 'Homepage', 'Tag']
[1]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=test_Packages;att=1;bug=571470
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-68
Bug#365349: linux-image-*-dbg for squeeze?
Hi kernel team, (Cc-ing -devel to get more eyes on the subject, since I'm soliciting ideas here... See [1] for some context.) What would it take to get kernel debuginfo into squeeze? As I understand it, the main blockers were [2]: 1) It would blow up the archive by ~10 GB - This is a lot of space, but I believe it's worth it for crash dump and systemtap support. 2) It would increase the buildd disk requirements as well. Bastion gave a 30 GB figure, given 8 flavors in a particular architecture. - Do we have that many flavors for any arch now?) - Do we have buildd's that are this low on disk space? Couldn't we upgrade them? I haven't tried to see if my patch still applies against the current linux-2.6 packaging. If I made sure it still worked (submitting a new patch if necessary, of course), would you consider accepting it? Another alternative would be to turn on the CONFIG_DEBUG_INFO and CONFIG_KPROBES options, but strip the kernel and modules, but at least provide some script a user could run to rebuild the kernel with the same options and compiler to get the debug symbols. Or maybe upload the debuginfo packages to a separate archive? There was some discussion about a large data archive a few years ago, and Joerg mentioned in May 2008 that such an archive setup was only a couple weeks out [3]. But I haven't heard anything since then... And then there's debug.debian.net - but I suspect that to get kernel debug symbols into there would require changes both to linux-2.6 and the scripts that service uses. Any opinions? Suggestions? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365349 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365349#138 [3]: http://lists.debian.org/debian-devel/2008/05/msg00970.html -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569685: kdump-tools: Incorrect init.d script dependencies
tags 569685 + pending thanks Hi Petter, On Sat, Feb 13, 2010 at 02:01:13PM +0100, Petter Reinholdtsen wrote: > Package: kdump-tools > Version: 1.3.4-1 > Severity: normal > Tags: patch > User: initscripts-ng-de...@lists.alioth.debian.org > Usertags: incorrect-dependency > > With dependency based boot sequencing, I discovered what I believe is > a bug in the init.d scripts of this package, when doing a archive wide > check of the dependencies. This is the error reported: > > error: script kdump-tools/init.d/kdump-tools depend on non-existing > provides: $networking > > This patch should solve the issue. > > diff -ur makedumpfile-1.3.4/debian/kdump-tools.init > makedumpfile-1.3.4-pere/debian/kdump-tools.init > --- makedumpfile-1.3.4/debian/kdump-tools.init 2010-02-13 13:56:10.0 > +0100 > +++ makedumpfile-1.3.4-pere/debian/kdump-tools.init 2010-02-13 > 13:56:37.0 +0100 > @@ -2,7 +2,7 @@ > > ### BEGIN INIT INFO > # Provides: kdump-tools > -# Required-Start:$syslog $time $local_fs $remote_fs $networking > +# Required-Start:$syslog $time $local_fs $remote_fs $network > # Required-Stop: $syslog > # Default-Start: 2 3 4 5 > # Default-Stop: > > Happy hacking, Thanks! Applied. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552190: python-debian: python DeprecationWarning
On Wed, Feb 17, 2010 at 11:54:22AM +0100, Julian Andres Klode wrote: > On Thu, Jan 28, 2010 at 03:24:37PM -0700, John Wright wrote: > > I have a branch that uses the new TagFile interface. I'll try to merge > > that in and upload this week or weekend. I also had a "fix" to ignore > > the DeprecationWarning in my local git tree, but I never got around to > > pushing or uploading. Sorry about that. > > > > Thanks for the reminder! > > You might want to wait for 0.7.93.2 and use the iterator API therein, > which does not even use shared storage and should thus be more useful > for python-debian. Ok. Right now we're avoiding shared storage by using a TagFile instance for each Deb822 instance returned by its iter_paragraphs class method. But it would be nice not to have to do that. :) I'm not sure if we'll wait, but I'll definitely be converting deb822 to the new interface when it's available. Thanks! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570210: Module should be named 'debian', not 'debian_bundle'
On Wed, Feb 17, 2010 at 11:49:18AM +0100, Stefano Zacchiroli wrote: > On Wed, Feb 17, 2010 at 11:37:25AM +0100, Julian Andres Klode wrote: > > The module should be called 'debian' and not 'debian_bundle', in order > > to get 'import debian' working. This is Python Policy, section 2.2. > > Otherwise, > > the package may also be renamed to 'python-debian-bundle' to somehow match > > the Policy in a better way. > > Eh eh, it was about time that issue got raised :-) > > So, we basically have two possibilities: rename the module (to > "debian"), rename the package (to "python-debian-bundle"). I've > personally *never* liked "debian_bundle": it might be correct, but it is > not intuitive at all. > > I'm hence for renaming the module and then providing, just for a > release, a transition path with an empty "debian_bundle" module which > imports "debian" and outputs a deprecation warning. > > What do others think? Agreed the debian_bundle name is a wart, so let's get rid of it (with a transition phase). Fixing the source tree might be funky, though. We'll need an empty parent directory (lib?) since the "root" debian directory is for packaging stuff. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#495272: [PATCH 2/2] deb822: Better support for non-ascii values
Hi Filippo, Thanks for the review, and sorry it took me so long to get back to this. On Sat, Jan 30, 2010 at 08:10:39PM +0100, Filippo Giunchedi wrote: > On Thu, Jan 28, 2010 at 06:41:03PM -0700, John Wright wrote: > > This patch changes Deb822Dict to give back only unicode values. That > > class (and the Deb822 subclass) now takes an encoding argument, which > > defaults to "utf-8", and specifies how incoming strings are to be > > interpreted. Likewise, the dump method takes an optional encoding > > argument to specify how to encode the unicode objects back to byte > > strings before writing out to a file (and it defaults to the encoding > > the object was initialized with). > > looks generally good to me. Do you think this change warrants a NEWS entry? I'd rather not spam everyone upgrading this package, but yeah, the change might not be very nice, depending on whether people commonly use deb822 on non-utf-8-encoded files. I'll write up a news entry and post back here for review. > A couple of tests added just for catching regressions would be good also. That, and an encoding option for Deb822.iter_paragraphs ... Oops. I'll try to come up with some tests to exercise the encoding stuff. > > :param _parsed: internal parameter. > > + > > +:param encoding: When parsing strings, interpret them in this > > encoding. > > +(All values are given back as unicode objects, so an encoding > > is > > + necessary in order to properly interpet the strings.) > > "interpret" typo Fixed, thanks. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414287: me too
Hi Marco, On Fri, Feb 05, 2010 at 01:34:58AM +0100, Marco d'Itri wrote: > On Jan 21, John Wright wrote: > > Thank you for your analisys, it is really appreciated. > But I am not sure that the solution you proposed is optimal: > > > * Don't put the persistent-net rules in the initrd. > >- Users can easily modify persistent-net.rules on the system without > > running update-initramfs, and there's no point in setting up > > interfaces twice anyway. > Actually there is a point: what about systems booting from iSCSI, NFS > or NBD? I suppose they rely on network devices being correctly named > in the initramfs before the root is mounted. I didn't think of that. I guess we should care in that case. :) > > our persistent-net.rules. Then, we add another interface, which > > the kernel happens to see as eth0. Without > > persistent-net-generator.rules (or rather, without write_net_rules, > > which isn't included in the initrd), the new interface will never > Now I wonder why I added persistent-net-generator.rules without > write_net_rules... Maybe I should add write_net_rules too, but I would > first need to modify it to always use /dev/.udev/ when running in the > initramfs. Maybe. I'm not sure it would be consistent, though. What if the initrd doesn't have persistent-net-rules for two new interfaces? With write_net_rules in the initramfs, we should at least have successfully renamed all the devices in initramfs, and the "real" persistent-net-rules file on the rootfs would then get the order found in initramfs the first time. But what about subsequent boots? If we don't regenerate the initramfs, it's still possible that network device order in initramfs will be different than the one decided when udev runs in real init. -- +-+ | John Wright | | Hewlett-Packard Telco Platform Software | +-+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568325: crash: makefiles run 'arch' in a subshell
Package: crash Version: 5.0.0-1 Severity: minor There are lots of occurrances of '$(shell arch)' in crash's Makefiles (and in gdb-7.0.patch, patching gdb-7.0/Makefile.in). gdb-7.0.patch:+ifeq ($(shell arch), ppc64) gdb-7.0.patch:+ifeq ($(shell arch), ppc64) extensions/snap.mk:ifeq ($(shell arch), i686) extensions/snap.mk:ifeq ($(shell arch), ppc64) extensions/snap.mk:ifeq ($(shell arch), ia64) extensions/snap.mk:ifeq ($(shell arch), x86_64) Nothing provides /bin/arch in lenny; it was added back into coreutils in version 7.4-1. Since this really only affects backports to lenny, maybe it's reasonable to leave it alone; but a fix that would work everywhere is to change all the "arch" references to "uname -m". See http://bugs.debian.org/446023 -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages crash depends on: ii libc6 2.10.2-4 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20090803-2 shared libraries for terminal hand ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime crash recommends no packages. Versions of packages crash suggests: pn dumputils (no description available) pn kernel-patch-lkcd (no description available) -- 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#495272: [PATCH 1/2] deb822: Refactor _multivalued.dump
This method used to re-implement much of Deb822.dump; now, Deb822.dump
relies on a get_as_string method, and _multivalued overrides that method
for multivalued fields.
---
debian_bundle/deb822.py | 85 +-
1 files changed, 39 insertions(+), 46 deletions(-)
diff --git a/debian_bundle/deb822.py b/debian_bundle/deb822.py
index a3298d5..b3acb69 100644
--- a/debian_bundle/deb822.py
+++ b/debian_bundle/deb822.py
@@ -346,6 +346,15 @@ class Deb822(Deb822Dict):
# __repr__ is handled by Deb822Dict
+def get_as_string(self, key):
+"""Return the self[key] as a string (or unicode)
+
+The default implementation just returns unicode(self[key]); however,
+this can be overridden in subclasses (e.g. _multivalued) that can take
+special values.
+"""
+return unicode(self[key])
+
def dump(self, fd=None):
"""Dump the the contents in the original format
@@ -357,7 +366,9 @@ class Deb822(Deb822Dict):
return_string = True
else:
return_string = False
-for key, value in self.iteritems():
+
+for key in self.iterkeys():
+value = self.get_as_string(key)
if not value or value[0] == '\n':
# Avoid trailing whitespace after "Field:" if it's on its own
# line or the value is empty
@@ -842,53 +853,35 @@ class _multivalued(Deb822):
for line in filter(None, contents.splitlines()):
updater_method(Deb822Dict(zip(fields, line.split(
-def dump(self, fd=None):
-"""Dump the contents in the original format
-
-If fd is None, return a string.
-"""
-
-if fd is None:
+def get_as_string(self, key):
+keyl = key.lower()
+if keyl in self._multivalued_fields:
fd = StringIO.StringIO()
-return_string = True
-else:
-return_string = False
-for key in self.keys():
-keyl = key.lower()
-if keyl not in self._multivalued_fields:
-value = self[key]
-if not value or value[0] == '\n':
-# XXX Uh, really print value if value == '\n'?
-fd.write('%s:%s\n' % (key, value))
-else:
-fd.write('%s: %s\n' % (key, value))
-else:
-fd.write(key + ":")
-if hasattr(self[key], 'keys'): # single-line
-array = [ self[key] ]
-else: # multi-line
-fd.write("\n")
-array = self[key]
-
-order = self._multivalued_fields[keyl]
-try:
-field_lengths = self._fixed_field_lengths
-except AttributeError:
-field_lengths = {}
-for item in array:
-for x in order:
-raw_value = str(item[x])
-try:
-length = field_lengths[keyl][x]
-except KeyError:
-value = raw_value
-else:
-value = (length - len(raw_value)) * " " + raw_value
-fd.write(" %s" % value)
-fd.write("\n")
-if return_string:
-return fd.getvalue()
+if hasattr(self[key], 'keys'): # single-line
+array = [ self[key] ]
+else: # multi-line
+fd.write("\n")
+array = self[key]
+order = self._multivalued_fields[keyl]
+try:
+field_lengths = self._fixed_field_lengths
+except AttributeError:
+field_lengths = {}
+for item in array:
+for x in order:
+raw_value = str(item[x])
+try:
+length = field_lengths[keyl][x]
+except KeyError:
+value = raw_value
+else:
+value = (length - len(raw_value)) * " " + raw_value
+fd.write(" %s" % value)
+fd.write("\n")
+return fd.getvalue().rstrip("\n")
+else:
+return Deb822.get_as_string(self, key)
###
--
1.6.6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#495272: [PATCH 0/2] deb822: Better support for non-ascii values
tags 495272 + patch thanks This is a proposed patchset for bug 495272. I think the first in the series should be applied either way - it fixes a wart in _multivalued, that its dump method reimplements a lot of Deb822.dump. I'm looking for comments on the second patch, since it changes a fairly fundamental aspect of how Deb822 objects work. Basically, it ensures all "string" values in a Deb822 object are returned as unicode objects instead. When it takes a byte string (whether from a file or other iterator) as input, it uses the new encoding keyword argument given to its constructor to decode the string to a unicode object. Deb822 objects can still contain non-string-type values, and in that case, the __getitem__ method doesn't attempt any conversion. (So you still could have a list of strings with non-ascii characters, which could be problematic. But in general, we've only ensured that you can dump a Deb822 object if its values are strings or supported multivalued lists, so I think this is acceptable.) Anybody see shortcomings I have missed? John Wright (2): deb822: Refactor _multivalued.dump deb822: Better support for non-ascii values debian_bundle/deb822.py | 135 --- tests/test_deb822.py|2 +- 2 files changed, 81 insertions(+), 56 deletions(-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#495272: [PATCH 2/2] deb822: Better support for non-ascii values
This patch changes Deb822Dict to give back only unicode values. That
class (and the Deb822 subclass) now takes an encoding argument, which
defaults to "utf-8", and specifies how incoming strings are to be
interpreted. Likewise, the dump method takes an optional encoding
argument to specify how to encode the unicode objects back to byte
strings before writing out to a file (and it defaults to the encoding
the object was initialized with).
---
debian_bundle/deb822.py | 50 ++
tests/test_deb822.py|2 +-
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/debian_bundle/deb822.py b/debian_bundle/deb822.py
index b3acb69..6fed5ea 100644
--- a/debian_bundle/deb822.py
+++ b/debian_bundle/deb822.py
@@ -127,10 +127,12 @@ class Deb822Dict(object, UserDict.DictMixin):
# See the end of the file for the definition of _strI
-def __init__(self, _dict=None, _parsed=None, _fields=None):
+def __init__(self, _dict=None, _parsed=None, _fields=None,
+ encoding="utf-8"):
self.__dict = {}
self.__keys = OrderedSet()
self.__parsed = None
+self.encoding = encoding
if _dict is not None:
# _dict may be a dict or a list of two-sized tuples
@@ -165,13 +167,18 @@ class Deb822Dict(object, UserDict.DictMixin):
def __getitem__(self, key):
key = _strI(key)
try:
-return self.__dict[key]
+value = self.__dict[key]
except KeyError:
if self.__parsed is not None and key in self.__keys:
-return self.__parsed[key]
+value = self.__parsed[key]
else:
raise
+if isinstance(value, str):
+# Always return unicode objects instead of strings
+value = value.decode(self.encoding)
+return value
+
def __delitem__(self, key):
key = _strI(key)
self.__keys.remove(key)
@@ -217,7 +224,8 @@ class Deb822Dict(object, UserDict.DictMixin):
class Deb822(Deb822Dict):
-def __init__(self, sequence=None, fields=None, _parsed=None):
+def __init__(self, sequence=None, fields=None, _parsed=None,
+ encoding="utf-8"):
"""Create a new Deb822 instance.
:param sequence: a string, or any any object that returns a line of
@@ -228,6 +236,10 @@ class Deb822(Deb822Dict):
should be parsed (the rest will be discarded).
:param _parsed: internal parameter.
+
+:param encoding: When parsing strings, interpret them in this encoding.
+(All values are given back as unicode objects, so an encoding is
+necessary in order to properly interpet the strings.)
"""
if hasattr(sequence, 'items'):
@@ -235,7 +247,8 @@ class Deb822(Deb822Dict):
sequence = None
else:
_dict = None
-Deb822Dict.__init__(self, _dict=_dict, _parsed=_parsed, _fields=fields)
+Deb822Dict.__init__(self, _dict=_dict, _parsed=_parsed, _fields=fields,
+encoding=encoding)
if sequence is not None:
try:
@@ -305,6 +318,8 @@ class Deb822(Deb822Dict):
curkey = None
content = ""
for line in self.gpg_stripped_paragraph(sequence):
+if isinstance(line, str):
+line = line.decode(self.encoding)
m = single.match(line)
if m:
if curkey:
@@ -344,6 +359,9 @@ class Deb822(Deb822Dict):
def __str__(self):
return self.dump()
+def __unicode__(self):
+return self.dump()
+
# __repr__ is handled by Deb822Dict
def get_as_string(self, key):
@@ -355,10 +373,15 @@ class Deb822(Deb822Dict):
"""
return unicode(self[key])
-def dump(self, fd=None):
+def dump(self, fd=None, encoding=None):
"""Dump the the contents in the original format
-If fd is None, return a string.
+If fd is None, return a unicode object.
+
+If fd is not None, attempt to encode the output to the encoding the
+object was initialized with, or the value of the encoding argument if
+it is not None. This will raise UnicodeEncodeError if the encoding
+can't support all the characters in the Deb822Dict values.
"""
if fd is None:
@@ -367,15 +390,24 @@ class Deb822(Deb822Dict):
else:
return_string = False
+if encoding is None:
+# Use the encoding we've been using to decode strings with if none
+# was explicitly specified
+encoding = self.encoding
+
for key in self.iterkeys():
value = self.get_as_string(key)
if not value or value[0] == '\n':
# Avoid trailing whitespace after "Field:" if it's on its own
# line or the value is empty
# XXX Uh, really
Bug#552190: python-debian: python DeprecationWarning
Hi Sven, On Mon, Jan 25, 2010 at 09:30:14AM +0100, Sven Joachim wrote: > On 2009-10-26 16:52 +0100, John Wright wrote: > > > On Sat, Oct 24, 2009 at 07:39:21AM +0200, Laurent Bonnaud wrote: > >> # update-apt-xapian-index --quiet > >> /usr/lib/pymodules/python2.5/debian_bundle/deb822.py:244: > >> DeprecationWarning: apt_pkg.ParseTagFile() is deprecated. Please see > >> apt_pkg.TagFile() for the replacement. > >> parser = apt_pkg.ParseTagFile(sequence) > >> > >> This is annoying because every week, /etc/cron.weekly/apt-xapian-index > >> outputs this warning and an e-mail is sent to the admin. > >> [...] > > > > Unfortunately, the apt_pkg.TagFile interface is not available in the > > version of python-apt in unstable. I'll see if the interface is similar > > enough to the old ParseTagFile one to make deb822 use it if it's > > available but fall back on the old one if not. If it would mean a bunch > > of extra code, I'd prefer to wait until this shows up in unstable. > > Which has just happened with the upload of python-apt 0.7.93 to unstable > last week. Today I received a mail from the weekly cron job with the > above warning. I have a branch that uses the new TagFile interface. I'll try to merge that in and upload this week or weekend. I also had a "fix" to ignore the DeprecationWarning in my local git tree, but I never got around to pushing or uploading. Sorry about that. Thanks for the reminder! -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414287: me too
reassign 414287 udev 0.125-7+lenny3 tags 414287 + patch thanks On Thu, May 21, 2009 at 10:50:51PM +0100, Daniel Pocock wrote: > My box had lenny (installed in December, before the official > release), I just did: > > apt-get dist-upgrade > > It upgraded the box from 2.6.26-1 to 2.6.26-2 > > I did a reboot to get the new kernel > > On booting, eth0 became eth0_rename_ren > > I looked at: > > /etc/udev/rules.d/70-persistent-net.rules > > and found each MAC listed multiple times, with variations of > eth0_rename and eth0, etc > > I deleted the file completely, rebooted again, and found the > interfaces eth1, eth0_rename, eth2_rename and eth3_rename on my > system, and each of these describe once in > /etc/udev/rules.d/70-persistent-net.rules > > I edited the file by hand, remove _rename from each of the names, > rebooted again and now I have eth0, eth1, eth2, eth3 > > Now for another reboot - and I still have eth0, eth1, eth2, eth3 now. > > My biggest concern is that booting without any > /etc/udev/rules.d/70-persistent-net.rules gave me three interfaces > with _rename appended to their names. > > One other comment, not sure if it could be related to the issue in any > way, but this is a Xen dom0 box, and Xen does it's usual tricks > renaming interfaces, but not until after the udev setup. I have seen this issue before, and the culprit was having a stale 70-persistent-net.rules file in the initrd. It happened to us when we added a network interface and didn't re-build the initrd, but the symptoms look the same. The attached patch fixed the issue for us. -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ Cleanly handle when new network interfaces are added to the system * Don't put the persistent-net rules in the initrd. - Users can easily modify persistent-net.rules on the system without running update-initramfs, and there's no point in setting up interfaces twice anyway. - More importantly, suppose we have set up rules for eth0 and eth1 in our persistent-net.rules. Then, we add another interface, which the kernel happens to see as eth0. Without persistent-net-generator.rules (or rather, without write_net_rules, which isn't included in the initrd), the new interface will never be renamed away from eth0. So the process that tries to rename our previously configured interface to eth0 will sit for 30 seconds waiting for this to happen before finally giving up (and leaving an ethN_rename interface behind). Index: udev/extra/initramfs.hook === --- udev.orig/extra/initramfs.hook 2009-06-15 18:33:30.0 -0600 +++ udev/extra/initramfs.hook 2009-06-15 18:33:50.0 -0600 @@ -18,6 +18,8 @@ cp -a /etc/udev/ $DESTDIR/etc/ rm -f $DESTDIR/etc/udev/rules.d/75-cd-aliases-generator.rules +rm -f $DESTDIR/etc/udev/rules.d/75-persistent-net-generator.rules +rm -f $DESTDIR/etc/udev/rules.d/70-persistent-net.rules if [ -e /etc/scsi_id.config ]; then cp /etc/scsi_id.config $DESTDIR/etc/ fi
Bug#565238: libparse-debianchangelog-perl: should allow '.' and '+' in distribution
Package: libparse-debianchangelog-perl
Version: 1.1.1-2
Severity: normal
Tags: patch
Hello,
The regular expression for the distribution in the changelog is more
restrictive than that in dpkg's Dpkg::Changelog::Debian module. dpkg
has allowed '.' and '+' characters in the distribution field since
version 1.13.20 (see http://bugs.debian.org/361171). The attached patch
makes the regexp more closely match the one in dpkg.
--
+------+
| John Wright |
| HP Mission Critical OS Enablement & Solution Test (MOST) |
+--+
>From 57ea8d5148560321dc808611a738405defbbdda6 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Wed, 13 Jan 2010 18:35:26 -0700
Subject: [PATCH] Parse::DebianChangelog: Allow '.' and '+' in distribution name
---
lib/Parse/DebianChangelog.pm |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Parse/DebianChangelog.pm b/lib/Parse/DebianChangelog.pm
index 30186de..56632b8 100644
--- a/lib/Parse/DebianChangelog.pm
+++ b/lib/Parse/DebianChangelog.pm
@@ -312,7 +312,7 @@ sub parse {
while (<$fh>) {
s/\s*\n$//;
# printf(STDERR "%-39.39s %-39.39s\n",$expect,$_);
- if (m/^(\w[-+0-9a-z.]*) \(([^\(\) \t]+)\)((\s+[-0-9a-z]+)+)\;/i) {
+ if (m/^(\w[-+0-9a-z.]*) \(([^\(\) \t]+)\)((\s+[-+0-9a-z.]+)+)\;/i) {
unless ($expect eq 'first heading'
|| $expect eq 'next heading or eof') {
$entry->{ERROR} = [ $file, $NR,
--
1.6.6
Bug#561674: nfs-kernel-server: Version 1.2.1-2 still not working (reopen this bug?)
Hi Dave,
On Wed, Jan 13, 2010 at 10:13:07AM -0500, Dave Witbrodt wrote:
> Package: nfs-kernel-server
> Version: 1:1.2.1-2
> Severity: normal
>
>
> Updated this morning, and the init script still doesn't want to start.
> (I build NFS support into my kernel.)
> I experimented with the following change:
>
> # diff /etc/init.d/nfs-kernel-server.{orig,new}
> 67c67
> < if [ -f /proc/kallsyms ] && ! grep -Eqm1 ' nfsd_.*
> *\[nfsd\]' /proc/kallsyms; then
> ---
> > if [ -f /proc/kallsyms ] && ! grep -Eqm1 ' nfsd$'
> /proc/kallsyms; then
>
> ... and it appears to be working. I don't know if this is the *right*
> fix, but I'll use it for now -- until an official fix is adopted.
Unfortunatlely, *this* one only works with nfsd built into the kernel :)
How about something like
if [ -f /proc/kallsyms ] && ! grep -Eqm1 ' nfsd([[:space:]]|$)'
/proc/kallsyms; then
(match ' nfsd' followed by whitespace - for the module case - or the end
of line - for the built-in case) which should work at least as far back
as 2.6.10. Or something like Joerg Dorchain suggested:
if ! grep '[[:space:]]nfsd$' /proc/filesystems; then
--
+--+
| John Wright |
| HP Mission Critical OS Enablement & Solution Test (MOST) |
+--+
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561674: nfs-kernel-server: Test for NFS kernel server support in init script doesn't work for compiled in nfs support
Hi Anibal, On Wed, Jan 13, 2010 at 02:35:56AM +, Aníbal Monsalve Salazar wrote: > On Tue, Jan 12, 2010 at 06:38:42PM -0700, John Wright wrote: > > >Unfortunately, /proc/fs/nfsd exists regardless of whether the kernel > >has nfsd support. (It's created in proc_root_init in fs/root/root.c, > >so whenever /proc is mounted, it has /proc/fs/nfsd/.) > > > >Perhaps the right solution is going back to reading /proc/kallsyms, but > >looking for a symbol other than init_nfsd. > > What do you think about the following check? > > if [ -f /proc/kallsyms ] && ! grep -E ' nfsd_.* *\[nfsd\]' /proc/kallsyms; > then Wouldn't that only match when the symbols are provided by the nfsd module (not built-in)? Maybe if [ -f /proc/kallsyms ] && ! grep -E ' nfsd_open[[:space:]]' /proc/kallsyms; then I assume nfsd_open has been around forever, but I haven't checked... -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561674: nfs-kernel-server: Test for NFS kernel server support in init script doesn't work for compiled in nfs support
tags 561674 - patch thanks On Sat, Dec 19, 2009 at 03:17:29PM +0100, Elimar Riesebieter wrote: > Package: nfs-kernel-server > Version: 1:1.2.0-4.1 > Severity: important > Tags: patch > > > Test for NFS kernel server support in init script doesn't work for compiled in > nfs support. The attached patch works for my kernels. > diff -Naurd nfs-utils-1.2.0~/debian/nfs-kernel-server.init > nfs-utils-1.2.0/debian/nfs-kernel-server.init > --- nfs-utils-1.2.0~/debian/nfs-kernel-server.init2009-12-19 > 14:40:41.0 +0100 > +++ nfs-utils-1.2.0/debian/nfs-kernel-server.init 2009-12-19 > 14:43:00.0 +0100 > @@ -64,7 +64,7 @@ > do_modprobe nfsd > > # See if our running kernel supports the NFS kernel server > - if ! [ -d /sys/module/nfsd ]; then > + if ! [ -d /proc/fs/nfsd ]; then > log_warning_msg "Not starting $DESC: no support in > current kernel." > exit 0 > fi Unfortunately, /proc/fs/nfsd exists regardless of whether the kernel has nfsd support. (It's created in proc_root_init in fs/root/root.c, so whenever /proc is mounted, it has /proc/fs/nfsd/.) Perhaps the right solution is going back to reading /proc/kallsyms, but looking for a symbol other than init_nfsd. -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542540: fmit: FTBFS on GNU/kFreeBSD due to missing include
Hi KiBi, On Mon, Dec 21, 2009 at 09:46:26AM +0100, Cyril Brulebois wrote: > Cyril Brulebois (20/08/2009): > > Package: fmit > > Version: 0.97.7-2 > > Severity: important > > Tags: patch > > User: debian-...@lists.debian.org > > Usertags: kfreebsd > > No reply in months, I've uploaded an NMU which fixes this FTBFS. Yikes, I'm not sure how I lost track of this for so long. Thanks for the upload. > > a single tweak is needed to get your package built on GNU/kFreeBSD, > > which you can find in the attached patch. It pretty much looks like > > all those other include-cleaning-related issues when porting to a > > newer gcc version, see build logs[1]. > > I could trigger this FTBFS on a Linux environment, so I guess there > are some tiny architecture-related disparities. Anyway, since exit() > is used, let's just add the include as initially suggested. > > Please find attached the source debdiff for my NMU. Thanks! -- John Wright signature.asc Description: Digital signature
Bug#552190: python-debian: python DeprecationWarning
Hi Laurent,
On Sat, Oct 24, 2009 at 07:39:21AM +0200, Laurent Bonnaud wrote:
> Package: python-debian
> Version: 0.1.14
> Severity: normal
>
>
> Hi,
>
> here is the problem:
>
> # update-apt-xapian-index --quiet
> /usr/lib/pymodules/python2.5/debian_bundle/deb822.py:244:
> DeprecationWarning: apt_pkg.ParseTagFile() is deprecated. Please see
> apt_pkg.TagFile() for the replacement.
> parser = apt_pkg.ParseTagFile(sequence)
>
> This is annoying because every week, /etc/cron.weekly/apt-xapian-index
> outputs this warning and an e-mail is sent to the admin.
>
>
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 2.6.31-trunk-686-bigmem (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/bash
>
> Versions of packages python-debian depends on:
> ii python2.5.4-3An interactive high-level
> object-o
> ii python-support1.0.4 automated rebuilding support for
> P
>
> Versions of packages python-debian recommends:
> ii python-apt0.7.92 Python interface to libapt-pkg
>
> Versions of packages python-debian suggests:
> ii gpgv 1.4.10-2 GNU privacy guard - signature
> veri
Unfortunately, the apt_pkg.TagFile interface is not available in the
version of python-apt in unstable. I'll see if the interface is similar
enough to the old ParseTagFile one to make deb822 use it if it's
available but fall back on the old one if not. If it would mean a bunch
of extra code, I'd prefer to wait until this shows up in unstable.
Meanwhile, you can patch deb822.py like this:
diff --git a/debian_bundle/deb822.py b/debian_bundle/deb822.py
index dd1d201..371fe9b 100644
--- a/debian_bundle/deb822.py
+++ b/debian_bundle/deb822.py
@@ -27,6 +27,9 @@ from deprecation import function_deprecated_by
try:
import apt_pkg
_have_apt_pkg = True
+import warnings
+warnings.filterwarnings("ignore", category=DeprecationWarning,
+message=r"apt_pkg.ParseTagFile\(\) is deprecated")
except ImportError:
_have_apt_pkg = False
I'll consider committing a patch like this, but I don't really like to
ignore warnings in released code...
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530595: quinn-diff: should only exclude arch:all on -i
tags 530595 + patch
thanks
On Tue, May 26, 2009 at 10:33:19AM +0200, Philipp Kern wrote:
> Due to a change in dpkg-source some packages don't just end up
> with arch:any anymore if they contain arch-specific binary
> packages and an arch:all, but instead they end up with
> something like "i386 all". If -i is passed to quinn-diff it
> ignores such packages which is wrong.
I've attached a patch that fixes the issue for me. The solution is to
ignore a package with "all" in the architecture list only if the current
architecture (specified by --architecture or detected from the Packages
file) isn't also in the architecture list.
--
+------+
| John Wright |
| HP Mission Critical OS Enablement & Solution Test (MOST) |
+--+
>From 10d1a7f82c924aaf2c3cc4517e0ca354d251cf68 Mon Sep 17 00:00:00 2001
From: John Wright
Date: Thu, 15 Oct 2009 14:24:12 -0600
Subject: [PATCH] Be more careful with --ignore-arch-all
Historically, dpkg-source would output "Architecture: any" on any source
package that built binaries for more than one architecture. As of
dpkg-dev version 1.15.1, it spells out each architecture, so we end up
with architecture lines like
Architecture: all amd64 i386 ia64
for a package that builds arch-all binaries, plus architecture-specific
binaries on amd64, i386, and ia64, but not on any other architectures.
This patch changes the ignore_arch_all logic in parse_sources() to
ignore a package with "all" in the architecture list only if it also
doesn't find the current architecture (either detected in the given
Packages file or specified by --architecture) in the architecture list.
Closes: #530595
---
src/parse_sources.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/parse_sources.c b/src/parse_sources.c
index 0006e8c..cb7904f 100644
--- a/src/parse_sources.c
+++ b/src/parse_sources.c
@@ -85,7 +85,8 @@ parse_sources (sources_info *source)
}
/* If we're ignoring 'Architecture: all' packages, check this isn't */
- if (ignore_arch_all && in_arch_list(source->architecture,"all"))
+ if (ignore_arch_all && in_arch_list(source->architecture, "all")
+ && !in_arch_list(source->architecture, packages_architecture))
{
debug (debug_sources, "parse_sources: ignoring 'Architecture: all' source packages, and %s is ('%s').", source->name, source->architecture);
continue;
--
debian.1.6.3.3.1.7.g944a7
Bug#539316: python-debian: Parsing an existing changelog duplicates newlines
tags 539316 + patch
thanks
Hi Michael,
On Thu, Jul 30, 2009 at 06:34:20PM +0200, Michael Bienia wrote:
> Package: python-debian
> Version: 0.1.14
> Severity: normal
Thanks for the report.
> I was looking if I can use the Changelog class to access changelog
> entries from a existing changelogs. The parsing of a existing changelog
> went fine but then I found out that there are no methods to iterate over
> (or access) existing changelog blocks (I'd should file a wishlist bug
> about this instead of accessing internal structures)
Yes, please file this as a separate bug...
> but the more
> important problem was that I got to many newlines when I tried to get a
> string representation of a changelog block.
> (Note: this was with pyhton 2.6 on Ubuntu if it's important)
>
> >>> c = debian_bundle.changelog.Changelog(file('changelog.txt', 'r'))
> >>> print c
To work around this for now, please pass the whole file in as a string:
>>> c = debian_bundle.changelog.Changelog(file('changelog.txt', 'r').read())
I'm attaching a patch that fixes the bug and adds a testcase. James,
would you review and apply if you agree?
--
John Wright
commit 1be5f14ee2e432ede73e3db70f12fd7beb0eeb4c
Author: John Wright
Date: Thu Jul 30 19:44:51 2009 +0200
changelog: Consistently parse different types of inputs
The previous implementation added extra newlines when given a file as
input, rather than the result of whole_string.splitlines().
diff --git a/debian_bundle/changelog.py b/debian_bundle/changelog.py
index 07fe4fa..ae72a90 100644
--- a/debian_bundle/changelog.py
+++ b/debian_bundle/changelog.py
@@ -298,10 +298,12 @@ class Changelog(object):
self._parse_error('Empty changelog file.', strict)
return
-if file[-1] != '\n':
-file += '\n'
-file = file.split('\n')[:-1]
+file = file.splitlines()
for line in file:
+# Support both lists of lines without the trailing newline and
+# those with trailing newlines (e.g. when given a file object
+# directly)
+line = line.rstrip('\n')
if state == first_heading or state == next_heading_or_eof:
top_match = topline.match(line)
blank_match = blankline.match(line)
@@ -645,6 +647,17 @@ class ChangelogTests(unittest.TestCase):
self.assertEqual(c.full_version, '1.2.3')
self.assertEqual(str(c.version), c.full_version)
+def test_str_consistent(self):
+# The parsing of the changelog (including the string representation)
+# should be consistent whether we give a single string, a list of
+# lines, or a file object to the Changelog initializer
+cl_data = open('test_changelog').read()
+c1 = Changelog(open('test_changelog'))
+c2 = Changelog(cl_data)
+c3 = Changelog(cl_data.splitlines())
+for c in (c1, c2, c3):
+self.assertEqual(str(c), cl_data)
+
class VersionTests(unittest.TestCase):
def _test_version(self, full_version, epoch, upstream, debian):
Bug#539187: libgv-python: broken symlink /usr/lib/pyshared/python2.{4,5}/_gv.so
Package: libgv-python Version: 2.20.2-3+b4 Severity: grave Justification: renders package unusable I can't import the gv module: jswri...@callisto:~$ python Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gv Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.5/gv.py", line 7, in import _gv ImportError: No module named _gv Poking around: jswri...@callisto:~$ file /usr/lib/pyshared/python2.5/_gv.so /usr/lib/pyshared/python2.5/_gv.so: broken symbolic link to `../../python2.5/site-packages/libgv_python25.so' The symlink wasn't broken in version 2.20.2-3; I think the binNMU, which would have used a later version of python-support, broke it. I suspect the fix to #523033 might have caused it, but I'm assigning it to libgv-python for now just in case. :) Thanks, John Wright -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-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/bash Versions of packages libgv-python depends on: ii libc62.9-22 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-11 GCC support library ii libgraphviz4 2.20.2-3+b4 rich set of graph drawing tools ii libstdc++6 4.4.0-11The GNU Standard C++ Library v3 ii python 2.5.4-2 An interactive high-level object-o ii python-support 1.0.3 automated rebuilding support for P libgv-python recommends no packages. libgv-python 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#365349: Intermediate space requirements
On Fri, Jul 17, 2009 at 02:28:46PM +0200, Bastian Blank wrote: > Hi folks > > I did some checks on the intermediate space requirements, especially the > build directory and ccache dirs. The ability to use ccache is currently > the limiting factor to do the snapshots in the current fashion. All > checks are done with the default powerpc64 image. > > No debugging info: > - build directory: 300MiB > - ccache: 50MiB > Full debugging info > - build directory: >> 2GiB > - ccache: 400MiB > Only image debugging info: > - build directory: 1,6GiB > - ccache: 110MiB > > Building with full debugging would push the linux-2.6 package right on > top of the space requirements list by effectively using factor 10 of the > current space. I'm unsure if the normal buildd-infrastructure could hold > up to this. > > Building only the image with debugging information, which should be > enough for most usage, would be an option, as it only takes about factor > five.[1] Since we build so much of the kernel as modules, I think it's much better if we can provide debug info for modules as well. Going through the buildd's listed at db.debian.org, I didn't see many machines with less than 36 GiB of disk space. Yes, 2 GiB is quite a lot of space, but I don't see that it would overload the buildd infrastructure. Worst case, if there are buildds that don't have enough space to build the kernel, they could be configured not to take the linux-2.6 package, leaving it for buildds that do have the space. (Of course, this depends on at least one buildd per architecture having enough space.) > [1]: Even this would currently make it impossible to build snapshots in > the current setup, because the used machine have no additional free > space. Perhaps this can happen on Debian hardware as Lucas suggests? Even if not, I would be willing to donate disks if it meant we could have debug info for Debian kernels. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523925: fmit: no sound seems to be captured with ALSA input
On Sun, Jul 26, 2009 at 05:56:20PM +0200, Francesco Poli wrote: > On Wed, 22 Jul 2009 14:51:10 -0600 John Wright wrote: > > You mentioned before that you could hear sound from the line in through > > your speakers. Were you able to capture sound from another program like > > aplay or audacity? > > I haven't tried (yet). > I may see if I manage to capture sound with arecord (I think you meant > arecord, rather than aplay), but not any time soon: I will be busy > and/or away from my equipment for some time, unfortunately. > > I had time to perform tests some months ago, not now... :-( Oops, yes, I meant arecord. Sorry again for not getting on this months ago... > > In the "Capture" tab of alsamixer (navigate with the > > tab key), you may need to select an input channel to capture, using the > > space bar. > > My "Capture" settings are as follows: > > Front Mic Boost33<>33 > Mic Boost 33<>33 > IEC958 74<>74 > Capture72<>72 CAPTUR > Capture 1 72<>72 CAPTUR > Capture 2 72<>72 CAPTUR > Input Source [Front Mic] > Input Source 1 [Line] > Input Source 2 [Mic] That looks like it should work - the key is the CAPTUR indicator. > > If you can get other ALSA-aware programs to capture sound, but not FMIT, > > then we need to figure out what's different on your machine compared to > > mine. :) > > > > Again, sorry for the terribly late response. I hope this helps to > > resolve the issue. > > As explained above, I won't have much time to perform tests soon. > I hope to get back and investigate further on September, possibly. > > Please think about the issue in the meanwhile and make suggestions, if > you have some more ideas... When you get an opportunity, try to run arecord -f cd /tmp/capture.wav with the above mixer settings. If the resulting .wav has no data in it, then it's an alsa problem. But if it records fine, yet FMIT still doesn't work, then it's probably an FMIT issue. I can't reproduce the problem here, but I'll try to think of some other things to try. :-/ -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538723: python-apt: Please allow a way to get "raw" data for a tag
On Sun, Jul 26, 2009 at 06:10:39PM +0200, Julian Andres Klode wrote: > On Sun, Jul 26, 2009 at 05:18:01PM +0200, John Wright wrote: > > On Sun, Jul 26, 2009 at 05:04:34PM +0200, John Wright wrote: > > > Package: python-apt > > > Version: 0.7.11.0 > > > Severity: wishlist > > > Tags: patch > > > > > > There are times when it would be nice to get the raw data for a tag, > > > without any white space stripped off the front. For example, see > > > #538376, where we would like to know if the data started with a newline. > > > > > > I have attached a patch that adds a FindRaw method to TagSection. > > I'll add it as "find_raw()" in 0.7.92 (aka 0.8 Beta 1), which should > hit experimental a few days after the release of apt 0.7.22 (which > should happen within the next weeks). Great, thanks! Do you know when it might find its way into unstable? > > --- a/python/tag.cc > > +++ b/python/tag.cc > > + char *Default = 0; > > + if (PyArg_ParseTuple(Args,"s|z",&Name,&Default) == 0) > > + return 0; > By the way, Default should just be any Python object. There's no > need to restrict the user from passing what he wants to. Ah, that makes sense. But I just cut and pasted from the implementation of the Find method... -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538376: python-debian: debian_bundle parses some multilines fields inconsistantly
On Sun, Jul 26, 2009 at 03:06:58PM +0200, John Wright wrote:
> I really wish it were possible to ensure the apt_pkg parser gave the
> same results as the native parser, though. :(
Looks like we can actually do this, with a small patch to python-apt [1]
and the attached patch.
[1]: http://bugs.debian.org/538723
--
John Wright
commit a26b007a91c9723d33690e7e0b897c70c2006ee5
Author: John Wright
Date: Sun Jul 26 17:20:20 2009 +0200
Don't ignore leading newlines on field data with apt_pkg
This depends on the patch to python-apt in #538723 being accepted.
diff --git a/debian_bundle/deb822.py b/debian_bundle/deb822.py
index fb1ed7c..a5662af 100644
--- a/debian_bundle/deb822.py
+++ b/debian_bundle/deb822.py
@@ -37,6 +37,31 @@ import sys
import StringIO
import UserDict
+class TagSectionWrapper(object, UserDict.DictMixin):
+"""Wrap a TagSection object, using the FindRaw method instead of Find
+
+This allows us to pick which whitespace to strip off the beginning and end
+of the data, so we don't lose leading newlines.
+"""
+
+def __init__(self, parser):
+self.parser = parser
+
+def keys(self):
+return self.parser.keys()
+
+def __getitem__(self, key):
+s = self.parser.FindRaw(key)
+
+if s is None:
+raise KeyError(key)
+
+data = s.partition(':')[2]
+
+# Get rid of spaces and tabs after the :, but not newlines, and strip
+# off any newline at the end of the data.
+return data.lstrip(' \t').rstrip('\n')
+
class OrderedSet(object):
"""A set-like object that preserves order when iterating over it
@@ -242,16 +267,12 @@ class Deb822(Deb822Dict):
if _have_apt_pkg and use_apt_pkg and isinstance(sequence, file):
parser = apt_pkg.ParseTagFile(sequence)
+section = TagSectionWrapper(parser.Section)
while parser.Step() == 1:
if shared_storage:
-parsed = parser.Section
+parsed = section
else:
-# Since parser.Section doesn't have an items method, we
-# need to imitate that method here and make a Deb822Dict
-# from the result in order to preserve order.
-items = [(key, parser.Section[key])
- for key in parser.Section.keys()]
-parsed = Deb822Dict(items)
+parsed = Deb822Dict(section)
yield cls(fields=fields, _parsed=parsed)
else:
Bug#538723: python-apt: Please allow a way to get "raw" data for a tag
On Sun, Jul 26, 2009 at 05:04:34PM +0200, John Wright wrote:
> Package: python-apt
> Version: 0.7.11.0
> Severity: wishlist
> Tags: patch
>
> There are times when it would be nice to get the raw data for a tag,
> without any white space stripped off the front. For example, see
> #538376, where we would like to know if the data started with a newline.
>
> I have attached a patch that adds a FindRaw method to TagSection.
Whoops, I didn't actually attach the patch. Here it is.
--
John Wright
commit d1272e937729cb13b54ea2d2955692bceb078236
Author: John Wright
Date: Sun Jul 26 16:12:06 2009 +0200
Add a FindRaw method for TagSection objects
diff --git a/python/tag.cc b/python/tag.cc
index 217be29..6fe97ed 100644
--- a/python/tag.cc
+++ b/python/tag.cc
@@ -92,6 +92,29 @@ static PyObject *TagSecFind(PyObject *Self,PyObject *Args)
return PyString_FromStringAndSize(Start,Stop-Start);
}
+static char *doc_FindRaw = "FindRaw(Name) -> String/None";
+static PyObject *TagSecFindRaw(PyObject *Self,PyObject *Args)
+{
+ char *Name = 0;
+ char *Default = 0;
+ if (PyArg_ParseTuple(Args,"s|z",&Name,&Default) == 0)
+ return 0;
+
+ unsigned Pos;
+ if (GetCpp(Self).Find(Name,Pos) == false)
+ {
+ if (Default == 0)
+ Py_RETURN_NONE;
+ return PyString_FromString(Default);
+ }
+
+ const char *Start;
+ const char *Stop;
+ GetCpp(Self).Get(Start,Stop,Pos);
+
+ return PyString_FromStringAndSize(Start,Stop-Start);
+}
+
static char *doc_FindFlag = "FindFlag(Name) -> integer/none";
static PyObject *TagSecFindFlag(PyObject *Self,PyObject *Args)
{
@@ -355,6 +378,7 @@ static PyMethodDef TagSecMethods[] =
{
// Query
{"Find",TagSecFind,METH_VARARGS,doc_Find},
+ {"FindRaw",TagSecFindRaw,METH_VARARGS,doc_FindRaw},
{"FindFlag",TagSecFindFlag,METH_VARARGS,doc_FindFlag},
{"Bytes",TagSecBytes,METH_VARARGS,doc_Bytes},
Bug#538723: python-apt: Please allow a way to get "raw" data for a tag
Package: python-apt
Version: 0.7.11.0
Severity: wishlist
Tags: patch
There are times when it would be nice to get the raw data for a tag,
without any white space stripped off the front. For example, see
#538376, where we would like to know if the data started with a newline.
I have attached a patch that adds a FindRaw method to TagSection. It
uses the C++ Find(char *Name, unsigned &Pos) method to get the position
of the tag in the section, then the Get method, to get the start and
stop of the tag. The result is the whole tag, not just the bits after
the colon with whitespace removed. For example:
>>> f = open('/tmp/apt_pkg.tmp', 'w')
>>> f.write("""\
... Package: foo
... Bar:
... Baz
... """)
>>> f.close()
>>> import apt_pkg; apt_pkg.init()
>>> parser = apt_pkg.ParseTagFile(open('/tmp/apt_pkg.tmp'))
>>> parser.Step()
1
>>> parser.Section.FindRaw('Package')
'Package: foo\n'
>>> parser.Section.FindRaw('Bar')
'Bar:\n Baz'
This way, I can write a wrapper around TagSection that handles leading
whitespace differently than the default implementation, e.g.:
class TagSectionWrapper(object, UserDict.DictMixin):
"""Wrap a TagSection object, using the FindRaw method instead of Find
This allows us to pick which whitespace to strip off the beginning and
end
of the data, so we don't lose leading newlines.
"""
def __init__(self, parser):
self.parser = parser
def keys(self):
return self.parser.keys()
def __getitem__(self, key):
s = self.parser.FindRaw(key)
if s is None:
raise KeyError(key)
data = s.partition(':')[2]
# Get rid of spaces and tabs after the :, but not newlines, and
strip
# off any newline at the end of the data.
return data.lstrip(' \t').rstrip('\n')
Thanks for considering the patch.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538376: python-debian: debian_bundle parses some multilines fields inconsistantly
On Sun, Jul 26, 2009 at 12:34:47PM +0200, Stefano Zacchiroli wrote: > On Sat, Jul 25, 2009 at 07:38:57PM +0200, John Wright wrote: > > I'm actually inclined to turn off using apt_pkg by default. It's > > definitely faster, typically by a factor between 2 and 2.5, but we > > keep running into weird corner cases with the way apt_pkg parses > > things. > > > Clearly, using shared storage (which basically just means using > > apt_pkg's parser.Section directly) is blazingly fast compared to > > without. But this is aready not the default, since it has the > > confusing side-effect of making the object returned by each > > iteration (each of which has a different id) actually share the same > > data. > > > > Is anybody strongly opposed to making iter_paragraphs not use > > apt_pkg by default? I'm still trying to figure out a way to salvage > > the output from apt_pkg in this case, but I'm not having much luck. > > I'm not against changing the default. However, I'm against making it > difficult / undocumented how to use apt_pkg + shared storage. I do > care about runtimes but I want to retain the nice data structures of > deb822 nevertheless (i.e. please not make me use python-apt all > alone). > > What it might make sense then is to have different top level > functions, with one maybe marked "fast" and well documenting that it > has potential drawback. The other can safely be our, slower, default. I don't quite understand what you mean. Are you thinking of a method like deb822.Deb822.iter_paragraphs_fast(...), which is basically a wrapper around iter_paragraphs with use_apt_pkg=True and shared_storage=True? I wouldn't be opposed to something like that. Somehow, we just need to make it clear that using the "native" parser, which is slower than apt_pkg, is the only way to guarantee that modifying a Deb822 object and then dumping it back out will produce output consistent with the input. I really wish it were possible to ensure the apt_pkg parser gave the same results as the native parser, though. :( -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538375: libdw-dev: Please provide a static libdw library
Hi Kurt, On Sat, Jul 25, 2009 at 02:29:23PM +0200, Kurt Roeckx wrote: > On Sat, Jul 25, 2009 at 12:08:05PM +0200, John Wright wrote: > > I'm working on getting makedumpfile ready to upload to Debian. The > > upstream Makefile builds makedumpfile statically, so that it can be > > easily included in an initramfs. The only library it needs that isn't > > available statically now is libdw. I notice you removed the static > > library in version 0.141-1; would it be possible to bring it back? > > Note that libdw1 contains a whole bunch of shared libraries which > can be dynamicly loaded, and you probably need atleast one of > them. Upstream does not provide them staticly. > > I suggest you look at doing this with the shared version instead, > I don't see an advantage of doing it staticly. makedumpfile's purpose is to dump the memory of a crashed kernel (from a newly kexec'd "crash kernel"), ignoring user memory and pages of zeros. It's possible to do this after booting the crash kernel through a normal init process, but to avoid needing to pre-allocate a lot of memory for the crash kernel, it's better if makedumpfile can run in the initramfs. For that, we want a statically linked binary (or else we have to copy the libz, libelf, and libdw shared libraries also into the initramfs). It works just fine linked against libdw.a. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537758: Adopting trac-mercurial
Hi Christoph, On Sun, Jul 26, 2009 at 10:07:13AM +0200, Christoph Egger wrote: > owner 537758 ! > retitle 537758 ITA: trac-mercurial -- Mercurial version control backend for > Trac > kthxbye > > Hi! > > I'm using trac + mercurial + this plugin in production an plan > continuing to do so. Because of this I'll adopt this package and > (probably) to collab-maint. Great! I'm glad it will be getting the attention it deserves. :) -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538376: python-debian: debian_bundle parses some multilines fields inconsistantly
On Sat, Jul 25, 2009 at 05:02:16PM +0200, John Wright wrote:
> On Sat, Jul 25, 2009 at 02:05:26PM +0200, sean finney wrote:
> > severity 538376 normal
> > thanks
> >
> > okay i take back what i said about this being a regression, it seems that
> > in previous versions (< 0.1.10) it was treated as a plain text field (i.e.
> > no dictionary at all), which meant that the fields were probably ignored
> > entirely in the patch-tracker but are now partially showing up.
> >
> > still a bug though afaict :)
>
> Gah! This is apt_pkg's fault: it strips off the leading '\n'. This
> means our goal of having the output match the input will in general be
> broken when you use apt_pkg. (Right now, the only place that's used by
> default is when you use iter_paragraphs.)
>
> A temporary workaround is to pass use_apt_pkg=False to the
> iter_paragraphs method. On large files, you'll probably notice a bit of
> a performance hit. I'll see what we can do to preserve this information
> with apt_pkg.
I'm actually inclined to turn off using apt_pkg by default. It's
definitely faster, typically by a factor between 2 and 2.5, but we keep
running into weird corner cases with the way apt_pkg parses things.
Using sid's Sources and amd64 Packages files, calling the respective
class's iter_paragraph method with the specified kwargs and throwing
away the results, like
for d in cls.iter_paragraphs(f, **kwargs): pass
I get the following run times:
Packages, , {'use_apt_pkg': True}
0: 0:00:08.664978
1: 0:00:07.747378
2: 0:00:07.743156
3: 0:00:07.961919
4: 0:00:07.758220
Average: 0:00:07.975130
Packages, , {'use_apt_pkg': False}
0: 0:00:18.505047
1: 0:00:18.179216
2: 0:00:18.179558
3: 0:00:18.415705
4: 0:00:18.182857
Average: 0:00:18.292476
Sources, , {'use_apt_pkg': True}
0: 0:00:07.865666
1: 0:00:07.864537
2: 0:00:07.861713
3: 0:00:07.873949
4: 0:00:07.858093
Average: 0:00:07.864791
Sources, , {'use_apt_pkg': False}
0: 0:00:13.710405
1: 0:00:13.262080
2: 0:00:13.260217
3: 0:00:13.245185
4: 0:00:13.251963
Average: 0:00:13.345970
Packages, , {'use_apt_pkg': True}
0: 0:00:06.283796
1: 0:00:06.414739
2: 0:00:06.323466
3: 0:00:06.320447
4: 0:00:06.264290
Average: 0:00:06.321347
Packages, , {'use_apt_pkg': False}
0: 0:00:16.653596
1: 0:00:16.637927
2: 0:00:16.805496
3: 0:00:16.631162
4: 0:00:16.614459
Average: 0:00:16.668528
Packages, , {'use_apt_pkg': True,
'shared_storage': True}
0: 0:00:02.513985
1: 0:00:02.516300
2: 0:00:02.521496
3: 0:00:02.514919
4: 0:00:02.516548
Average: 0:00:02.516649
Clearly, using shared storage (which basically just means using
apt_pkg's parser.Section directly) is blazingly fast compared to
without. But this is aready not the default, since it has the confusing
side-effect of making the object returned by each iteration (each of
which has a different id) actually share the same data.
Is anybody strongly opposed to making iter_paragraphs not use apt_pkg by
default? I'm still trying to figure out a way to salvage the output
from apt_pkg in this case, but I'm not having much luck.
--
John Wright
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538376: Acknowledgement (python-debian: debian_bundle parses some multilines fields inconsistantly)
On Sat, Jul 25, 2009 at 02:05:26PM +0200, sean finney wrote: > severity 538376 normal > thanks > > okay i take back what i said about this being a regression, it seems that > in previous versions (< 0.1.10) it was treated as a plain text field (i.e. > no dictionary at all), which meant that the fields were probably ignored > entirely in the patch-tracker but are now partially showing up. > > still a bug though afaict :) Gah! This is apt_pkg's fault: it strips off the leading '\n'. This means our goal of having the output match the input will in general be broken when you use apt_pkg. (Right now, the only place that's used by default is when you use iter_paragraphs.) A temporary workaround is to pass use_apt_pkg=False to the iter_paragraphs method. On large files, you'll probably notice a bit of a performance hit. I'll see what we can do to preserve this information with apt_pkg. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538375: libdw-dev: Please provide a static libdw library
Package: libdw-dev Version: 0.141-2 Severity: wishlist Hello, I'm working on getting makedumpfile ready to upload to Debian. The upstream Makefile builds makedumpfile statically, so that it can be easily included in an initramfs. The only library it needs that isn't available statically now is libdw. I notice you removed the static library in version 0.141-1; would it be possible to bring it back? Thanks, -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538076: RFA: trac-mercurial -- Mercurial version control backend for Trac
Package: wnpp Severity: normal I hardly ever use Mercurial anymore, and Trac even less so. Thus, I haven't been giving this package the time it deserves. There's a Mercurial repository for it here: http://debian.johnwright.org/hg/trac-mercurial/ I would be willing to sponsor uploads if needed, and to work with the new maintainer on how I've been tracking upstream (which lives in Edgewall's Trac Subversion repository) and patching the source. Cheers, -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523925: fmit: no sound seems to be captured with ALSA input
Hi Fancesco, On Tue, Jul 07, 2009 at 12:36:11AM +0200, Francesco Poli wrote: > On Mon, 13 Apr 2009 19:11:33 +0200 Francesco Poli (t1000) wrote: > > [...] > > I am trying to see if it can tune my electric guitar (connected to > > the sound card mic-in through a DI box). > [...] > > Is this a bug or is there something else I can try to do in order > > to use FMIT with ALSA transport? > > > > Thanks for any help. > [...] > > May I have some sort of response, please? I'm sorry, I lost track of this bug, and I haven't had a machine with a working sound setup for a while. Unfortunately, this makes me a bit of a poor maintainer for a piece of audio software... Anyway, I finally got around to figuring out how the inputs on this machine are mapped to mixer channels, and FMIT works for me. You mentioned before that you could hear sound from the line in through your speakers. Were you able to capture sound from another program like aplay or audacity? In the "Capture" tab of alsamixer (navigate with the tab key), you may need to select an input channel to capture, using the space bar. If you can get other ALSA-aware programs to capture sound, but not FMIT, then we need to figure out what's different on your machine compared to mine. :) Again, sorry for the terribly late response. I hope this helps to resolve the issue. -- John Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365349: Add support for creating a "debuginfo" package
On Thu, Jul 16, 2009 at 09:21:50AM +0200, Bastian Blank wrote: > On Wed, Jul 15, 2009 at 11:31:49PM -0600, John Wright wrote: > > On Wed, Jul 15, 2009 at 08:36:27PM +0200, Bastian Blank wrote: > > > On Wed, Jul 15, 2009 at 10:45:23AM -0600, John Wright wrote: > > > > + +$(MAKE_CLEAN) -C $(DIR) modules_install > > > > INSTALL_MOD_PATH='$(CURDIR)'/$(PACKAGE_DIR) INSTALL_MOD_STRIP=1 > > > > + +$(MAKE_CLEAN) -C $(DIR) modules_install > > > > INSTALL_MOD_PATH='$(CURDIR)'/$(DEBUG_DIR) > > > > > > How about only installing debugging infos in the debugging package? > > > > THis would be ideal. Current tools like "crash" don't work with an > > image that's been stripped with "--only-keep-debug". I'm not sure what > > strip is removing that crash needs, but I'll look into it. > > This will not work on x86 because the bootable image is no elf file. Right, but the vmlinux that we'd provide in the debug package is: $ file /usr/lib/debug/vmlinux-2.6.29-3-amd64 /usr/lib/debug/vmlinux-2.6.29-3-amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped This is what I get from crash when I run it on the vmlinux I stripped with --only-keep-debug: $ sudo crash vmlinux-2.6.29-clim-3-amd64.stripped /dev/mem System.map-2.6.29-clim-3-amd64 crash 4.0-7.6 Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc. Copyright (C) 2004, 2005, 2006 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. crash: vmlinux-2.6.29-clim-3-amd64.stripped: no text and data contents crash: the use of a System.map file requires that the accompanying namelist argument is a kernel file built with the -g CFLAG. The namelist argument supplied in this case is a debuginfo file, which must be accompanied by the kernel file from which it was derived. So it looks like we can't use just the debuginfo in vmlinux with crash. But since it only saves 9 MB out of 69 MB in this case, that doesn't seem like a huge problem. > > Stripping the modules themselves with "--only-keep-debug" seems to work > > with crash, but then it saves only a marginal amount of space (from 963 > > MB down to 926 MB on a 2.6.29 kernel). > > Äh. What is the size of the resulting packages? 321 MB for the linux-image-2.6.29-2-amd64-dbg deb (which contains both the unstripped vmlinux and the unstripped modules). The 686 and mckinley flavours are within 15 MB of that size (both smaller); I haven't tried this on other architectures. It might be worthwhile to teach crash to use gzipped vmlinux and .ko files. I'm not sure if any other tool that uses these files has that capability either, though. Plus, people who would need to use the debug info for the kernel will probably have space available for that. -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365349: Add support for creating a "debuginfo" package
On Wed, Jul 15, 2009 at 08:36:27PM +0200, Bastian Blank wrote: > On Wed, Jul 15, 2009 at 10:45:23AM -0600, John Wright wrote: > > install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain: > > This is not the correct target. Can you elaborate? Do you mean it should go in its own target? > > + +$(MAKE_CLEAN) -C $(DIR) modules_install > > INSTALL_MOD_PATH='$(CURDIR)'/$(PACKAGE_DIR) INSTALL_MOD_STRIP=1 > > + +$(MAKE_CLEAN) -C $(DIR) modules_install > > INSTALL_MOD_PATH='$(CURDIR)'/$(DEBUG_DIR) > > How about only installing debugging infos in the debugging package? THis would be ideal. Current tools like "crash" don't work with an image that's been stripped with "--only-keep-debug". I'm not sure what strip is removing that crash needs, but I'll look into it. Stripping the modules themselves with "--only-keep-debug" seems to work with crash, but then it saves only a marginal amount of space (from 963 MB down to 926 MB on a 2.6.29 kernel). Similarly with the vmlinux: from 69 MB down to 60 MB. Maybe strip is just confused by something in the format of a kernel module? > > +Package: linux-ima...@upstreamversion@@abiname@@localvers...@-dbg > > +Section: admin > > +Priority: optional > > +Provides: linux-image-dbg, linux-ima...@major@-dbg, > > linux-modul...@upstreamversion@@abiname@@localvers...@-dbg > > +Pre-Depends: debconf (>= 0.2.17) | debconf-2.0 > > +Depends: module-init-tools (>= 0.9.13), coreutils (>= 5.2.1) > > Are your serious? Uhm, yes... Why should I not be? If you're worried about the virtual packages it provides, I'm not partial to them. If the patch needs improvement, I'm glad to improve on specific points, but I don't understand what you don't like about this section. -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365349: Add support for creating a "debuginfo" package
On Wed, Jul 15, 2009 at 10:45:23AM -0600, John Wright wrote: > tags 365349 + patch > thanks > > On Tue, Jul 14, 2009 at 11:45:29AM -0600, dann frazier wrote: > > On Tue, Jul 14, 2009 at 12:02:52PM -0400, Lucas Nussbaum wrote: > > > On 14/07/09 at 09:47 +0200, maximilian attems wrote: > > > > On Mon, 13 Jul 2009, Lucas Nussbaum wrote: > > > > > > > > > > What's the status on the addition of a "debuginfo" package in addition > > > > > to linux-image-*? Is it just waiting on someone to do the work, and is > > > > > it something that needs to be discussed first? > > > > > > > > yep, nobody dedicated time yet to linux-debug flavour. > > > > a good start would be x86 only. > > > > > > Why do you see this as a new flavor? Wouldn't it be better to have it > > > based on the standard flavor, splitting off the debug info after the > > > build? > > > > > > If I remember correctly, enabling such options has no performance impact > > > (and other distros are doing it too). > > > > fwiw, I'd like to see these too. Coworkers of mine have patches to do > > this within kernel-package but, by the time we got the k-p maintainer > > to serious look at them, linux-2.6 was migrating away from k-p. > > > > In addition to systemtap, it should also make it easier to get crash > > to work on released kernel images. > > I'm attaching a patch to linux-2.6 to build a -dbg kernel for each > flavor. > > The first patch just enables CONFIG_DEBUG_INFO and builds the -dbg > packages; the second patch should add the necessary bits for systemtap. Note that we'll need a similar patch for linux-modules-*-2.6, since without INSTALL_MOD_STRIP=1, any modules built against a kernel with CONFIG_DEBUG_INFO=y will have all debug symbols, which will make them rather large. I do think it would be worthwhile having -dbg packages for modules as well, though. I can supply this patch soon -- should I attach it here or open new bugs against linux-modules-extra-2.6 and friends? -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365349: Add support for creating a "debuginfo" package
tags 365349 + patch thanks On Tue, Jul 14, 2009 at 11:45:29AM -0600, dann frazier wrote: > On Tue, Jul 14, 2009 at 12:02:52PM -0400, Lucas Nussbaum wrote: > > On 14/07/09 at 09:47 +0200, maximilian attems wrote: > > > On Mon, 13 Jul 2009, Lucas Nussbaum wrote: > > > > > > > > What's the status on the addition of a "debuginfo" package in addition > > > > to linux-image-*? Is it just waiting on someone to do the work, and is > > > > it something that needs to be discussed first? > > > > > > yep, nobody dedicated time yet to linux-debug flavour. > > > a good start would be x86 only. > > > > Why do you see this as a new flavor? Wouldn't it be better to have it > > based on the standard flavor, splitting off the debug info after the > > build? > > > > If I remember correctly, enabling such options has no performance impact > > (and other distros are doing it too). > > fwiw, I'd like to see these too. Coworkers of mine have patches to do > this within kernel-package but, by the time we got the k-p maintainer > to serious look at them, linux-2.6 was migrating away from k-p. > > In addition to systemtap, it should also make it easier to get crash > to work on released kernel images. I'm attaching a patch to linux-2.6 to build a -dbg kernel for each flavor. The first patch just enables CONFIG_DEBUG_INFO and builds the -dbg packages; the second patch should add the necessary bits for systemtap. -- +--+ | John Wright | | HP Mission Critical OS Enablement & Solution Test (MOST) | +--+ >From d6d318ef1927c6e0688920e9c7218fcb1f437333 Mon Sep 17 00:00:00 2001 From: John Wright Date: Wed, 3 Jun 2009 14:57:19 -0600 Subject: [PATCH 1/2] Build debuggable kernel --- config/config |2 +- config/defines|2 +- rules.real| 23 --- templates/control.image.type-plain.in | 11 +++ 4 files changed, 29 insertions(+), 9 deletions(-) diff --git a/config/config b/config/config index 7e7f19e..3c3c0ee 100644 --- a/config/config +++ b/config/config @@ -2979,7 +2979,7 @@ CONFIG_TIMER_STATS=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y -# CONFIG_DEBUG_INFO is not set +CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set diff --git a/config/defines b/config/defines index 2790095..61f7429 100644 --- a/config/defines +++ b/config/defines @@ -1,5 +1,5 @@ [abi] -abiname: 1 +abiname: 2 ignore-changes: # kvm __kvm* kvm* emulate_instruction emulator_write_emulated fx_init gfn_to_hva gfn_to_memslot_unaliased gfn_to_page gfn_to_pfn load_pdptrs diff --git a/rules.real b/rules.real index 18d5bd7..4410f54 100644 --- a/rules.real +++ b/rules.real @@ -295,25 +295,34 @@ install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): REAL_VERSION = $(UPSTREA install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): PACKAGE_NAME = linux-image-$(REAL_VERSION) install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): PACKAGE_DIR = debian/$(PACKAGE_NAME) install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): INSTALL_DIR = $(PACKAGE_DIR)/boot +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): DEBUG_PACKAGE_NAME = linux-image-$(REAL_VERSION)-dbg +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): DEBUG_DIR = debian/$(DEBUG_PACKAGE_NAME)/usr/lib/debug/ install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): DIR = $(BUILD_DIR)/build_$(ARCH)_$(FEATURESET)_$(FLAVOUR) -install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): DH_OPTIONS = -p$(PACKAGE_NAME) +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): DH_OPTIONS = install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE): $(STAMPS_DIR)/build_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_$(TYPE) install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain: dh_testdir dh_testroot - dh_prep - dh_installdirs 'boot' + dh_prep -p$(PACKAGE_NAME) -p$(DEBUG_PACKAGE_NAME) + dh_installdirs -p$(PACKAGE_NAME) 'boot' + dh_installdirs -p$(DEBUG_PACKAGE_NAME) 'usr/lib/debug' +$(MAKE_SELF) \ install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image \ DIR='$(DIR)' PACKAGE_DIR='$(PACKAGE_DIR)' INSTALL_DIR='$(INSTALL_DIR)' REAL_VERSION='$(REAL_VERSION)' + install -m644 $(DIR)/vmlinux $(DEBUG_DIR)/vmlinux-$(REAL_VERSION) ifeq ($(MODULES),True) - +$(MAKE_CLEAN) -C $(DIR) modules_install INSTALL_MOD_PATH='$(CURDIR)'/$(PACKAGE_DIR) + +$(MAKE_CLEAN) -C $(DIR) modules_install INSTALL_MOD_PATH='$(CURDIR)'/$(PACKAGE_DIR) INSTALL_MOD_STRIP=1 + +$(MAKE_CLE
