Bug#1040062: Build failure for pydevd on alpha: gp-relative relocation against dynamic symbol
On Sat, Oct 28, 2023 at 03:34:47PM +0300, Adrian Bunk wrote: > On Fri, Oct 20, 2023 at 07:03:41AM +0100, Julian Gilbey wrote: > > Hi! > > > > I'm completely out of my depth on this one, and I wonder whether > > anyone might be able to help. > > [...] > > /usr/bin/ld: /tmp/ccR4bmTq.ltrans5.ltrans.o: gp-relative relocation against > > dynamic symbol __pyx_module_is_main__pydevd_bundle__pydevd_cython > > [...] > > That's related to #1040062, the best fix that does not involve touching dpkg > is: Thanks Adrian! I'll apply this patch. Best wishes, Julian
Bug#931782: dupload: warn if attempt to upload binaries to main
Package: dupload Version: 2.9.4 Severity: wishlist Hi! Now that the release team have said that only source-only uploads will be accepted for migration to bullseye (at least in debian/main), could dupload be patched to check for this, asking for confirmation if the .changes file is not source-only and the target is main? Thanks, Julian
Bug#726932: dpkg-dev: dpkg-buildflags has FFLAGS != CFLAGS
Package: dpkg-dev Version: 1.16.12 The dpkg-buildflags manpage says that FFLAGS should be the same as CFLAGS, but: polya:~ $ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-Wl,-z,relro This appears to be because FFLAGS is not included in the add_hardening_flags sub in /usr/share/perl5/Dpkg/Vendor/Debian.pm, though whether this is intentional or not, I am unsure. Julian -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698249: dpkg-dev: dpkg-source could support 7z compressed files
Package: dpkg-dev Version: 1.16.9 Severity: wishlist It would be nice if dpkg-source could support 7z compressed files. Julian -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#303030: parse error, in file `/var/lib/dpkg/available' after update
severity 303030 important thanks On Mon, Apr 04, 2005 at 02:04:24PM +0100, Francois wrote: Hello Scott, I still don't know where my problem came from, but I've (temporarily) solved it with 'dpkg --clear-avail'. Before that dpkg was refusing to install new packages from deb archives. Strangely enough however synaptic seemed not to be impacted by the situation. Could it be that synaptic messed up with dpkg's config file? Please see my comments in bug#478970. I have also been experiencing this problem sporadically when using aptitude, but it seems that the culprit is dpkg itself. Somehow, dpkg seems to sometimes mess up the formatting of the available file when rewriting it. I don't know when or why this happens, but next time I will keep a copy. Also, yesterday, during the large stable - testing upgrade, dpkg managed to make the same error with its status file: it lost the beginning of a package section, right up to and including Depends: and began the section with the first dependency. The only way to fix it was to manually edit the status file. This seems like quite a serious problem! Julian -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#397121: unnecessary dpkg accesses to the available file
On Sun, Jul 06, 2008 at 06:39:32PM +0300, Guillem Jover wrote: Hi, [...] The fact that dpkg pays attention to the available file at all is a bug; it should only care about the state of the system and not about external repositories. Only higher level package managers like apt and dselect should do that. [...] The only important information might be the Section and Priority fields, which are usually overriden and used to create roostraps or select what's the base system, etc. But on the other hand I think all programs doing that are using the archive Packages files for that purpose, so I guess it's fine to apply this patch. [...] Yeah seems reasonable, will review and merge. Please could you do this? I have frequently had problems where dpkg seems to have corrupted the available database (as reported by someone else in bug#303030); if dpkg does not look at this database, then such problems can be avoided. (The source of bug#303030 is a separate matter entirely, though.) Julian -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#478970: aptitude + complete /var/lib/dpkg/availablea
On Thu, Feb 19, 2009 at 07:18:43AM -0800, Daniel Burrows wrote: The culprit seems to be dpkg itself; at the end of running dpkg --unpack ... (called from aptitude), the available file is updated (or at least touched); the same happened at the end of dpkg --configure Turns out this has been reported against dpkg itself, so I guess the severity of this aptitude bug should be returned to wishlist. Better yet, it can be reassigned to dpkg and merged with the existing bug. No; that would be a distraction from the original topic of this bug (which is that aptitude should update /var/lib/dpkg/available). I'll post some comments to #303030 and raise its severity instead. Thank you for your help! Julian -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457135: Confusing error unable to create for diverted files
On Thu, Dec 20, 2007 at 03:41:59AM +0100, dAniel hAhler wrote: With diverted files the unable to create error is confusing. [...] With the attached patch the error will look like the following instead: dpkg: error processing /var/cache/apt/archives/xserver-xorg-core_2%3a1.4.1~git20071212-1ubuntu2_i386.deb (--install): unable to create `/usr/lib/nvidia/libwfb.so.xserver-xorg-core.dpkg-new' (while processing `./usr/lib/xorg/modules/libwfb.so'): No such file or directory I was stuck for two hours trying to debug a problem with a package which wouldn't install as I was bitten by this very same confusing error message. Please, please, please apply this simple patch - it would have saved me and others such headaches! (Even better still would be a message to say that a diversion has been applied, but this is a very good solution in the meantime.) Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470540: dpkg: [install-info] Use of implicit regexps when reading INFO-DIR-SECTION causes confusing entries
Package: dpkg Version: 1.14.16.6 When the texinfo info doc has been installed, the info file contains: INFO-DIR-SECTION Texinfo documentation system and so the dir file ends up with a section entitled Texinfo documentation system However, when packages providing info files specifying: INFO-DIR-SECTION TeX are later installed, TeX is turned into a regex /^tex/, which ends up matching Texinfo documentation system. So I now have a load of TeX documentation under the Texinfo documentation system heading in my info directory. It would make sense that if INFO-DIR-SECTION is read from an info file, that it is not treated as a regex, but used only as an exact match. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] dpkg-buildpackage development goal
On Tue, Oct 09, 2007 at 02:13:41AM +0200, Frank Lichtenheld wrote: On the other hand one could argue that dpkg-buildpackage should intentionally remain simple and that people are expected to write their own wrappers or replacements if they need. I like this thought. On the other hand, something like integrating dpkg-sig(s) functionality might be a good thing to do. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397479: dpkg-dev: dpkg-buildpackage -B -b fails
tags 397479 + patch
thanks
This trivial patch allows people who do -B -b to not get bitten; it
simply pays attention to the last option and not the first.
--- /usr/bin/dpkg-buildpackage 2006-06-21 16:08:36.0 +0100
+++ /tmp/dpkg-buildpackage 2006-11-08 16:02:50.0 +
@@ -109,7 +109,7 @@
-tc)cleansource=true ;;
-t*)targetgnusystem=$value ;; # Order DOES matter!
-nc)noclean=true; if [ -z $binaryonly ]; then binaryonly=-b; fi ;;
- -b) binaryonly=-b; [ $sourceonly ] \
+ -b) binaryonly=-b; checkbuilddep_args=''; binarytarget=binary; [
$sourceonly ] \
{ echo 2 $progname: cannot combine $1 and -S ; exit
2 ; } ;;
-B) binaryonly=-B; checkbuilddep_args=-B; binarytarget=binary-arch;
[ $sourceonly ] \
{ echo 2 $progname: cannot combine $1 and -S ; exit
2 ; } ;;
Julian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#179913: dpkg -l doesn't display epoch version
I'm unclear why this bug has been tagged wontfix - no explanation is given. I'd like to see this bug resurrected and the (tiny) patch applied for the following reason. As the BTS now accurately tracks bug reports using version numbers, and it is quite common to grab the version number using dpkg -l rather than dpkg -s (shorter output!), it is likely to lead to a number of bug reports with the wrong version number. Far better would be to just have the correct version number displayed by dpkg -l in the first place. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322926: merging changes files breaks wrappers (like debuild)
On Sat, Dec 03, 2005 at 11:41:14PM +0300, Nikita V. Youshchenko wrote: I probably understood how 'sources' come in. If one first runs 'dpkg-buildpackage -S', a .changes file will be created with 'sources' in the arch part of the name. Later, if 'dpkg-buildpackage' is run to create binary packages, it creates a .changes file with real arch part of the name; so there are two .changes files, and they are merged. Probably a good workaround will be not to include 'source' in the merged file name in such case. Committed this workaround to dpkg-cross CVS. This will be in dpkg-cross 1.26 Don't know what to do with this bug now. Probably submitter or debuild maintainer should decide if this is enough to close it. Please could you look at bug #217546? I think this is probably the same thing, which you have now fixed, but I am not certain. Thanks! Julian (as devscripts/debuild maintainer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322926: merging changes files breaks wrappers (like debuild)
On Sat, Aug 20, 2005 at 11:32:07PM +0400, Nikita V. Youshchenko wrote:
Package: dpkg-cross, devscripts, dpkg-dev
Severity: normal
If dpkg-cross is installed, it provides it's own dpkg-buildpackage,
which potentially replaces the *_${arch}.changes file with
*_source+${arch}.changes. When debuild calls helpers like lintian or
debsign, these will fail because debuild assumes the
*_${arch}.changes filename.
[...]
Thank you for the bug report.
Dpkg-cross still needs to be adopted to post-sarge changes in dpkg.
I'm at last back from all summer trips, and hope to do this work on the
ongoing weeks. While doing it, I will look what can be done do with this
issue.
Any further thoughts on this?
Julian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217945: dpkg-dev: should depend on build-essential
On Tue, Nov 04, 2003 at 06:52:21PM -0600, Adam Heath wrote: (2) If it is not for dpkg to enforce policy, why run dpkg-checkbuilddeps during dpkg-buildpackage, with an abort on error? Because that's not policy, but a dpkg interface. I'm confused: policy talks about build-essential packages and Build-Depends etc. in the same breath, if I'm not very much mistaken. (Sections 4.2 and 7.6.) I just don't understand the distinctions you and Wichert are making. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217945: dpkg-dev: should depend on build-essential
On Wed, Nov 05, 2003 at 12:56:08PM -0600, Adam Heath wrote: I'm confused: policy talks about build-essential packages and Build-Depends etc. in the same breath, if I'm not very much mistaken. (Sections 4.2 and 7.6.) I just don't understand the distinctions you and Wichert are making. [...] Other systems that use dpkg may not make this same descision. Ah, that's the missing piece for me. Thanks. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217945: dpkg-dev: should depend on build-essential
Adam Heath wrote: On Wed, 29 Oct 2003, Herbert Xu wrote: Agreed. However, making dpkg-checkbuilddeps do the appropriate checks seems to be the logical solution. No. dpkg-checkbuilddeps will not enforce debian policy. In fact, none of dpkg should enforce policy. And, on that note, dpkg-dev will not build-depend on build-essential either, for the same reason. We used to do this. But Wichert convinced me it was wrong, and the change was backed out. (1) You should then back out the change to the dpkg-checkbuilddeps manpage as well. (2) If it is not for dpkg to enforce policy, why run dpkg-checkbuilddeps during dpkg-buildpackage, with an abort on error? (3) A happy compromise could be for dpkg-checkbuilddeps to check for the presence of build-essential (or for the build-essential dependencies) and to warn (only) if any are not found, rather than to exit with an error. Implementing a check for the build-essential package is, as you know, easy; implementing a check for the build-essential dependencies without assuming that the package is installed would probably be easiest to do by dpkg build-depending on build-essential, then copying the dependency list into the dpkg-checkbuilddeps script. And that would require dpkg-dev to become Architecture: any, so I don't really like this approach. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217943: dpkg-dev: dpkg-checkbuilddeps gets confused with Build-Conflicts
Package: dpkg-dev
Version: 1.10.16
Severity: minor
Tags: patch
In /usr/bin/dpkg-checkbuilddeps, two bugs:
(1) (minor): in sub usage, the usage instruction reads:
Usage: dpkg-checkbuild [-B] [control-file]
but of course the program is now called dpkg-checkbuilddeps
(2) (more significant)
When checking the Build-Depends and Build-Conflicts fields (line
43 onwards), it puts _all_ of the results in @unmet, rather than
putting the unsatisfied depends in @unmet and the unsatisfied
conflicts in @conflicts.
Patch which fixes both of these:
--- /usr/bin/dpkg-checkbuilddeps2003-10-25 21:51:27.0 +0100
+++ /tmp/dpkg-checkbuilddeps2003-10-28 10:26:45.0 +
@@ -11,7 +11,7 @@
sub usage {
print STDERR EOF;
-Usage: dpkg-checkbuild [-B] [control-file]
+Usage: dpkg-checkbuilddeps [-B] [control-file]
-B binary-only, ignore -Indep
control-filecontrol file to process [Default: debian/control]
EOF
@@ -44,13 +44,13 @@
push @unmet, build_depends(parsedep($fi{C Build-Depends}, 1),
@status);
}
if (defined($fi{C Build-Conflicts})) {
- push @unmet, build_conflicts(parsedep($fi{C Build-Conflicts}, 1),
@status);
+ push @conflicts, build_conflicts(parsedep($fi{C Build-Conflicts}, 1),
@status);
}
if (! $binary_only defined($fi{C Build-Depends-Indep})) {
push @unmet, build_depends(parsedep($fi{C Build-Depends-Indep}, 1),
@status);
}
if (! $binary_only defined($fi{C Build-Conflicts-Indep})) {
- push @unmet, build_conflicts(parsedep($fi{C Build-Conflicts-Indep},
1), @status);
+ push @conflicts, build_conflicts(parsedep($fi{C
Build-Conflicts-Indep}, 1), @status);
}
if (@unmet) {
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, website: http://www.polya.uklinux.net/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217946: dpkg-dev: /usr/share/doc/dpkg-dev should be useful
Package: dpkg-dev Version: 1.10.16 Severity: minor (My third bug report today - sorry guys ;-) /usr/share/doc/dpkg-dev is an empty directory. Much better would be to have it a symlink to /usr/share/doc/dpkg. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217945: dpkg-dev: should depend on build-essential
Package: dpkg-dev Version: 1.10.16 (This has come up before, bug#118420, which was closed with dpkg 1.10. However, the bug is again present in 1.10.16.) dpkg-dev should Depends: build-essential, or at the very least, Recommends: it; in the latter case, dpkg-checkbuilddeps should check for the presence of the package. Otherwise, people not running buildd's may well discover that they can't build their packages (and I've had some interesting bug reports against devscripts which arise from this bug). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#163061: dpkg-buildpackage has poor heuristics to decide between pgp and gpg
tags 163061 + patch thanks Here's the one-line patch I am applying to debsign, translated to a patch for dpkg-buildpackage. It fixes bugs #158614 and #211031 in devscripts, and so would fix the same issues in dpkg-buildpackage. --- /usr/bin/dpkg-buildpackage 2003-10-25 21:51:27.0 +0100 +++ dpkg-buildpackage 2003-10-28 11:34:27.0 + @@ -48,7 +48,7 @@ rootcommand='' signcommand= -if [ -e $GNUPGHOME/secring.gpg -o -e $HOME/.gnupg/secring.gpg ] \ +if [ \( -n $GNUPGHOME -a -e $GNUPGHOME \) -o -e $HOME/.gnupg ] \ command -v gpg /dev/null 21; then signcommand=gpg elif command -v pgp /dev/null 21 ; then It handles the cases: (1) the GNUPG secret keyring is in a location specified in the GNUPG options file, and not ~/.gnupg/secring.gpg (2) the GNUPG directory has been chmod 000 for a small amount of extra security; the effect is to get a more meaningful error message Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217963: dpkg-dev: dpkg-buildpackage should create .changes file even if signing .dsc fails
Package: dpkg-dev
Version: 1.10.16
Tags: patch
If something goes wrong with the signature process for the .dsc file,
then dpkg-buildpackage aborts at that point, meaning that the only
obvious way to proceed is to rebuild the entire package. (Of course,
one could run dpkg-genchanges etc. manually, but that's possibly not
such a great idea.) The following patch means that a failed signature
does not stop the build, but causes it to exit with an error at the
end anyway. After this, debsign can be used to sign the .dsc/.changes
files.
--- /usr/bin/dpkg-buildpackage 2003-10-25 21:51:27.0 +0100
+++ dpkg-buildpackage 2003-10-28 13:27:25.0 +
@@ -166,8 +166,14 @@
$signcommand -u ${signkey:-$maintainer} +clearsig=on -fast
../$1 \
../$1.asc
fi
+ status=$?
+ if [ $status -eq 0 ]; then
+ mv -- ../$1.asc ../$1
+ else
+ /bin/rm -f ../$1.asc
+ fi
echo
- mv -- ../$1.asc ../$1
+ return $status
}
withecho () {
@@ -205,8 +211,12 @@
read dummy_stuff
fi
+signerrors=
if [ x$binaryonly = x ]; then
-$signsource $pv.dsc
+ if ! $signsource $pv.dsc; then
+ signerrors=(WARNING: Failed to sign .dsc and .changes file)
+ signchanges=:
+ fi
fi
chg=../$pva.changes
withecho dpkg-genchanges $@ $chg
@@ -242,10 +252,16 @@
fi
fi
-$signchanges $pva.changes
+if ! $signchanges $pva.changes; then
+ signerrors=(WARNING: Failed to sign .changes file)
+fi
if $cleansource; then
withecho $rootcommand debian/rules clean
fi
echo dpkg-buildpackage: $srcmsg
+if [ -n $signerrors ]; then
+ echo 2 $signerrors
+ exit 1
+fi
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, website: http://www.polya.uklinux.net/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
Bug#217815: dpkg-buildpackage includes policy url in .dsc/.changes
This same issue applied to dpkg-buildpackage as it does to debsign, the latter just containing code copied from the former. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Another attempt at the build-arch problem (fwd)
What do you guys think of this idea? I think it's one of the smartest I've heard for a while, and leaves open the possibility of further extensions. Another possibility is to have something like debian/rules.features, which would have a list of features supported by the debian/rules file. For example, current possible features, based on musings on the -policy list, could include build-arch and test. For example, if debian/rules.features had one keyword per line, then dpkg-buildpackage et al could do something like: if [ -r debian/rules.features ] grep -q build-arch debian/rules.features then ... else ... fi This would potentially be more flexible than debian/rules.version, but also potentially more confusing. - Forwarded message from Bill Allombert [EMAIL PROTECTED] - Date: Thu, 23 Oct 2003 00:58:19 +0200 From: Bill Allombert [EMAIL PROTECTED] Subject: Re: Bug#216492: FTBFS (unstable/all) missing build-dep To: debian-policy@lists.debian.org [...] So I come up with a different proposal: Introducing a new file, say debian/rules.version. If this file does not exist, we declare that version=0, else version=`cat debian/rules.version`. Currently 2 versions are defined: 0: debian/rules support rules described as mandatory by policy. 1: as 0, but debian/rules also support build-arch and build-indep. Future version of policy can define higher version. dpkg-buildpackage just need to read this file before deciding whether it can call debian/rules build-arch. What do you think ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. - End forwarded message - Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Document dpkg:(Upstream)Version Reassigning
reopen 85815 tags 85815 - fixed reassign 85815 dpkg thanks The dpkg:(Upstream)Version substvars should be documented in the dpkg-genchanges/dpkg-gencontrol manpage. These variables are no longer documented at all in policy, but should join the collection in this manpage. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#33994: 33994 not reproducible
On Wed, Oct 09, 2002 at 07:38:35AM +0200, Thomas Hood wrote: tags 33994 moreinfo thanks I just tried this and fg did not cause apt to clear the screen. Which is not to say that this can never happen. Under what circumstances does this happen? Run dselect. Select the [I]nstall option (with apt as the dselect method). While the packages are being installed, do a suspend/ctrl-Z. Then fg clears the screen. This could be a dselect bug, though. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#33394: not a bug?
On Wed, Oct 02, 2002 at 02:11:11PM +0200, Wichert Akkerman wrote: Previously Julian Gilbey wrote: If I recall correctly, the default status for a new package used to be hold ok not-installed, whereas it is currently purge ok not-installed. I highly doubt that. If so that is years and years ago and certainly no longer relevant. Let's see polya:~ $ grep-status -F Status hold ok not-installed -s Package | wc -l 1942 Hmm, that's 1942 entries in the status file which have this status. That makes it certainly still relevant for me. (Incidentally, it seems that the change to dpkg's behaviour happened around 1998, so it was years and years ago, but stuff like this has a habit of sticking around for a *long* time.) One possibility of cleaning up this properly might be to have dpkg internally convert hold ok not-installed to purge ok not-installed so that the next time the status file is updated by dpkg, there are no more entries with this status. This code would only need to exist for sarge (or possibly also sarge+1), for after that, everyone who's followed Debian release-by-release will have had their status files upgraded. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#33394: not a bug?
On Tue, Oct 01, 2002 at 10:51:48AM +0200, Thomas Hood wrote: Housekeeping ... Date: Mon, 15 Feb 1999 00:41:59 + (GMT) dpkg --forget-old-unavail only removes unavailable packages from the status file which have Status: purge ok not-installed, but not those which have Status: hold ok not-installed, This doesn't look like a bug to me. Close? If I recall correctly, the default status for a new package used to be hold ok not-installed, whereas it is currently purge ok not-installed. So it may still be worth keeping this around for a bit. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#138409: PROPOSAL] Add build environment data to package.changes files
On Fri, Mar 15, 2002 at 05:15:37PM +, James Troup wrote: Julian Gilbey [EMAIL PROTECTED] writes: If you can find a bigger one easily, I'll test that too! Evolution or any of the big gnome packages (e.g. gnumeric). evolution: 92 dependencies, an extra 1-2 seconds. gnumeric: 69 dependencies, an extra second. Hardly worth worrying about ;-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#133470: dpkg-dev: dpkg-buildpackage signinterface check
Package: dpkg-dev Version: 1.9.18 Severity: minor Tags: patch The test for valid signinterface in dpkg-buildpackage (lines 120 onwards) is not quite adequate: if test -n $forcesigninterface ; then signinterface=$forcesigninterface if [ $signinterface != gpg -a $signinterface != pgp ] ; then echo 2 $progname: invalid sign interface specified exit 1 fi else signinterface=$signcommand fi Note that $forcesigninterface can only be gpg or pgp by the design of the program, whereas $signcommand could be anything. So this replacement should be much more effective at doing the necessary checks. You could always leave the first check in as well, in case the -s* options are dealt with by stripping -s off at a later date. if test -n $forcesigninterface ; then signinterface=$forcesigninterface else signinterface=$signcommand if [ $signinterface != gpg -a $signinterface != pgp ] ; then echo 2 $progname: need to specify sign interface as gpg or pgp exit 1 fi fi Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: My recent bug's and continuing effort to debconf-ize Debian
On Thu, Aug 31, 2000 at 03:21:17PM -0700, Sean 'Shaleh' Perry wrote: I started this afternoon submitting bugs against packages which print verbose output in their maintainer scripts. The future that Debian must take is to A thread came up here a little while back about installation scripts sometimes not being able to use debconf for security or other reasons. But we would like an interference-free install. So what about introducing a dpkg-postconfigure program which runs package.postconfig files after any dpkg run has finished, in an analagous way to dpkg-preconfigure. Only this time, it will be only for things that *must* wait till post-installation, and cannot use debconf for whatever reason. There shouldn't be that many of these, but it would probably be a good idea to introduce this soon as we move to non-interactive installs. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Faster 'dpkg -s'?
On Sun, Jul 23, 2000 at 05:23:40AM -0400, Itai Zukerman wrote: I see (at least) two possibilities: 1. dpkg -s $PACKAGE 2. sed -n -e /^Package: $PACKAGE$/,/^$/p /var/lib/dpkg/status Install dlocate. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
dpkg conffiles weirdness
I've just had a bizarre experience upgrading from test-cycle-1 to test-cycle-2, perhaps someone can shed some light? I used dselect with an APT backend. One of the upgraded packages was xterm, from version 3.3.6-6 to 3.3.6-7. There's a conffile in the package: /etc/X11/Xresources/xterm. I had a modified version, which was unceremoniously moved to xterm.dpkg-old and replaced by the new version. No questions were asked. (Incidentally, the backspace key in emacs in an xterm now behaves like ctrl-H. Any ideas why? Yuck!) I tried reinstating the old xterm conffile and reinstalling version 3.3.6-7, but now the conffile wasn't touched. I then tried deleting the conffile and reinstalling; no conffile was installed at all this time. Purging and reinstalling reinstalled the conffile, but nothing less would do so. Does anyone have a clue what might be up? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: interesting question
Package: packaging-manual Version: 3.1.1.1 On Tue, Apr 04, 2000 at 12:48:27PM -0700, Joey Hess wrote to -devel: Here's an interesting hypothetical question we came up with at the office: Suppose a .deb is released that does rm -rf / in its prerm. We know it has been installed on a bunch of machines all over the place. How can we safely upgrade them? [explanation of difficulty snipped] I just wrote a long thought about similar problems, and then realised that I didn't understand the packaging manual, section 6.3, para 1. Could I suggest the following rewording to clarify the issue (which more clearly describes the behaviour of dpkg): - 1. If a version the package is already installed, call old-prerm upgrade new-version - 2. If this gives an error (ie, a non-zero exit status), dpkg - will attempt instead: + 2. If the script runs but exits with a non-zero exit status, dpkg + will attempt: new-prerm failed-upgrade old-version Error unwind, for both the above cases: old-postinst abort-upgrade new-version - Still doesn't solve the problem Joey has, though. I wonder whether the possibility of having a prerm-override file would help, or whether it would just complicate things unnecessarily. Although I could imagine situations in which non-malicious but still serious bugs in prerm's could cause similar situations to arise. Basically, in the current setup, prerm bugs are mostly unfixable. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#49598: dpkg: dpkg-buildpackage usage message not up to date
Package: dpkg-dev Version: 1.4.1.19 dpkg-buildpackage -h no longer lists all available options; things like -t have been added since the message was written. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#49395: dpkg: -X user error reports about --vextract
Package: dpkg Version: 1.4.1.19 It would be nice if the error message better matched the command in the following situation: polya:~ $ dpkg -X /var/cache/apt/archives/passwd_19990827-8_i386.deb dpkg-deb: --vextract needs a target directory. Perhaps you should be using dpkg --install ? polya:~ $ Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#37254: dpkg: update-alternatives madness
I agree that update-alternatives shouldn't put an alternative into manual mode because a _target_ disappeared unexpectedly. I'll look into this eventually. But, the problem doesn't happen if you call update-alternatives in the prerm, which is where you should. So it would be good if the policy manual could be changed to this effect. Therefore, I've reassigned this bug to debian-policy, dpkg. When the policy is changed, please assign it back to dpkg. Thanks, Ian. Now the packaging manual already states: Each package provides its own version under its own name, and calls update-alternatives in its postinst to register its version (and again in its prerm to deregister it). Do we need to then specify this in the policy manual, or will it be sufficient to file bugs against packages which don't have the needed update-alternatives in their prerm? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#37254: dpkg: update-alternatives madness
Previously Julian Gilbey wrote: Do we need to then specify this in the policy manual, or will it be sufficient to file bugs against packages which don't have the needed update-alternatives in their prerm? No need to put this in the policy manual. The policy manual is for policies, not for guidelines to make packages. Wichert. So I'm reassigning back to dpkg. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#46808: dpkg: update-rc.d regexp error
Package: dpkg
Version: 1.4.1.13
There is an error in the /^start|stop$/ regexp; it should have
parentheses. Here is a patch.
--- update-rc.d.origWed Oct 6 15:54:12 1999
+++ update-rc.d Wed Oct 6 15:55:51 1999
@@ -52,10 +52,10 @@
}
$_ = $ARGV[0];
-if(/^remove$/) { checklinks (remove); }
-elsif (/^defaults$/) { defaults; makelinks }
-elsif (/^start|stop$/) { startstop; makelinks; }
-else { usage; }
+if(/^remove$/) { checklinks (remove); }
+elsif (/^defaults$/) { defaults; makelinks }
+elsif (/^(start|stop)$/) { startstop; makelinks; }
+else { usage; }
exit (0);
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#43682: dpkg-shlibdeps: should use $? 8
Package: dpkg-dev Version: 1.4.0.35 Line 130 of dpkg-shlibdeps checks for the exit status of a command using $? instead of $? 8. This probably happens elsewhere too. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#37592: dselect automatically deselects libc6 and essential packages
I tried to upgrade my system from slink to potato and found a problem in dselect. After pressing Enter in [S]elect to leave the select screen, dselect wants to deselect libc6 and all packages that depend on it (which is almost any package - including essential ones!). After some testing I found that the problem is caused by the devscripts package: # dpkg -s devscripts Package: devscripts [...] Version: 2.2.4 Depends: dpkg-dev, netstd, patch, perl Recommends: dupload, libtricks | fakeroot, lintian Suggests: debian-keyring, pgp, libmd5-perl, perl-suid Conflicts: debmake ( 3.5) As you can see, devscripts recommends libtricks | fakeroot. libtricks can't be installed with the new libc6 because ... # dpkg -s libc6 Package: libc6 [...] Version: 2.1.1-3 Conflicts: [...], libtricks, apt ( 0.3.0) ... libc6 conflicts with it. So the only way to satisfy devscript's recommendations would be to install fakeroot. This situation causes the problem: When fakeroot is not installed and you try to install devscripts, dselect automatically deselects libc6 and all the other packages (instead of just selecting fakeroot). [...] No problems occur if you remove libtricks from libc6's conflict line or from devscript's recommends line in /var/lib/dpkg/status. A possible workaround would be for devscript to just recommend fakeroot but I think it's better to solve the real problem. Let's get something working in the meantime. First question: if devscripts is modified so that it recommends fakeroot | libtricks (opposite order), does that help? That could be a clue to fixing the problem. I will upload a devscripts which recommends only fakeroot in the meantime. libtricks in potato Provides: fakeroot, so devscripts doesn't need to mention libtricks. Although how useful libtricks will be given the situation remains unclear. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#37017: dpkg: .deb should contain authentication data
Package: dpkg Version: 1.4.0.34 Severity: Important (Important as it is a security issue that has been brought up recently in several contexts, and we know that mirrors can be compromised.) .debs should have an extra component in the ar archive which are PGP-signed MD5 sums (or equivalent) of the other two sections of the .deb archive (control and data). Dpkg (or dpkg-deb?) should create this part when asked to, in a way to be decided, and should be able to check it if asked to. Less urgent is a way of enabling users to confirm these PGP signatures before installing the packages. There is the obvious DFSG problem of making dpkg depend on PGP -- this may actually be a very good opportunity to begin working towards GnuPG by having the signatures be GnuPG ones. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#34589: dpkg: prerm purge call, perhaps
Julian Gilbey writes (Bug#34589: dpkg: prerm purge call, perhaps): Package: dpkg Version: 1.4.0.34 Severity: wishlist I think it might be nice if the prerm script were to be called with a purge argument before the conffiles are removed during the purge phase of package removal. I have a use for such a facility. (This would come immediately before step 5 in section 6.5 of the Packaging Manual.) Please explain your requirement. (There are some reasons why this is not necessarily a very good idea.) I was dealing with a package which left configuration-type files around after removal, and I would have liked to have removed them pre-purge so that the automatic conffile removal doesn't balk at non-empty directories where it expects them. But this is essentially cosmetic, as the real work can of course be done in the postrm, so if this will introduce problems, then it's not worth implementing. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#33787: dpkg: unnecessary warning on --purge
Package: dpkg Version: 1.4.0.33 When purging a package which has conffiles in a directory owned only by the package, it issues a warning during the remove phase that the directory is not empty. The problem is probably in dpkg/remove.c, remove_bulk(), which should check whether the reason for the inability to remove the directory is due solely to the presence of conffiles. It should also attempt to remove the directory again after purging conffiles, which it does not currently do. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#33394: dpkg: --forget-old-unavail doesn't work properly
Package: dpkg Version: 1.4.0.33 dpkg --forget-old-unavail only removes unavailable packages from the status file which have Status: purge ok not-installed, but not those which have Status: hold ok not-installed, which is the usual state of play for never-installed packages. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#32765: dpkg-dev: various scripting bugs
Package: dpkg-dev
Version: 1.4.0.31 (+later?)
Here are a few bugs I noticed in certain of the scripts which probably
haven't been fixed yet. I haven't bothered giving diffs, as there are
going to be so many changes to so much stuff, by the looks of it, that
it won't necessarily be of much help.
I'm looking forward to Ian having the time now to work on it: good luck!!
dpkg-parsechangelog
===
Does not accept a -h option; needs the line
if (m/^-h$/) { usageversion; exit(0); }
near the end of the main while(@ARGV) loop.
parsechangelog/debian
=
There is a missing + in the regexp for examining the final line of
a changelog section; it does not allow a time zone such as (GMT).
The line should read:
} elsif (m/^ \-\- (.*) (.*)
((\w+\,\s*)?\d{1,2}\s+\w+\s+\d{4}\s+\d{1,2}:\d\d:\d\d\s+[-+]\d{4}(\s+\([^\\\(\)]+\))?)$/)
{
with an extra '+' after the [^\\\(\)].
dpkg-genchanges
===
Typo in section:
for $_ (keys %fi) {
...
if (s/^C //) {
...
elsif (m/^X[BS]+-|...
with no '|' before the ^X.
controllib.pl
=
There are problems when capit is applied to a field name such as
XB-Foobar. I would suggest something like the following
replacement (untested):
sub capit {
if ($_[0] =~ m/^(X[BCS]+)-(.*)/i) {
return uc($1) .
( defined($capit{lc($2)}) ? $capit{lc($2)} : ucfirst(lc($2)) );
} else {
return ( defined($capit{lc($_[0])}) ?
$capit{lc($_[0])} : ucfirst(lc($_[0])) );
}
}
One could even envisage a function capit which broke the input into
hyphen-separated segments and capitalised each one:
sub capit {
my (@parts,@capit_parts);
@parts = split /-/, $_[0];
@capit_parts = map { ucfirst(lc($_)) } @parts;
if ($parts[0] =~ /^X[BCS]+/i) { @capit_parts[0] = uc($parts[0]); }
return join '-', @capit_parts;
}
This would make the field names much more consistent in form and do
away with the need for the exceptions array (although it could be
retained if desired).
dpkg-gencontrol
===
There's a problem if there's an _all.deb file created and
dpkg-gencontrol is run more than once -- the file ends up being
listed multiple times. This is due to the line near the end of the
code (and \d could replace 0-9 in the character class):
if (open(X, $fileslistfile)) {
while (X) {
s/\n$//; # chomp would probably be nicer here, incidentally ;-)
next if m/^([-+0-9a-z.]+)_[^_]+_([-\w]+)\.deb /
($1 eq $oppackage) ($2 eq $arch);
whereas the last line should read something like:
($1 eq $oppackage) ($2 eq $arch or $2 eq 'all');
HTH,
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#32210: dpkg-dev: parsechangelog cannot handle one character package names
reassign 32210 dpkg-dev
retitle 32210 Bug#32210: dpkg-dev: parsechangelog cannot handle one character
package names
thanks
Trying to build a .deb archive of our m package
(http://www.phy.hw.ac.uk/~karsten/M/),
build complains about files in debian/ being ill-formatted.
The bug is in /usr/lib/dpkg/parsechangelog/debian, where line 54 should
be corrected to read:
-if (m/^(\w[-+0-9a-z.]+) \(([^\(\) \t]+)\)((\s+[-0-9a-z]+)+)\;/i) {
+if (m/^(\w[-+0-9a-z.]*) \(([^\(\) \t]+)\)((\s+[-0-9a-z]+)+)\;/i) {
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#32318: devscripts: Build doesn't stop on errors
Well, dpkg-dev (which has dpkg-buildpackage) has no changelog in /usr/doc/dpkg-dev. dpkg's changelog was last updated on October 22. On Mon, Jan 25, 1999 at 03:00:07PM +, Julian Gilbey wrote: OK. The reason I reported it against debuild is that this behavior was not exhibited before switching from build to debuild in the new devscripts. John Was there a change in dpkg-buildpackage at the same time, perhaps? Julian That is completely bizarre. I'll try to investigate. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#32318: dpkg-dev: dpkg-buildpackage doesn't stop on errors
reassign 32318 dpkg-dev retitle 32318 dpkg-dev: dpkg-buildpackage doesn't stop on errors thanks John Goerzen reported: For instance: dh_installexamples cp: template.html: No such file or directory dh_installexamples: command returned error code make: *** [binary-indep] Error 1 signfile dailyupdate_6.01-1.dsc Pretty Good Privacy(tm) 2.6.3a - Public-key encryption for the masses. Even after make aborts with error, debuild goes on to try to sign things. It's actually a bug in these lines of dpkg-buildpackage: withecho debian/rules build withecho $rootcommand debian/rules $binarytarget if [ x$binaryonly = x ]; then $signsource $pv.dsc fi chg=../$pva.changes withecho dpkg-genchanges $@ $chg Nowhere are there any checks for whether the commands succeeded. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey Email: [EMAIL PROTECTED] Dept of Mathematical Sciences, Queen Mary Westfield College, Mile End Road, London E1 4NS, ENGLAND -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Bug#31508: parsechangelog broken?
Package: dpkg-dev
Version: 1.4.1
Severity: important
Without the attached patch, I am unable to build packages with
dpkg-buildpackage.
Christian
[...]
You've got a bug all right, but the problem was that you were using a
non-English locale and controllib.pl assumes that you will get English
error messages. The following patch will fix the problem.
Wichert or someone else: could you please rebuild dpkg and upload it
with this patch? It is a bit much for me to download for such a small
bug.
Julian
--- controllib.pl.orig Fri Jan 15 01:08:51 1999
+++ controllib.pl Fri Jan 15 01:10:15 1999
@@ -1,3 +1,4 @@
+use POSIX qw(:errno_h);
$parsechangelog= 'dpkg-parsechangelog';
@@ -101,7 +102,7 @@
$substvar{$1}= $';
}
close(SV);
-} elsif ($! !~ m/no such file or directory/i) {
+} elsif ($! != ENOENT) {
error(unable to open substvars file $varlistfile: $!);
}
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey Email: [EMAIL PROTECTED]
Dept of Mathematical Sciences, Queen Mary Westfield College,
Mile End Road, London E1 4NS, ENGLAND
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
