Bug#766568: dpkg-genchanges(1) does not document -g
Package: dpkg-dev Version: 1.17.18 Severity: normal The new dpkg-buildpackage -g option can also be passed to dpkg-genchanges, but is not documented on its man page. This makes it hard to figure out that dpkg-buildpackage --changes-option=-g can be used. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files7.6 ii binutils 2.24.90.20141014-1 ii bzip2 1.0.6-7 ii libdpkg-perl 1.17.18 ii make 4.0-8 ii patch 2.7.1-6 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages dpkg-dev recommends: ii build-essential 11.7 ii fakeroot 1.20.2-1 ii gcc [c-compiler] 4:4.9.1-5 ii gcc-4.6 [c-compiler] 4.6.4-7 ii gcc-4.8 [c-compiler] 4.8.3-13 ii gcc-4.9 [c-compiler] 4.9.1-18 ii gnupg1.4.18-4 ii gnupg2 2.0.26-3 ii gpgv 1.4.18-4 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2014.08.31 -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#756975: dpkg-genchanges option to only include arch:all debs
Guillem Jover wrote: > But, this has a nice side-effect, you can also do something like: > > $ dpkg-buildpackage --changes-option=-g > > which will perform a normal full build, but filter the generated > .changes file to only include source+arch-indep packages. Which I > think is what you'd be looking for? Yes, this is perfect, aside from being a handful to type for the current DAK case. -- see shy jo signature.asc Description: Digital signature
Bug#756975: dpkg-genchanges option to only include arch:all debs
Raphael Hertzog wrote: > Funnily this can already be done with “dpkg-buildpackage > --changes-option=-S” but it will generate a _.changes file > that list only the source package (that's because the filename > is decided by dpkg-buildpackage while the content comes from > dpkg-genchanges). Hmm, so it can. The name of the change file does not matter, at least according to <87zjfl46kd@deep-thought.43-1.org> -- see shy jo signature.asc Description: Digital signature
Bug#756975: dpkg-genchanges option to only include arch:all debs
Guillem Jover wrote: > Hmm, I had already pondered about this when I saw the announcement. So, > while I agree such option would make life easier for people that want > to do “almost-source-only uploads” right now (because TBH the other > alternatives are very annoying), on first thought this seemed to be a > very non-generic and DAK specific option, and less useful if this is > going to be a short temporary situation. > > But then there's (AFAICS) only two missing combinations in the tools, > source+arch-dep and source+arch-indep, so I guess if I add both, then > it keeps being quite generic. :) > > I'll try to include this for 1.17.11, which I'm planning to release > RSN. An added wrinkle is that -S doesn't build arch specific debs at all, of course, but a responsible user of this new DAK feature will want to build debs, lintian and test the locally, but not upload them. I think this calls for more than a generic filling in of the complements to -S. It's fine to add those options to dpkg-genchanges, but dpkg-buildpackage would be improved by an option that built everything, and then told dpkg-genchanges to only put source and arch:all in the changes. -- see shy jo signature.asc Description: Digital signature
Bug#756975: dpkg-genchanges option to only include arch:all debs
Package: dpkg-dev Version: 1.17.10 Severity: wishlist Now that the archive supports source-only uploads, with the exception that arch:all debs have to still be uploaded (as no autobuilder is responsible for them), dpkg-genchanges -S is useful, but not quite right. It would be good to have an option that is like -S but includes arch:all debs, until such a time as the archive stops needing them. Perhaps --minimal? -- see shy jo signature.asc Description: Digital signature
Bug#720598: remove 3.0 (git)
Guillem Jover wrote: > While it's true the format is not being used in Debian, that dgit might > obsolete it there too, that it might have been a mistake to add the git > and bzr formats to dpkg and that the formats are marked as experimental, > I'd be slightly uncomfortable removing them from dpkg, as dpkg is being > used in places other than Debian. It also makes it harder to extract > possible historic packages. I'll ponder about this for a bit, but > given that they are tiny codewise I might just keep them, we'll see. I appreciate the caution. I think there is no reason to continue to support making them. Could continue to support extracting them. -- see shy jo signature.asc Description: Digital signature
Bug#720598: remove 3.0 (git)
Package: dpkg-dev Version: 1.17.1 Severity: minor dgit obsoletes the 3.0 (git) source format, which is unused anyway. Please remove it. -- see shy jo signature.asc Description: Digital signature
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Nicholas Bamber wrote: > Techincally the shell script > fragments incorporated into Debian maintance scripts by debhelper may > fall into this category For code that is licensed like so? Redistribution and use in source and binary forms, with or without modification, are permitted under any circumstances. No warranty. Give me a break. -- see shy jo signature.asc Description: Digital signature
Bug#560070: Fix for #560070 broken by debhelper 8.9.4
Modestas Vainius wrote: > I don't think it is a fair statement. Examples of minimal dh rules all over > the place in your blog, debhelper package and dh manual page DO NOT have > build > flags handling. It is true that it's the result of inappropriate dpkg- > buildpackage behaviour but it's still a bad practise pushed debhelper from > the > advent of dh so you should feel at least a bit responsible. This has nothing to do with dh. No example rules file *ever* shipped with debhelper has included build flag handling. Contrary to popular belief, most packages get this right without having flags forced. (The only exception to this is noopt handling, which could still be enabled outside v9 mode.) -- see shy jo signature.asc Description: Digital signature
Bug#560070: Fix for #560070 broken by debhelper 8.9.4
Raphael Hertzog wrote: > Joey, once the new dpkg is in unstable, can we revert this and get the > packages fixed to use the proper dpkg-buildflags interface to adjust > the flags to avoid the failure? > > Because in my opinion, it's much more important to have a wide usage of > dpkg-buildflags. You don't know how many packages are broken or no longer > policy compliant because they were relying on those environment > variables... If you don't know that, then you cannot turn of dpkg-buildpackage's use of dpkg-buildflags. I and others have repeatedly told you that is probably the case. -- see shy jo signature.asc Description: Digital signature
Bug#560070: Fix for #560070 broken by debhelper 8.9.4
Sven Joachim wrote: > Hi folks, > > with this change from dpkg-dev git: > > , > | * dpkg-buildpackage no longer exports the compiler flags. Closes: #560070 > | Packages must directly call dpkg-buildflags to retrieve them. > ` > > and the following from debhelper 8.9.4: > > , > | * dpkg-buildflags is only used to set environment in v9, to avoid > | re-breaking packages that were already broken a first time by > | dpkg-buildpackage unconditionally setting the environment, and > | worked around that by unsetting variables in the rules file. > | (Example: numpy) > ` > > , compiler flags are not set at all for packages using dh-style rules > files, unless those packages are upgraded to debhelper compatibility > level 9. That does not seem to be an acceptable outcome. It's Not My Problem. Build flags are also not set for packages not using dh. -- see shy jo signature.asc Description: Digital signature
Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy
Raphael Hertzog wrote: > Please reconsider. I think it's been well explained that version numbers > ought to start with a "number". Where? Also, f is a number around here. Example breakage includes the bitlbee bzr snapshots, which many stable users of bitlbee were probably using. -- see shy jo signature.asc Description: Digital signature
Bug#605719: dpkg-mergechangelogs complains about "urgency=low"
Sven Joachim wrote: > No, it does not like the trailing space after "urgency=low" in the 2.50 > entry. I see. dpkg-parsechangelog has no problem with trailing space, so maybe dpkg-mergechangelog should also be less strict. (dropping severity to minor) -- see shy jo signature.asc Description: Digital signature
Bug#605719: dpkg-mergechangelogs complains about "urgency=low"
Package: dpkg-dev Version: 1.15.8.6 Severity: normal File: /usr/bin/dpkg-mergechangelogs j...@gnu:~/src/tasksel>git stash apply dpkg-mergechangelogs: warning: .merge_file_qmEqOI(l1365): bad key-value after `;': `urgency=low ' LINE: tasksel (2.50) unstable; urgency=low dpkg-mergechangelogs: warning: .merge_file_QUd3Nf(l1366): bad key-value after `;': `urgency=low ' LINE: tasksel (2.50) unstable; urgency=low dpkg-mergechangelogs: warning: .merge_file_4ONINM(l1369): bad key-value after `;': `urgency=low ' LINE: tasksel (2.50) unstable; urgency=low Auto-merging debian/changelog CONFLICT (content): Merge conflict in debian/changelog The changelog started with this: tasksel (2.87) UNRELEASED; urgency=low Perhaps it's really choking on the UNRELEASED? -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files5.10 Debian base system miscellaneous f ii binutils 2.20.1-15 The GNU assembler, linker and bina ii bzip2 1.0.5-6high-quality block-sorting file co ii libdpkg-perl 1.15.8.6 Dpkg perl modules ii make 3.81-8 An utility for Directing compilati ii patch 2.6-3 Apply a diff file to an original ii xz-utils 5.0.0-2XZ-format compression utilities Versions of packages dpkg-dev recommends: ii build-essential 11.5 Informational list of build-essent ii fakeroot 1.14.4-1 Gives a fake root environment ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.5-4The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.5-8The GNU C compiler ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii gpgv 1.4.10-4 GNU privacy guard - signature veri ii libalgorithm-merge-perl 0.08-2 Perl module for three-way merge of ii tcc [c-compiler] 0.9.25-5 the smallest ANSI C compiler Versions of packages dpkg-dev suggests: ii debian-keyring2010.08.01 GnuPG (and obsolete PGP) keys of D -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#597340: dpkg-gencontrol: implicit substvar at the end of every field
Raphaël Hertzog wrote:
> dpkg-gencontrol could be modified to always append the value of
> ${implicit:} at the end of the corresponding field.
Note this would mean that for depends fields, the content of the
substvar would need to start with ", ".
> CCing -devel and Joey Hess to have some input on this idea. Do you think
> it would be useful ? Do you have comments and suggestions ?
It seems like a good idea, it would reduce clutter if misc:Depends did
not need to be manually listed. I don't know if debhelper's perl:Depends
and python:Depends could be sanely made implicit.
--
see shy jo
signature.asc
Description: Digital signature
Bug#582819: dpkg-maintscript-helper package version optional?
Raphael Hertzog wrote: > > * If doing as the man page suggests and avoiding a pre-depends > > by testing dpkg-maintscript-helper supports. > > Here you'd presumably still want to let the action happen > > in a later upgrade if the old conffile is still present. > > (At least when removing an old conffile.. doing that when > > renaming a conffile is probably unsafe.) > > What exactly do you fear when renaming a conffile? The scenario I envision is a package upgrade that moves a conffile, but also changes it. Suppose the new version is needed to avoid breakage. There is no pre-depends on dpkg. The preinst does not run dpkg-maintscript-helper, because a new enough dpkg is not installed yet. Then dpkg is upgraded, and then the postinst runs (a low proability, but possible scenario w/o a pre-depends). So the postinst will run dpkg-maintscript-helper without prepare_mv_conffile having had a chance to check the old conffile md5sum and move unmodified ones out of the way. So finish_mv_conffile will move the old, unmodified conffile into the new location. The new conffile will be left as .dpkg-new. Does the user see a modified conffile prompt at this point? I haven't checked. Real culprit here is the avoiding of the pre-depends which allows the postinst to run it despite the preinst not. The version check may make the scenario less likely to occur. > > * In debhelper, which needs to move conffiles sometimes, and doesn't > > have package version information available. > > I hope you will provide a way for the maintainer to supply the required > version. This is difficult to do in both cases where debhelper has needed to move conffiles before. -- see shy jo signature.asc Description: Digital signature
Bug#582921: dpkg-mergechangelogs needs a --merge-unreleased
Package: dpkg-dev Version: 1.15.7.2 Severity: wishlist --merge-prereleases is nice, but requires a) Everyone used the same base version number. There are many ways that can not happen, maybe someone thinks the next version will be 1.1 and someone else 1.0.1. Or maybe the version is date-based. b) Using ~exp* in the version number. There's another way to tell that two different versioned changelog entries are both unreleased and equivilant for merging, and that is to look for UNRELEASED in the distribution field, as put there by dch. I suggest either adding a --merge-unreleased that uses that, or extending --merge-prereleases to also merge such entries. -- see shy jo signature.asc Description: Digital signature
Bug#582819: dpkg-maintscript-helper package version optional?
Package: dpkg Version: 1.15.7.2 Severity: normal It's not clear from dpkg-maintscript-helper(1) if the package version is optional. Omitting the package version can be useful: * If doing as the man page suggests and avoiding a pre-depends by testing dpkg-maintscript-helper supports. Here you'd presumably still want to let the action happen in a later upgrade if the old conffile is still present. (At least when removing an old conffile.. doing that when renaming a conffile is probably unsafe.) * In debhelper, which needs to move conffiles sometimes, and doesn't have package version information available. Based on my reading of dpkg-maintscript-helper, if a version of "" is specified, since it uses le-nl to compare versions, it will always run the action, and should handle these cases. I'd like to see that documented, or at least signed off on, before I start using it though. -- see shy jo signature.asc Description: Digital signature
Bug#582814: dpkg-maintscript-helper: can't shift that many
Package: dpkg Version: 1.15.7.2 Severity: minor When run without a parameter, dpkg-maintscript-helper fails trying to shift away parameters that do not exist. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 8.5-1 GNU core utilities ii libbz2-1.01.0.5-4high-quality block-sorting file co ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libselinux1 2.0.94-1 SELinux runtime shared libraries ii xz-utils 4.999.9beta+20100307-1 XZ-format compression utilities ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.25.3 Advanced front-end for dpkg -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#575891: btrfs issues
cwillu wrote: > New information on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 > > Turns out to have been an unsafe assumption on dpkg's part with > apparently astronomic odds of being triggered on most filesystems. > > Putting /var/lib/dpkg on an ext3 mount (I used a bind mount from my > /boot) works around it until the problem can be fixed in dpkg. Cwillu, thanks for following up. That does seem to explain #569058, closing that bug. At the moment, my other two problems, #567135 and #568908, do not seem likely to be caused by the dpkg bug. -- see shy jo signature.asc Description: Digital signature
Bug#551323: dpkg-repack: eats an epoch from version number in the name of result file
Eugene V. Lyubimkin wrote: > They are important. Unless .deb have a "canonical" name, I cannot use packed > .debs as cached archives to install with cupt/apt. apt web-escapes various characters, including the : in an epoch, so you would have to modify filenames even if the epoch was included. (Anyway, I was referring to the bug report priority, which does not meet policy's definition of important.) > > This is done by dpkg-deb when building any package with an epoch in any > > way. Epochs are not intended to be user-visible. > > > This is news for me. Where can I find the source of this statement? dpkg 1.2.0: * Epochs in version numbers implemented, using the syntax :-. (Epoch not usually displayed.) Although they eventually changed this policy, see #107449. So perhaps they'd be willing to change dpkg-deb to include epochs now if asked. > Anyway, I need the way the rename the target file to the name I want to have. > As I understand, the best I can do is guess the target .deb name by package > name, right? I.e. no option where I can specify the target name myself? apt determines the filenames for its cache using the package name and version, AFAIK. -- see shy jo signature.asc Description: Digital signature
Bug#514316: the files in /etc/modprobe.d/
I'd forgotten that I submitted a patch to dpkg over a year ago to add a
dpkg-conffile(8) utility.
Note that the code on the wiki has changed slightly to handle a couple
of cases since I wrote dpkg-conffile last year. The wiki version puts a
space after $CONFFILE here to work around a bug:
old_md5sum="`dpkg-query -W -f='${Conffiles}' $PKGNAME | sed -n
-e \"' $CONFFILE '{s/ obsolete$//;s/.* //p}\"`"
I don't understand why some are talking about shell libraries. As the
author of probably the most commonly used shell library in Debian
(confmodule.sh), I can tell you that they are a *very* bad idea
for forward maintainability. They're also a PITA to access from
maintainer scripts that are not written in shell.
dpkg-conffile(8) has no more business being a shell library than do
dpkg-divert(8) or update-alternatives(8).
I really hope that this doesn't degenerate into bikeshedding, and that the
current slow-motion cut-n-paste train wreck is averted. The best way
to avoid both pitfalls is to put the current best practice code for managing
conffiles into a single place, immediatly. If dpkg's handling of conffile
delete/rename is significantly improved afterwards, you will then have
one place to change or deprecate.
--
see shy jo
signature.asc
Description: Digital signature
Bug#515540: ignores .swp, but not .swo, etc
Raphael Hertzog wrote: > I can add .swo but I don't think it's safe/interesting to ignore .sw[a-p]. > Is that enough for you? > Flash file are .swf for examples and it would be annoying to lose them > because we were too generous in the default ignore list. Is it not possible to ignore `.*.sw?` while not ignoring `*.sw?` I'm not sure because the current code seems to ignore `*.swp` for tar, rather than only ignoring the dotfiles. -- see shy jo signature.asc Description: Digital signature
Bug#515540: ignores .swp, but not .swo, etc
Package: dpkg-dev Version: 1.14.25 Severity: minor The default ignores includes vi .swp files, but vim will also create .swo, .swn, etc if the same file is being edited by two or more vims at once. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.28-1-686 (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 dpkg-dev depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii bzip2 1.0.5-1 high-quality block-sorting file co ii cpio2.9-14 GNU cpio -- a program to manage ar ii dpkg1.14.25 Debian package management system ii libtimedate-perl1.1600-9 Time and date functions for Perl ii lzma4.43-14 Compression method of 7z format in ii make3.81-5 The GNU version of the "make" util ii patch 2.5.9-5 Apply a diff file to an original ii perl [perl5]5.10.0-19Larry Wall's Practical Extraction ii perl-modules5.10.0-19Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii gcc [c-compiler] 4:4.3.2-3 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-25 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.3-3The GNU C compiler Versions of packages dpkg-dev suggests: ii debian-keyring2009.01.18 GnuPG (and obsolete PGP) keys of D ii gnupg 1.4.9-3GNU privacy guard - a free PGP rep -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#484669: trigger processing runs too often
Raphael Hertzog wrote: > Package: dpkg > Version: 1.14.19 > Severity: wishlist > > On Wed, 04 Jun 2008, Joey Hess wrote: > > The triggered script is called once at the end of the dpkg run, and once > > after the set of changed packages are unpacked. (I'm not sure why the > > latter call happens.) > > We should investigate this and document the reason if there's any. > Otherwise we should make dpkg smarter. > > Did you observe this while using apt or while directly using dpkg -i > and/or dpkg --unpack? I've seen it when using dpkg alone. But I think it's just due to the package triggering update-menus in its postinst. If so, dpkg would have to defer file triggers until after the postinst to avoid this. Fixing apt to defer all triggers to the end of course fixes it to. -- see shy jo signature.asc Description: Digital signature
Bug#478925: parsechangelog fails on changelogs with trailing data
Package: dpkg-dev Version: 1.14.18 Severity: normal parsechangelog/debian: warning: debian/changelog(l7): badly formatted heading line LINE: - New upstream release parsechangelog/debian: warning: debian/changelog(l8): badly formatted heading line LINE: - Removed PPDs for the Xerox Paser 6100, they are provided from upstream now parsechangelog/debian: warning: debian/changelog(l9): badly formatted heading line LINE: - Added CUPS DDK to the BuildRequires. It is easier and better to rebuild the parsechangelog/debian: warning: debian/changelog(l10): found change data where expected next heading or eof LINE: PPDs than introducing new workarounds to not rebuild them with each new Can't locate object method "init" via package "Dpkg::Changelog::Entry" at /usr/share/perl5/Dpkg/Changelog/Debian.pm line 259, line 10. dpkg-parsechangelog: failure: changelog parser /usr/lib/dpkg/parsechangelog/debian gave error exit status 9 dpkg-parsechangelog should robustly handle changelog files that contain trailing data not in changelog format after some correctly formatted entries. And it used to, until recently.. This has broken alien, which appends the rpm changelog, generating a changelog file like this: splix (1.1.1-2) experimental; urgency=low * Converted from .rpm format to .deb by alien version 8.71 -- Joey Hess <[EMAIL PROTECTED]> Thu, 01 May 2008 15:00:54 -0400 - New upstream release - Removed PPDs for the Xerox Paser 6100, they are provided from upstream now - Added CUPS DDK to the BuildRequires. It is easier and better to rebuild the PPDs than introducing new workarounds to not rebuild them with each new upstream release. - Updated for building LSB-3.2 packages. The particular trailing lines that seem to make dpkg-parsechangelog crash are the two starting with spaces. Because its parser doesn't check to see if it's actually within a changelog entry before trying to add indented lines to it. Also, since historically, Debian packages with changelogs that predate the "new" changelog format simply left the old changelog entries alone and prepended entries in the new format to the top, this also causes ugliness, and potentially crashes, with packages that still have old changelog format entries in their changelog. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina ii bzip2 1.0.5-0.1high-quality block-sorting file co ii cpio2.9-13 GNU cpio -- a program to manage ar ii dpkg1.14.18 package maintenance system for Deb ii libtimedate-perl1.1600-9 Time and date functions for Perl ii lzma4.43-12 Compression method of 7z format in ii make3.81-4 The GNU version of the "make" util ii patch 2.5.9-5 Apply a diff file to an original ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction ii perl-modules5.8.8-12 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.3 informational list of build-essent ii gcc [c-compiler] 4:4.2.3-8 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.3-3The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.0-3The GNU C compiler -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#476138: exporting CFLAGS causes packages to FTBFS
Package: dpkg-dev Version: 1.14.18 Severity: normal dpkg-buildpackage exporting CFLAGS can cause packages to FTBFS. See for example #475979. In this case the package consists of a top-level makefile, that runs a makefile in a subdirectory. The toplevel makefile sets CFLAGS to some value, but does not expect the makefile in the subdirectory to see it. If CFLAGS is exported though, the makefile in the subdirectory will see the value exported from toplevel, and in this case, fail to build. This doesn't stike me as a goods change to have made if you want to get the current version of dpkg into testing for the release. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils2.18.1~cvs20080103-3 The GNU assembler, linker and bina ii bzip2 1.0.5-0.1high-quality block-sorting file co ii cpio2.9-13 GNU cpio -- a program to manage ar ii dpkg1.14.18 package maintenance system for Deb ii libtimedate-perl1.1600-9 Time and date functions for Perl ii lzma4.43-12 Compression method of 7z format in ii make3.81-4 The GNU version of the "make" util ii patch 2.5.9-4 Apply a diff file to an original ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction ii perl-modules5.8.8-12 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.3 informational list of build-essent ii gcc [c-compiler] 4:4.2.3-7 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.3-3The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.0-3The GNU C compiler -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#473449: please include doc/triggers.txt from source
Package: dpkg-dev Version: 1.14.18 Severity: normal The trigger documentation should be included. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-3 The GNU core utilities ii libc6 2.7-9 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#471669: dpkg: Keeps retrying after package configuration failure
Hmm, on -user there have been some (detail-less) complaints lately of dpkg apparently looping. http://lists.debian.org/debian-user/2008/03/msg01417.html ISTR another bug can't find it in the archives. -- see shy jo signature.asc Description: Digital signature
Bug#452806: [debchange] dch -a shouldn't modify existing entries
Adam D. Barratt wrote: > reassign 452806 dpkg > retitle 452806 [dpkg-parsechangelog] Please maintain trailing whitespace > kthxbye > > Hi, > > On Sun, 2007-11-25 at 11:41 +0100, Josselin Mouette wrote: > > Package: devscripts > > Version: 2.10.10 > > Severity: normal > > File: /usr/bin/dch > > > > When "dch -a" is called, it strips any whitespace at the end of lines in > > the existing changelog entries. > > > > This is very annoying for team-maintained packages, especially combined > > to debcommit which then considers these lines as having changed and adds > > them to the commit message. > > debchange simply parses the output of dpkg-parsechangelog(1) in order to > derive the changes. dpkg-pc is stripping the whitespace before debchange > begins processing it; I'm therefore reassigning the bug. Fine, but debcommit should use diff -w .. -- see shy jo signature.asc Description: Digital signature
Bug#464907: dpkg seems not to check for broken versioned dependencies when upgrading
> I haven't checked, but this sounds very similar to #20471. There's a patch > in that bug. If you can take some time to verify if it also fixes this > issue, it would be nice. I applied this patch on top of current git master (rev 98cdd8883f0661e24ff72d4c29d73554586eddf8), and have been using it today while doing whatever, and it seemed to cause this failure: [EMAIL PROTECTED]:/home/joey/tmp/xterm-231>dpkg -i ../xterm_231-2boldmode1_i386.deb dpkg: ../../src/depcon.c:218: depisok: Assertion `dep->type == dep_depends || dep->type == dep_predepends || dep->type == dep_breaks || dep->type == dep_conflicts || dep->type == dep_recommends || dep->type == dep_suggests || dep->type == dep_enhances' failed. Other packages installed ok; I was able to downgrade to unstable's dpkg and then install xterm successfully. Here's the package's header, just in case: Package: xterm Version: 231-2boldmode1 Architecture: i386 Maintainer: Debian X Strike Force <[EMAIL PROTECTED]> Installed-Size: 1108 Depends: libc6 (>= 2.7-1), libfontconfig1 (>= 2.4.0), libice6 (>= 1:1.0.0), libncurses5 (>= 5.6+20071006-3), libsm6, libx11-6, libxaw7, libxext6, libxft2 (>> 2.1.1), libxmu6, libxt6, xbitmaps Recommends: xutils Suggests: xfonts-cyrillic Provides: x-terminal-emulator Section: x11 Priority: optional -- see shy jo signature.asc Description: Digital signature
Bug#464907: dpkg seems not to check for broken versioned dependencies when upgrading
Raphael Hertzog wrote: > I haven't checked, but this sounds very similar to #20471. There's a patch > in that bug. If you can take some time to verify if it also fixes this > issue, it would be nice. I tried 0001-Check-dependencies-_on_-the-package-we-re-to-upgrade.patch : [EMAIL PROTECTED]:~joey/lib/debian/unstable>dpkg -i fbreader_0.8.14-1_i386.deb libzltext_0.8.14-1_i386.deb libzlcore_0.8.14-1_i386.deb (Reading database ... 173289 files and directories currently installed.) Preparing to replace fbreader 0.8.13-1 (using fbreader_0.8.14-1_i386.deb) ... Unpacking replacement fbreader ... Preparing to replace libzltext 0.8.13-1 (using libzltext_0.8.14-1_i386.deb) ... Unpacking replacement libzltext ... dpkg: libzlcore_0.8.14-1_i386.deb containing libzlcore breaks existing dependency: libzlui-gtk depends on libzlcore (= 0.8.13-1) libzlcore is to be installed, but is version 0.8.14-1. dpkg: error processing libzlcore_0.8.14-1_i386.deb (--install): existing dependency problem - not installing libzlcore dpkg: dependency problems prevent configuration of fbreader: fbreader depends on libzlcore (>= 0.8.14); however: Version of libzlcore on system is 0.8.13-1. dpkg: error processing fbreader (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libzltext: libzltext depends on libzlcore (= 0.8.14-1); however: Version of libzlcore on system is 0.8.13-1. dpkg: error processing libzltext (--install): dependency problems - leaving unconfigured Errors were encountered while processing: libzlcore_0.8.14-1_i386.deb fbreader libzltext zsh: exit 1 dpkg -i fbreader_0.8.14-1_i386.deb libzltext_0.8.14-1_i386.deb Which looks perfect. -- see shy jo signature.asc Description: Digital signature
Bug#464907: dpkg seems not to check for broken versioned dependencies when upgrading
Package: dpkg Version: 1.14.16.6 Severity: normal libzlui-gtk depends on libzlcore (= 0.8.12-3). I have both installed. If I tell dpkg to upgrade to a new 0.8.13 version of libzlcore, it does so, leaving libzlui-gtk with a broken dependency. At no point does dpkg complain about that dependency being broken. [EMAIL PROTECTED]:/home/joey/src/packages/fbreader>dpkg -i ../fbreader_0.8.13-1_i386.deb ../libzltext_0.8.13-1_i386.deb ../libzlcore_0.8.13-1_i386.deb (Reading database ... 172424 files and directories currently installed.) Preparing to replace fbreader 0.8.13-1 (using ../fbreader_0.8.13-1_i386.deb) ... Unpacking replacement fbreader ... Preparing to replace libzltext 0.8.12-3 (using ../libzltext_0.8.13-1_i386.deb) ... Unpacking replacement libzltext ... Preparing to replace libzlcore 0.8.12-3 (using ../libzlcore_0.8.13-1_i386.deb) ... Unpacking replacement libzlcore ... Setting up libzlcore (0.8.13-1) ... Setting up libzltext (0.8.13-1) ... Setting up fbreader (0.8.13-1) ... [EMAIL PROTECTED]:/home/joey/src/packages/fbreader>dpkg -s libzlui-gtk Package: libzlui-gtk Status: install ok installed Priority: optional Section: libs Installed-Size: 220 Maintainer: Joey Hess <[EMAIL PROTECTED]> Architecture: i386 Source: fbreader Version: 0.8.12-3 Provides: libzlui Depends: libatk1.0-0 (>= 1.20.0), libbz2-1.0, libc6 (>= 2.7-1), libcairo2 (>= 1.4.0), libexpat1 (>= 1.95.8), libgcc1, libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.12.0), libjpeg62, libpango1.0-0 (>= 1.18.4), libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.1.1-21), libzlcore (= 0.8.12-3), zlib1g -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-3 The GNU core utilities ii libc6 2.7-6 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#461327: important priority too high for dselect
Raphael Hertzog wrote: > We have changed that to "optional" in the git repo. Did you also open a > bug on ftpmaster's side? No, it seemed better to let the dpkg maintainers decide if I was right and handle replying to the override messages as usual. -- see shy jo signature.asc Description: Digital signature
Bug#461327: important priority too high for dselect
Package: dselect Version: 1.14.7 Severity: normal Tags: d-i dselect's priority was recently dropped from required to important (#452652), but important is still a much-inflated priority (so is standard -- optional would be ok). dselect is not the kind of core unix tool that policy defines as candidates for important. It made sense for dselect to be required priority when it was widely used to install and upgrade systems (in the early ninties). It made no sense to drop it from required to important now that it does not. I don't expect removal of dselect from important to be contoversial, although someone is sure to pipe up and say "but I use dselect!" :-) Boring statistical justification follows just in case: Rough reading of the nunbers from dselect's popcon graph suggests that fewer than 1 in 10 systems with dselect installed actually regularly use it. Aptitude is used by roughly twice as many systems, as is synaptic, and apt is regularly used by 6/7ths of all systems. Moreover, while the number of popcon submissions has tripled since the release of etch, and the number users of the other package managers has similarly spiked, the number of systems using dselect has remained flat. http://people.debian.org/~igloo/popcon-graphs/index.php?packages=dselect+aptitude+apt+synaptic+kpackage&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=2007-04-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 So most people who use dselect already had it installed before etch was released, and the majority of new installs are unnecessarily installing dselect. While we couldn't fix that for etch, due to the dpkg depenency, we can fix it for lenny, and the best time to fix it would be now. -- see shy jo signature.asc Description: Digital signature
Bug#452273: dpkg-gencontrol: incorrect warning "deb package with udeb specific field Installer-Menu-Item"
Guillem Jover wrote: > Well then there's also the argument that there's no point in having it > in the source control either, it could be inferred from the section. > But those seem quite weak and specific ways to do so. Determining a file's type from its extension is "weak and specific"? Tell that to /var/lib/dpkg/info/*.p*. Tell that to everyone who has run dpkg -i *.deb and managed to not accidentially dpkg -i *.a (both ar files after all). > Anyway, I don't think that'd be clean, and we might want to use that > field for other package types in the future (translation debs, or > debugging debs come to mind). You're designing for use cases that are not yet clear, and ignoring the current use case. > I mentioned I'd implement it that way one year ago (or so) on #d-b, Um, all I got from your communication on this subject was that you would make it an official field, not that you would put it *in* the binary package. > and no one seemed to oppose, and I requested comments on the patch > implementing this again on #d-b few days before committing. That does > not mean that decision could not be changed, but I don't see a good > reason to do so, the current implementation seems cleaner anyway. If you cared so much about our opinion that you requested comments twice before, why are you continually ignoring our opinion now, and continually re-closing this bug report? -- see shy jo signature.asc Description: Digital signature
Bug#452273: dpkg-gencontrol: incorrect warning "deb package with udeb specific field Installer-Menu-Item"
Guillem Jover wrote: > There's 278 udebs in the current main Packages file. Each Package-Type > field takes 19 bytes, so 5282 bytes of bloat. In comparison the > Description field takes 49416 bytes. If you are really concerned about > "bloat", maybe you could trim those down instead. We are constantly trimming udeb descriptions. However, unlike this useless new field, udeb descriptions do have value -- they are displayed to the user. Your continual closusre of this bug report and refusal to listen to us is becoming very annoying. -- see shy jo signature.asc Description: Digital signature
Bug#452273: dpkg-gencontrol: incorrect warning "deb package with udeb specific field Installer-Menu-Item"
Guillem Jover wrote: > It's not included and has never been, because only the ones with B are. > But now it's explicit given that dpkg-gencontrol supports the > field. Package-Type should have been XB- from the beginning. That > information is pertinent to the binary package and not to the changes > file. No, there is no reason to bloat udebs with this infrormation. This information is only used when building udebs. -- see shy jo signature.asc Description: Digital signature
Bug#452273: Package-Type
Frans seems to be spot on, dpkg should honor XC-Package-Type, and Package-Type should be treated as an implicitly "XC" field, that is not propigated into built packages. Unless you have a plan for including Package-Type in a [u]]deb that I'm unaware of. -- see shy jo signature.asc Description: Digital signature
Bug#452012: Acknowledgement (Path.pm exits subroutine via last)
To reproduce this bug, run dpkg-shlibdeps on a package that does not yet have a debian/tmp/DEBIAN directory. For example, this displays the perl warning. It also generates an empty substvars file despite the binaries linking to libc6 and stuff. [EMAIL PROTECTED]:~package/aalib>dpkg-shlibdeps -Tdebian/libaa-bin.substvars -Ldebian/libaa1/DEBIAN/shlibs debian/libaa-bin/usr/bin/aainfo debian/libaa-bin/usr/bin/aatest debian/libaa-bin/usr/bin/aafire debian/libaa-bin/usr/bin/aasavefont The above also displays many bogus warnings: dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. dpkg-shlibdeps: warning: symbol [EMAIL PROTECTED] used by debian/libaa-bin/usr/bin/aasavefont found in none of the libraries. OTOH, this works fine: [EMAIL PROTECTED]:~package/aalib>mkdir debian/libaa-bin/DEBIAN [EMAIL PROTECTED]:~package/aalib>dpkg-shlibdeps -Tdebian/libaa-bin.substvars -Ldebian/libaa1/DEBIAN/shlibs debian/libaa-bin/usr/bin/aainfo debian/libaa-bin/usr/bin/aatest debian/libaa-bin/usr/bin/aafire debian/libaa-bin/usr/bin/aasavefont I suspect this breaks a large number of packages that build with debhelper, as debhelper only creates the DEBIAN directory on demand, so it's typically created after dpkg-shlibdeps is run. So I think this bug should be RC.. -- see shy jo signature.asc Description: Digital signature
Bug#452013: dpkg-gencontrol dies on empty dependencies
Package: dpkg-dev
Version: 1.14.8
Severity: serious
dpkg-gencontrol -plibaa-bin -ldebian/changelog -isp
-Tdebian/libaa-bin.substvars -Pdebian/libaa-bin
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol: error: error occurred while parsing
The control file in question has:
Package: libaa-bin
Architecture: any
Section: text
Depends: ${shlibs:Depends}, ${misc:Depends}
But even simpler things also fail, it chokes on this too:
Depends: ${foo}
And even on this:
Depends:
I'm calling this serious, because there actually are a fair number of
packages with legitimately empty dependencies. Several of them are
udebs, but the "mr" package is a good example of a regular deb with
legitimately empty depends (all it needs is perl-base to run, which is
essential..)
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dpkg-dev depends on:
ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina
ii cpio2.9-6GNU cpio -- a program to manage ar
ii dpkg1.14.8 package maintenance system for Deb
ii make3.81-3 The GNU version of the "make" util
ii patch 2.5.9-4 Apply a diff file to an original
ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction
ii perl-modules5.8.8-12 Core Perl modules
Versions of packages dpkg-dev recommends:
ii bzip21.0.3-7 high-quality block-sorting file co
ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler
ii gcc-2.95 [c-compiler]1:2.95.4-27 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-15 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.6-6 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-17The GNU C compiler
ii gcc-4.2 [c-compiler] 4.2.2-3 The GNU C compiler
-- no debconf information
--
see shy jo
signature.asc
Description: Digital signature
Bug#452012: Path.pm exits subroutine via last
Package: dpkg-dev Version: 1.14.8 Severity: normal Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52. Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52. Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52. Seen while running dpkg-shlibdeps in aalib build. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina ii cpio2.9-6GNU cpio -- a program to manage ar ii dpkg1.14.8 package maintenance system for Deb ii make3.81-3 The GNU version of the "make" util ii patch 2.5.9-4 Apply a diff file to an original ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction ii perl-modules5.8.8-12 Core Perl modules Versions of packages dpkg-dev recommends: ii bzip21.0.3-7 high-quality block-sorting file co ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler ii gcc-2.95 [c-compiler]1:2.95.4-27 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-6 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-17The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.2-3 The GNU C compiler -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#438416: dpkg-divert unitialialized values
Package: dpkg Version: 1.14.5 Severity: normal [EMAIL PROTECTED]:/home/joey>dpkg-divert --remove /tmp/foo Use of uninitialized value in string eq at /usr/sbin/dpkg-divert line 224. Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224. Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224. Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224. No diversion `any diversion of /tmp/foo', none removed -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 5.97-5.3 The GNU core utilities ii libc6 2.6.1-1GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#229357: Can we require build-arch/indep targets for lenny?
Bill Allombert wrote: > + The syntax is a list of options separated by > + commas that are implemented in the build process. > + The following options are defined: If commas are used as delimiters, it should use ", " as the delimiter for consistency with other fields using commas as delimiters. Since debian/control has both space and comma-delimited fields, I have no real preference which is chosen. Also, I like Ian's language about all unknown fields being ignored. -- see shy jo signature.asc Description: Digital signature
Bug#229357: Can we require build-arch/indep targets for lenny?
Ian Jackson wrote: > While we are at it we should write a specification for Build-Options, > something like: > > The Build-Options field appears (only) in the first stanza in > debian/control. It gives a whitespace-separated list of options. > The meanings of these options is defined in policy. > > Any package processing tool may act only on options which it > recognises. Unknown tokens must be ignored. > > Currently only the following token is defined: > > * build-arch > Declares that the package supports all of the following > build targets: `build-indep', `build-arch', `binary-indep', > `binary-arch'. Funny, I'd forgotten this was ever proposed before, and was planning to propose adding a Build-Options field for entirely other, though fully compatible reasons. Which suggests that the name and format are well chosen. I think it would also be useful to include 'nostrip' and 'noopt' in the Build-Options field, as a way to indicate that the package implements those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things that can go in Build-Options, but they're not ready yet and would be OT in this thread. -- see shy jo signature.asc Description: Digital signature
Bug#423451: uninitialised value in update-alternatives
Package: dpkg Version: 1.14.2 Severity: normal Setting up nano (2.0.6-1) ... Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461 Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 461. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. Use of uninitialized value in pattern match (m//) at /usr/sbin/update-alternatives line 717. Use of uninitialized value in concatenation (.) or string at /usr/sbin/update-alternatives line 718. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 5.97-5.3 The GNU core utilities ii libc6 2.5-7 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#410605: not a FTBFS bug
severity 410605 normal
thanks
dpkg does not FTBFS, the severity was inflated.
if (actualread < 0 ) {
const char *errmsg = BZ2_bzerror(bzfile, &err);
if (err == Z_ERRNO) {
if (errno == EINTR) continue;
errmsg= strerror(errno);
}
ohshite(_("%s: internal bzip2 error: `%s'"), v.buf, errmsg);
}
I don't see any cases where BZ2_bzerror can set err to -1 (Z_ERRNO), but
when that test fails to match, it will go on to use the errmsg returned by
BZ2_bzerror, and will still fail correctly with what should be a good
error message.
--
see shy jo
signature.asc
Description: Digital signature
Bug#317082: Not just a dpkg bug
Frank Lichtenheld wrote: > Yeah, that's indeed a problem. But that isn't solved by the current > implementation either. When I think about it there is now way the > -l option (if pointing to a directory that is not known to dpkg) > changes anything about the build currently since the local shlibs > information is considered before using the ldd paths. And the ldd paths > are only used in conjunction with dpkg --search ... > The only thing it does is supressing the error "couldn't find path for > X". You're right. BTW, dpkg-shlibdeps -l does not seem to be documented in its manual page or help text ATM. -- see shy jo signature.asc Description: Digital signature
Bug#335056: dpkg-shlibdeps needs a way to vary dependencies for udebs
Package: dpkg-dev
Version: 1.13.11
Severity: normal
Tags: d-i
Currently all automatically generated udeb library dependencies are
wrong. This causes numerous problems in d-i. In June I proposed a
solution here:
http://lists.debian.org/debian-dpkg/2005/06/msg00198.html
There were no objections and I provided some more details and an
implementation here:
http://lists.debian.org/debian-dpkg/2005/06/msg00202.html
I have attached the patch again to this message.
--
see shy jo
diff -ur old/dpkg-1.13.9/man/C/dpkg-source.1 dpkg-1.13.9/man/C/dpkg-source.1
--- old/dpkg-1.13.9/man/C/dpkg-source.1 2005-06-11 14:30:46.0 -0400
+++ dpkg-1.13.9/man/C/dpkg-source.1 2005-06-25 10:54:42.0 -0400
@@ -516,7 +516,7 @@
.TP
.BI \-L localshlibsfile
Causes
-.B dpkg\-shlibs
+.B dpkg\-shlibdeps
to read overriding shared library dependency information from
.I localshlibsfile
instead of
@@ -527,6 +527,15 @@
output, rather than being added to the substitution variables file
.RB ( debian/substvars
by default).
+.TP
+.BI \-t type
+Causes
+.B dpkg\-shlibdeps
+to prefer shared library dependency information tagged for the given
+package type. If no tagged information is available, falls back to untagged
+information. The default package type is "deb". Shared library dependency
+information is tagged for a given type by prefixing it with the name of the
+type, a colon, and whitespace.
.SH dpkg\-GENCHANGES OPTIONS
.B dpkg\-genchanges
does not take any non-option arguments.
Only in dpkg-1.13.9/scripts: debian
diff -ur old/dpkg-1.13.9/scripts/dpkg-shlibdeps.pl
dpkg-1.13.9/scripts/dpkg-shlibdeps.pl
--- old/dpkg-1.13.9/scripts/dpkg-shlibdeps.pl 2005-06-06 00:07:12.0
-0400
+++ dpkg-1.13.9/scripts/dpkg-shlibdeps.pl 2005-06-25 11:36:45.0
-0400
@@ -17,6 +17,7 @@
$varnameprefix= 'shlibs';
$dependencyfield= 'Depends';
$varlistfile= 'debian/substvars';
+$packagetype= 'deb';
@depfields= qw(Suggests Recommends Depends Pre-Depends);
@@ -42,6 +43,7 @@
-O print variable settings to stdout
-Lshlibs override file, not debian/shlibs.local
-Tupdate variables here, not debian/substvars
+ -t set package type (default is deb)
Dependency fields recognised are ".join("/",@depfields)."
";
}
@@ -66,6 +68,8 @@
&warn("unrecognised dependency field \`$dependencyfield'");
} elsif (m/^-e/) {
push(@exec,$'); push(@execf,$dependencyfield);
+} elsif (m/^-t/) {
+$packagetype= $';
} elsif (m/^-/) {
usageerr("unknown option \`$_'");
} else {
@@ -237,33 +241,37 @@
while () {
s/\s*\n$//; next if m/^\#/;
-if (!m/^\s*(\S+)\s+(\S+)/) {
+if (!m/^\s*(?:(\S+):\s+)?(\S+)\s+(\S+)/) {
&warn("shared libs info file \`$fn' line $.: bad line \`$_'");
next;
}
-next if $1 ne $ln || $2 ne $lsn;
+next if defined $1 && $1 ne $packagetype;
+next if $2 ne $ln || $3 ne $lsn;
return 1 if $fn eq "$curpackdir/DEBIAN/shlibs";
$da= $';
-for $dv (split(/,/,$da)) {
-$dv =~ s/^\s+//; $dv =~ s/\s+$//;
-if (defined($depstrength{$lf})) {
-if (!defined($predefdepfdep{$dv}) ||
-$depstrength{$predefdepfdep{$dv}} < $depstrength{$lf}) {
-$predefdepfdep{$dv}= $lf;
-}
-} else {
-$dk= "$lf: $dv";
-if (!defined($unkdepfdone{$dk})) {
-$unkdepfdone{$dk}= 1;
-$unkdepf{$lf}.= ', ' if length($unkdepf{$lf});
-$unkdepf{$lf}.= $dv;
-}
+last if defined $1; # exact match, otherwise keep looking
+}
+close(SLF);
+
+return 0 unless defined $da;
+
+for $dv (split(/,/,$da)) {
+$dv =~ s/^\s+//; $dv =~ s/\s+$//;
+if (defined($depstrength{$lf})) {
+if (!defined($predefdepfdep{$dv}) ||
+$depstrength{$predefdepfdep{$dv}} < $depstrength{$lf}) {
+$predefdepfdep{$dv}= $lf;
+}
+} else {
+$dk= "$lf: $dv";
+if (!defined($unkdepfdone{$dk})) {
+$unkdepfdone{$dk}= 1;
+$unkdepf{$lf}.= ', ' if length($unkdepf{$lf});
+$unkdepf{$lf}.= $dv;
}
}
-return 1;
}
-close(SLF);
-return 0;
+return 1;
}
if (!$stdout) {
signature.asc
Description: Digital signature
Bug#317967: probably fixed in .11 ..
tag 317967 - security thanks Presumably this bug was fixed in dpkg 1.13.11, which was released well after the fixed zlib got into the archive. Although I've not actually checked all the builds to see. Therefore I am not tracking this bug as a security hole, and IMHO it should be closed, unless the fact that dpkg still embeds a static zlib and still will be vulnerable and need recompiles because of future holes in that library is a problem worth leaving a bug open for. -- see shy jo signature.asc Description: Digital signature
Bug#317967: [EMAIL PROTECTED]
Florian Weimer: > To some extent, it's a policy decision. Is dpkg-deb supposed to > process untrusted input? Are you in the habit of installing third-party debs w/o using dpkg to dump their control files for review? Lets fact it, there are a lot[1] of third-party debs out there, this is something dpkg needs to safely support if our users have even a hope of using them securely. -- see shy jo [1] www.apt-get.org signature.asc Description: Digital signature
Bug#314550: blocky log updating
Package: dpkg Version: 1.13.9 Severity: normal There seems to be some buffering going on with writes to dpkg.log. If you tail it you'll see stuff like this: 2005-06-17 01:09:22 status unpacked smpeg-gtv 0.4.5+cvs20030824-1.1 2005-06-17 01:09:22 status unpacked smpeg-gtv 0.4.5+cvs20030824-1.1 2005-06-17 01:09:23 up And then a minute later it'll spit out the rest of the line and 50 more and some part of another line. Wouldn't it be more useful if it buffered on a line basis and wrote out each new line? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dpkg depends on: ii coreutils [textutils] 5.2.1-2 The GNU core utilities ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an dpkg recommends no packages. Versions of packages dpkg is related to: ii reportbug 3.13 reports bugs in the Debian distrib pn totem-gstreamer(no description available) -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#314352: dpkg-source fails on netive packages with non-native versioning
Package: dpkg-dev Version: 1.13.9 Severity: important [EMAIL PROTECTED]:~/tmp/t>apt-get source bogl Reading Package Lists... Done Building Dependency Tree... Done Need to get 95.8kB of source archives. Get:1 http://http.us.debian.org unstable/main bogl 0.1.18-1.1 (dsc) [649B] Get:2 http://http.us.debian.org unstable/main bogl 0.1.18-1.1 (tar) [95.1kB] Fetched 95.8kB in 4s (22.6kB/s) dpkg-source: error: unrecognised file suffix `.tar' Unpack command 'dpkg-source -x bogl_0.1.18-1.1.dsc' failed. E: Child process failed zsh: exit 100 apt-get source bogl Arguably native packages with non-native versions are broken, but there are a lot of them out there. And the error message sucks. :-) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dpkg-dev depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii cpio 2.5-1.2GNU cpio -- a program to manage ar ii dpkg 1.13.9 Package maintenance system for Deb ii make 3.80-9 The GNU version of the "make" util ii patch 2.5.9-2Apply a diff file to an original ii perl [perl5] 5.8.7-3Larry Wall's Practical Extraction ii perl-modules 5.8.7-3Core Perl modules -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#222652: reassign to dpkg-dev
Scott James Remnant wrote: > reassign 222652 dpkg-dev > thanks > > ... [EMAIL PROTECTED] ... > -- what was on YOUR mind? :p Argh, that often-made typo finally escaped my box. Thank you mutt. No, not that way. Bleh. > On Mon, 2005-06-13 at 12:03 -0400, Joey Hess wrote: > > > Well, of Branden's options, 1 seems like going behind dpkg-gencontrol's > > back and the wrong place to put code to remove dups; 2 complicates > > debhelper unnessarily; 3 seems like a good idea to me, but I dunno how > > the dpkg developers will feel about it; 4 seems reasonable too. > > > 3 seems like a good idea to me too, for much the same reason. Excellent! -- see shy jo signature.asc Description: Digital signature
