[SCM] dpkg's main repository branch, master, updated. 2c22031a81b0933bd90309637a83ced532449406
The branch, master has been updated
via 2c22031a81b0933bd90309637a83ced532449406 (commit)
from 6233f972c4d6a5d015d825482f39c80aa757abdf (commit)
- Shortlog
2c22031 dpkg-source: Fix diff generation for filenames containing spaces
Summary of changes:
ChangeLog |8
debian/changelog |3 +++
scripts/dpkg-source.pl |9 +
3 files changed, 16 insertions(+), 4 deletions(-)
---
Details of changes:
commit 2c22031a81b0933bd90309637a83ced532449406
Author: Frank Lichtenheld [EMAIL PROTECTED]
Date: Sun Oct 7 17:10:32 2007 +0200
dpkg-source: Fix diff generation for filenames containing spaces
Include a trailing HT character in the diff labels if
the filename contains spaces. Apparantly this is
standard but undocumented diff behaviour. Based on
a patch by Marcel Toele.
diff --git a/ChangeLog b/ChangeLog
index b1eafab..f301b1a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2007-10-07 Frank Lichtenheld [EMAIL PROTECTED]
+ Marcel Toele [EMAIL PROTECTED]
+
+ * scripts/dpkg-source.pl (handleformat): Include
+ a trailing HT character in the diff labels if
+ the filename contains spaces. Apparantly this is
+ standard but undocumented diff behaviour.
+
2007-09-29 Frank Lichtenheld [EMAIL PROTECTED]
* scripts/dpkg-buildpackage.pl: Call checkversion()
diff --git a/debian/changelog b/debian/changelog
index 6c33f1c..139d1c0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,6 +35,9 @@ dpkg (1.14.7) UNRELEASED; urgency=low
Closes: #379418
* Let dpkg-buildpackage error out early if the version number from
the changelog is not a valid Debian version. Closes: #216075
+ * Fix dpkg-source to create correct diffs for files with spaces in
+their name (apparantly we don't have many of those ;).
+Based on a patch by Marcel Toele. Closes: #445380
[ Updated dpkg translations ]
* Basque (Piarres Beobide). Closes: #440859
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index 5b7802d..da22b98 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -594,10 +594,11 @@ if ($opmode eq 'build') {
$ENV{'LC_ALL'}= 'C';
$ENV{'LANG'}= 'C';
$ENV{'TZ'}= 'UTC0';
-exec('diff','-u',
- '-L',$basedirname.orig/$fn,
- '-L',$basedirname/$fn,
- '--',$ofnread,$dir/$fn) or syserr(_g(exec
diff));
+ my $tab = ($basedirname/$fn =~ / /) ? \t : '';
+ exec('diff','-u',
+'-L',$basedirname.orig/$fn$tab,
+'-L',$basedirname/$fn$tab,
+'--',$ofnread,$dir/$fn) or syserr(_g(exec
diff));
}
my $difflinefound = 0;
$/= \n;
--
dpkg's main repository
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote: I've been working on making dpkg-source support a new source package format based upon git. Oh, one question that comes to mind: how does this affect checking for non-free stuff in past revisions? If 3.1-4 had some non-free files that get reimplemented for 3.2-1, do we (a) expect the maintainer to do a no-history upload for 3.2-1; (b) check that this happens somehow; (c) not worry about it as long as it's only in the history; (d) something else? Verifying that not just the current tree is DFSG-free, but all the history is too seems potentially difficult. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 02:56:47PM +1000, Anthony Towns wrote: On Sat, Oct 06, 2007 at 10:37:48PM +, Colin Watson wrote: The second possibility seems to me to be more flexible, though, and probably not all that hard to implement: build both a .tar.gz (containing the working tree) and a .$VCS.tar.gz, and teach 'dpkg-source -x' to unpack the tree given at least one of these. This would allow various interesting possibilities such as: Would this be better in any way than having a web interface that provides an autogenerated version-1 source package? Presume it's a url like: http://v1source.qa.debian.org/i/ifupdown/ifupdown_0.6.8.dsc Autogenerated source packages won't (presumably, certainly not without some special arrangements) be mirrored on useful services like www.mirrorservice.org that let you peek inside tarballs without opening them, and seem difficult for people to mirror locally in general since it would put a lot of stress on v1source.qa.debian.org which I expect would be a lot less beefy than the regular Debian mirror network. I'm quite attached to being able to peek inside source packages quickly by sshing over to the local mirror I keep at home which grabs everything overnight so that I don't have to wait for it to download; particularly so for large source packages. * Derivative distributions who are slow to upgrade their dpkg-source could still interoperate to some degree. They'd need to pull sources from the autogenerated url; though they'd still probably have Build-Depends: issues if they're not updating packages generally. Oh, I was referring more to the buildd base system and archive maintenance code too; dak needs to be updated in order to accept format 3.0 source packages, for instance. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
* Joey Hess: I have a sourcev3 branch with my changes at git://kitenet.net/dpkg, and have also attached a diff to this mail. I feel that this is ready for review and hopefully merging into dpkg now. Looking forward to your comments. What about empty directories? I really think you need to work off a clone (or a cleaned-up cp -al'ed copy). For instance, you do not necessary want to upload the reflog, or unreachable objects. The GIT configuration stored inside .git is probably uninteresting, too. But it's still a nice idea, I think. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sat, Oct 06, 2007 at 10:09:22PM -0400, Joey Hess wrote: Colin Watson wrote: (So, FWIW, I'm not sold on git. Not sold at all yet. But it was a good choice for this implementation for several reasons.) (I don't think bzr is perfect either, of course; the lack of shallow branches (see below) is one flaw that's very relevant to this application. If there were a distributed VCS that were clearly better than the others in every respect, we'd probably all know about it ...) Still, this work looks pretty cool, and I'd like to be able to make use of it despite avoiding git whenever I can. I noticed that you'd helpfully structured your changes such that it would be possible to plug in a different revision control system, so I wrote a module to support bzr. Nice. The FAQ has some questions aimed at adding other revision control systems, could you try to answer those in the context of bzr? In particular, is the data that would be shipped in the source package the same data that bzr normally reads from untrusted sources, thus ensuring that using it this way is equally (in)secure as using bzr to pull data over the network? (Note that this wasn't 100% true for git and I have had to put in several workarounds.) I believe so; bzr has hooks but AFAICS they're only exposed to plugins (i.e. code that goes in /usr or in ~/.bazaar/plugins) rather than being something that lives in the .bzr directory. I don't know of anything executable in .bzr. I intentionally used 'bzr branch' to create the data that will be shipped, which is the same command used to branch from a network repository, so I believe that if there is a security flaw in this implementation then it would also be a security flaw in bzr itself. The only things I really needed to tweak were to remove a couple of bits of metadata which aren't useful in this context: branch-name ended up with blah.bzr.tar.gz.tmp or something like that in it, and it'll be detected from the unpacked directory name if it doesn't exist; and parent is just the directory 'bzr branch' branched from. And is the data format stable and/or one that bzr has a history of supporting old versions of in a way that ensures backwards compatability? The data format has changed a few times, but so far bzr has an excellent history of continuing to support old versions. Some data formats (dating from 0.8 or so) are marked as unsupported and you have to use 'bzr upgrade' before doing anything else. Everything else at worst nags you to run 'bzr upgrade'. I think they may have dropped support for some very old formats that basically only some early bzr developers used. Also, will the bzr repos always contain the full history, or is there an equivilant to git shallow clones? How big do they tend to be? I don't have as comfortable an answer here. There's no equivalent to git shallow clones yet (only a design, http://bazaar-vcs.org/HistoryHorizon; so this will probably get fixed one day). At present the .bzr tends if anything to be a little bigger than the source. I think due to historical performance issues people tend not to be using bzr much on very large trees yet, so I'm hoping this won't be an issue for a while; whereas the git backend has the immediate prospect of linux-2.6.git.tar.gz. ;-) * Some source packages want to ship non-VCS-managed files. It's very common for source packages to include autogenerated objects like configure, Makefile.in, etc. Whether to check these into a VCS is a somewhat religious matter (as acknowledged by the gettext info documentation, for instance), and personally I lean towards checking them in (with a few exceptions) just because it makes it easier to see when they change and keep an eye out for oddities, but I know that a lot of developers prefer to keep these outside their VCS. Shipping a working tree would make it easier to handle cases like this. Hmm, I hadn't considered that this might be a problem. I don't know if I'd want to write the code to do this, but shipping a partial working tree consisting of just those files would be enough to solve this. That ought to be relatively straightforward; just list all the files that the VCS knows about and unlink them. It seemed untidy though. Maybe put them in a separate directory (.bzr-extra-files or something) which is copied over after unpack, and make it a dpkg-source -b option rather than the default behaviour? FWIW, I was thinking much more of native packages here; non-native packages already tend to just import the upstream tarball which usually contains generated files, which is probably why this hasn't been a problem for things like git-buildpackage. If nothing else, there are several native packages in the d-i tree alone that don't have configure et al in Subversion. Alternatively, if people don't agree with me that we should ship the working tree by default, maybe it could be an option for the few packages
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 11:55:49AM +, Colin Watson wrote: Of course, a number of packages accidentally ship .svn directories and so on anyway, though I suppose there's a difference between officially blessed by dpkg and warned against by lintian ... That has to be the understatement of the year ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 08:45:08AM +, Colin Watson wrote: I'm quite attached to being able to peek inside source packages quickly by sshing over to the local mirror I keep at home which grabs everything overnight so that I don't have to wait for it to download; particularly so for large source packages. How is that better than running apt-get source against your local mirror, though? Alternatively, is it really a problem to have your local mirror autogenerate v1 source packages in the same way v1source.qa.d.o presumably would? (I have a strong adverse reaction to duplicated information, so shipping the working tree in .git format and .orig.tar.gz format irks me, particularly if it's required) * Derivative distributions who are slow to upgrade their dpkg-source could still interoperate to some degree. They'd need to pull sources from the autogenerated url; though they'd still probably have Build-Depends: issues if they're not updating packages generally. Oh, I was referring more to the buildd base system and archive maintenance code too; dak needs to be updated in order to accept format 3.0 source packages, for instance. Well, you'd need an entirely new .dsc to use a v3 source package with an un-updated dak (or launchpad or whatever), that didn't contain the .git.tar.gz (or whatever) elements at all, so I don't personally see a lot of difference between just generating a new .dsc and generating a new .dsc and .tar.gz. (It might be just me, but I'm getting the feeling that implementing WigPen via this v3 format is probably easier than implementing it via the v2 format...) I might be off my rocker, but I'm not seeing any reason why we couldn't allow uploads of v3 format packages to experimental while blocking them for unstable etc, presuming dpkg somewhere supported them. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:18:17PM +1000, Anthony Towns wrote: On Sun, Oct 07, 2007 at 08:45:08AM +, Colin Watson wrote: I'm quite attached to being able to peek inside source packages quickly by sshing over to the local mirror I keep at home which grabs everything overnight so that I don't have to wait for it to download; particularly so for large source packages. How is that better than running apt-get source against your local mirror, though? Alternatively, is it really a problem to have your local mirror autogenerate v1 source packages in the same way v1source.qa.d.o presumably would? Of course, one possibility is to go the opposite direction: having a v3 source repository, that will automatically create v1 (or even v2 packages) and upload them to the main archive. [...] (It might be just me, but I'm getting the feeling that implementing WigPen via this v3 format is probably easier than implementing it via the v2 format...) Could you please explain what the difference between WigPen and v2 format is? I've seen them as identities so far. I might be off my rocker, but I'm not seeing any reason why we couldn't allow uploads of v3 format packages to experimental while blocking them for unstable etc, presuming dpkg somewhere supported them. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Anthony Towns wrote: Maybe providing a feature on packages.debian.org (or similar) to download sources in simple, non-VC, tarball format would make this a complete non-issue though? pristine-tar could be used for this, it would just need source packages to put the delta somewhere standaised (under debian/), and would need some standarised way to get to the upstream source branch in git. So the logic there would be: if there's an upstream tag, then generate an .orig.tgz if there's a pristine-tar info, hax0r it to be pristine generate a .diff.gz if the .diff failed goto bailout generate a .dsc containing the orig and diff It's not generally possible to generate a .diff.gz that expresses all the changes that might be in a git repository. Repo formats that bzr in etch can unpack could be denoted by Source-Depends: dpkg-bzr (= 0.11) while repo formats that require bzr from lenny or later could be denoted by: Source-Depends: dpkg-bzr (= 0.18) I was thinking about Source-Depends too, the main problem seems to be that it would need to be supported in apt-get source too. I wonder if we could just use build-depends. -- see shy jo signature.asc Description: Digital signature
Triggers status?
Hi, I was wondering what the status of merging Ian's triggers work is; I can't find any comments by the dpkg maintainers on it. I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Anthony Towns wrote: Oh, one question that comes to mind: how does this affect checking for non-free stuff in past revisions? If 3.1-4 had some non-free files that get reimplemented for 3.2-1, do we (a) expect the maintainer to do a no-history upload for 3.2-1; (b) check that this happens somehow; (c) not worry about it as long as it's only in the history; (d) something else? Verifying that not just the current tree is DFSG-free, but all the history is too seems potentially difficult. Yes, the faq discusses this problem. This is why shallow repos are IMHO important and non-shallow repos should only be uploaded with caution. -- see shy jo signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
Florian Weimer wrote: What about empty directories? Do you mean empty directories under .git or empty directories stored *in* git (can't be done, use a .gitignore in the directory) I really think you need to work off a clone (or a cleaned-up cp -al'ed copy). For instance, you do not necessary want to upload the reflog, or unreachable objects. The GIT configuration stored inside .git is probably uninteresting, too. I think if you read my code you'll see that I've dealt with these problems (Frank pointed out the reflog issue earlier in this thread), and of course it *does* build from a cleaned, cp'd copy, and run git-gc, and sanitise the .git/config, and... -- see shy jo signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
Colin Watson wrote: FWIW, I was thinking much more of native packages here; non-native packages already tend to just import the upstream tarball which usually contains generated files, which is probably why this hasn't been a problem for things like git-buildpackage. If nothing else, there are several native packages in the d-i tree alone that don't have configure et al in Subversion. Or these files could be checked into a copy of the repo that is used to build the source package, and not checked into the main vcs. This is not unlike those same packages in d-i shipping the generated files in their .diff.gz, if you look at diff as just another vcs.. -- see shy jo signature.asc Description: Digital signature
Re: Triggers status?
Colin Watson wrote: I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. I have a fairly vast number of things that I want to use triggers for in debhelper.. -- see shy jo signature.asc Description: Digital signature
Re: Manual pages and POD format
On Fri, Sep 28, 2007 at 11:40:49AM +0200, Nicolas François wrote: Maybe pod has a minor issue regarding translations, which is that the title (the last argument to the .TH command) must be specified on the pod2man command line and is thus harder to translate. But I would not complain if it is not translated. We only use three different titles: Debian dpkg suite dpkg utilities I guess it should be managable to arrange for them to be translated. But the majority seems to be contend with roff for now, anyway. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:05:08AM -0400, Joey Hess wrote: Colin Watson wrote: FWIW, I was thinking much more of native packages here; non-native packages already tend to just import the upstream tarball which usually contains generated files, which is probably why this hasn't been a problem for things like git-buildpackage. If nothing else, there are several native packages in the d-i tree alone that don't have configure et al in Subversion. Or these files could be checked into a copy of the repo that is used to build the source package, and not checked into the main vcs. This is not unlike those same packages in d-i shipping the generated files in their .diff.gz, if you look at diff as just another vcs.. This is true. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:18:17PM +1000, Anthony Towns wrote: On Sun, Oct 07, 2007 at 08:45:08AM +, Colin Watson wrote: I'm quite attached to being able to peek inside source packages quickly by sshing over to the local mirror I keep at home which grabs everything overnight so that I don't have to wait for it to download; particularly so for large source packages. How is that better than running apt-get source against your local mirror, though? Faster for some cases involving huge packages where I don't want to transfer the whole thing over wireless. Doesn't require complex apt configuration to point to the right package if what I want isn't the current version in the release I'm running. Etc. Alternatively, is it really a problem to have your local mirror autogenerate v1 source packages in the same way v1source.qa.d.o presumably would? I suppose that would be possible (if the code were properly packaged, integrated into debmirror, etc.), though it sounds like a big chunk of resources on my rather underpowered mirror server. (Yes, that's my problem, but I'm sure I'm not the only one.) I also can't see general mirrors like mirrorservice.org doing this kind of highly distro-specific thing, so we'd still lose handy look at a single file within this package on the web tools unless we reimplemented them on debian.org systems. Those sorts of things are very useful for big source packages. (I have a strong adverse reaction to duplicated information, so shipping the working tree in .git format and .orig.tar.gz format irks me, particularly if it's required) I do understand this reaction though ... Oh, I was referring more to the buildd base system and archive maintenance code too; dak needs to be updated in order to accept format 3.0 source packages, for instance. Well, you'd need an entirely new .dsc to use a v3 source package with an un-updated dak (or launchpad or whatever), that didn't contain the .git.tar.gz (or whatever) elements at all, so I don't personally see a lot of difference between just generating a new .dsc and generating a new .dsc and .tar.gz. True; I was thinking that a quick hack to permit v3 while still basically just unpacking .tar.gz and .diff.gz would be easier than full support for a derivative distribution that wasn't paying a whole lot of attention, but maybe it doesn't make that much difference. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess [EMAIL PROTECTED] said: I've been working on making dpkg-source support a new source package format based upon git. The idea is that a source package has only a .dsc and a .git.tar.gz, which is just a git repo. My implementation adds a new 3.0 version source format. A 3.0 format debian source package can consist of any files allowed by formats 1 and 2, but may also contain .$VCS.tar.gz files. To build a version 3 source package, a new field is needed in debian/control: I do not yet grok git, so could someoe tell me what this means in terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when the we are using CVS? manoj -- We don't like their sound. Groups of guitars are on the way out. Decca Recording Company, turning down the Beatles, 1962 Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:05:32AM -0500, Manoj Srivastava wrote: On Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess [EMAIL PROTECTED] said: My implementation adds a new 3.0 version source format. A 3.0 format debian source package can consist of any files allowed by formats 1 and 2, but may also contain .$VCS.tar.gz files. To build a version 3 source package, a new field is needed in debian/control: I do not yet grok git, so could someoe tell me what this means in terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when the we are using CVS? For CVS it would need to contain the repository (i.e. all the RCS files), for arch I don't know enough about it to say. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 07 Oct 2007, Frank Lichtenheld wrote: (It might be just me, but I'm getting the feeling that implementing WigPen via this v3 format is probably easier than implementing it via the v2 format...) Could you please explain what the difference between WigPen and v2 format is? I've seen them as identities so far. I don't know either. But I'd like to dig in to say a few words. I like the idea of Joey and I'd also like to improve our source packages. I think we need to step back a bit and maybe try to come up with a more generic design encompassing wigpen and the work of Joey. But it's not as easy as it seems because we have many different requirements as shown by Colin and others. And furthermore, the data flow is considerably different when we integrate VCS in the picture. I'm not even sure that we should really call v3 a 'source package'. The goals of wigpen were IIRC: 1/ support of other compression mechanism 2/ support of multiple tarballs (glibc case) 3/ automatic support of debian/patches (1) should be a no-brainer (2) is not clear: what would multiple tarballs mean with a VCS repository? (3) patches are auto-applied at source extraction time. In a VCS, what does it mean ? In Joey's work, all Debian changesets are in the master branch which is auto-extracted if I understand correctly (I haven't read the code, only the discussion here). What about cases were multiple branches are stored? (One for upstream, one for Debian) Also, it seems important to keep the possibility to always generate a plain source package from any VCS based source package. But we might need some information to be able to do that properly. Exactly like we need new information if we ever want to support generation of v2 source packages. Is there some ground to create something common for those two use cases? (Sorry, everything is still a bit blur in my mind and while I was preparing myself to maybe hack on wigpen as my next dpkg related project, this discussion took me by surprise :-)) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 05:25:00PM +0200, Raphael Hertzog wrote: (Sorry, everything is still a bit blur in my mind and while I was preparing myself to maybe hack on wigpen as my next dpkg related project, this discussion took me by surprise :-)) Btw, if someone has too much free time and doesn't mind writing documentation, a deb-source.5 (or dsc.5) manpage similar to what we have for binary packages in deb.5 would be great stuff. Especially if it would document both V1 and V2. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:05:32AM -0500, Manoj Srivastava wrote:
On Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess [EMAIL PROTECTED] said:
I've been working on making dpkg-source support a new source package
format based upon git. The idea is that a source package has only a
.dsc and a .git.tar.gz, which is just a git repo.
My implementation adds a new 3.0 version source format. A 3.0 format
debian source package can consist of any files allowed by formats 1
and 2, but may also contain .$VCS.tar.gz files. To build a version 3
source package, a new field is needed in debian/control:
I do not yet grok git, so could someoe tell me what this means
in terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when
the we are using CVS?
I think this only really makes sense for distributed revision control
systems. For arch, the .arch.tar.gz would contain the {arch} directory,
perhaps with a few adjustments similar to those being made in the git
and bzr modules.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Hi,
OK, commenting on this with my I use arch hat on. If I
understand correctly, we are proposing shipping a working directory in
the .deb; and not shipping an orig.tar.gz nor a diff.gz file. I like
the idea; and I think I can support nested arch packages (submodules in
.git speak), based on the examples I have seen of joey's patch and
Colin's for bzr -- I just need some more information about what exactly
some of these git commands do.
sub prep_tar:
make sure we have an ./{arch} directory.
Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested $tree_root`;
** Why are we checking for uncommitted files here? I would think that
people would have done an export to actually build packages **
for each tree_root and nested; do
run $TLA CHANGES
map { $list{${NESTED_PATH}/$_} = 1; } join ,, `$TLA inventory -s`
done
For all files in exclude list, go and set values in %list to 0 (or
delete the key)
** I have no idea what the prune and shallow copy commands do, or the
arch equivalent **
sub post_unpack_tar
make sure we have an ./{arch} directory.Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested $tree_root`;
** arch hooks are per user, not per repo -- iirc **
** what does git-config do? or bzr checkout? **
Actually, at this point I am beginning to question my
understanding of the proposal. If we are shipping a working tree, what
is this step doing?
Is this an svn update equivalent?
manoj
--
If a computer can't directly address all the RAM you can use, it's just
a toy. anonymous comp.sys.amiga posting, non-sequitur
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 09:54:39 -0400, Joey Hess [EMAIL PROTECTED] said: Anthony Towns wrote: Oh, one question that comes to mind: how does this affect checking for non-free stuff in past revisions? If 3.1-4 had some non-free files that get reimplemented for 3.2-1, do we (a) expect the maintainer to do a no-history upload for 3.2-1; (b) check that this happens somehow; (c) not worry about it as long as it's only in the history; (d) something else? Verifying that not just the current tree is DFSG-free, but all the history is too seems potentially difficult. Yes, the faq discusses this problem. This is why shallow repos are IMHO important and non-shallow repos should only be uploaded with caution. What does this mean in non-git context? manoj -- Don't get even -- get odd! Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Triggers status?
On Sun, 7 Oct 2007 10:13:45 -0400, Joey Hess [EMAIL PROTECTED] said: Colin Watson wrote: I have a change to man-db that uses triggers to update the manual page database automatically, fixing my second oldest remaining bug. I'd love to upload this. While it doesn't break with a non-triggers-supporting dpkg, I'd rather wait until triggers are merged in case their implementation changes incompatibly, so I'm curious as to how long I might need to wait. I have a fairly vast number of things that I want to use triggers for in debhelper.. I also would love to have a pre-install trigger (which I think is not present in the current patch; I'll be working on that) to ensure that a SELinux policy for a package is loaded before the package in unpacked; so that dpkg would be aware of initial security contects for files and directories before we unpack a package for the first time. manoj -- Linux: the operating system with a CLUE... Command Line User Environment. (seen in a posting in comp.software.testing) Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 15:44:47 +, Colin Watson [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 10:05:32AM -0500, Manoj Srivastava wrote:
On Fri, 5 Oct 2007 19:16:13 -0400, Joey Hess [EMAIL PROTECTED] said:
I've been working on making dpkg-source support a new source
package format based upon git. The idea is that a source package
has only a .dsc and a .git.tar.gz, which is just a git repo.
My implementation adds a new 3.0 version source format. A 3.0
format debian source package can consist of any files allowed by
formats 1 and 2, but may also contain .$VCS.tar.gz files. To build
a version 3 source package, a new field is needed in
debian/control:
I do not yet grok git, so could someoe tell me what this means in
terms of, say, CVS or arch? What is a $CVS.tar.gz file contain when
the we are using CVS?
I think this only really makes sense for distributed revision control
systems. For arch, the .arch.tar.gz would contain the {arch}
directory, perhaps with a few adjustments similar to those being made
in the git and bzr modules.
Hmm. If I have just the ./{arch} directory, and none of the
files, then arch thinks the files have just been deleted; and you can't
just check out stuff, since the tree is up to date. Ah. Baz undo
restores all the files, cool.
The problem here is that the repository in question _has_ to be
registered by the user running this; so all the users would have to
register the arch repository in question before unpacking the source
tarball in order to tell baz/tla how to get access to the repo. Is this
going to be an issue?
I would prefer to instead ship a grab file for arch instead of
the {arch} directory, since the latter really buys us nothing over the
grab file (since we are requiring the distributed source dir and
network access to unpack source packages).
Consider this grab file:
--8---cut here---start-8---
Archive-Name: [EMAIL PROTECTED]
Archive-Location: http://arch.debian.org/arch/private/srivasta
Target-Revision: packages--debian--1.0
Target-Directory: manoj-packages
Target-Config: configs/ucf/debian/ucf-3.003
--8---cut here---end---8---
tla register-archive --present-ok $values-of-Archive-Location-field
tla grab path/to/the/grab-file
cd $value-of-field-Target-Directory/package-name/*
(room for standardization here)
manoj
--8---cut here---start-8---
__ baz status
* looking for [EMAIL PROTECTED]/ucf--devel--3.0--patch-1 to compare with
* comparing to [EMAIL PROTECTED]/ucf--devel--3.0--patch-1
D .arch-ids
D examples
D examples/.arch-ids
D t
D t/.arch-ids
D .arch-ids/COPYING.id
D .arch-ids/ChangeLog.id
D .arch-ids/Makefile.id
D .arch-ids/lcf.1.id
D .arch-ids/lcf.id
D .arch-ids/ucf.1.id
D .arch-ids/ucf.conf.5.id
D .arch-ids/ucf.conf.id
D .arch-ids/ucf.id
D .arch-ids/ucfq.1.id
D .arch-ids/ucfq.id
D .arch-ids/ucfr.1.id
D .arch-ids/ucfr.id
D COPYING
D ChangeLog
D Makefile
D examples/.arch-ids/=id
D examples/.arch-ids/ChangeLog.id
D examples/.arch-ids/postinst.id
D examples/.arch-ids/postrm.id
D examples/ChangeLog
D examples/postinst
D examples/postrm
D lcf
D lcf.1
D t/.arch-ids/=id
D ucf
D ucf.1
D ucf.conf
D ucf.conf.5
D ucfq
D ucfq.1
D ucfr
D ucfr.1
__ baz update
* tree is already up to date
--8---cut here---end---8---
--
Time is money and money can't buy you love and I love your outfit
T.H.U.N.D.E.R. #1
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:52:45AM -0500, Manoj Srivastava wrote: What does this mean in non-git context? I think truncating the patch-log history is unimportant for Arch, but any ++pristine-trees should definitely be nuked prior to packing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 11:10:41AM -0500, Manoj Srivastava wrote:
Hmm. If I have just the ./{arch} directory, and none of the
files, then arch thinks the files have just been deleted; and you can't
just check out stuff, since the tree is up to date. Ah. Baz undo
restores all the files, cool.
I presume you could ship all the normal files in one tarball,
the .arch-ids and {arch} directories in another, and the debian/
directory in a third.
That would give the NMUer a full working tree to run $TLA diff
in. Only shipping a grab file would burden the end user with
a need for http access and no guarantee that the source will
be available.
The problem here is that the repository in question _has_ to be
registered by the user running this; so all the users would have to
register the arch repository in question before unpacking the source
tarball in order to tell baz/tla how to get access to the repo. Is this
going to be an issue?
It shouldn't be too difficult to add an --autoregister switch to tla
grab, though I don't know how safe it'd be.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote:
OK, commenting on this with my I use arch hat on. If I
understand correctly, we are proposing shipping a working directory in
the .deb; and not shipping an orig.tar.gz nor a diff.gz file. I like
You probably mean source package here and not .deb. Also the original
proposal just means shipping the repository data, since most DVCS can
easily create a working directory from that.
the idea; and I think I can support nested arch packages (submodules in
.git speak), based on the examples I have seen of joey's patch and
Colin's for bzr -- I just need some more information about what exactly
some of these git commands do.
sub prep_tar:
make sure we have an ./{arch} directory.
Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested $tree_root`;
** Why are we checking for uncommitted files here? I would think that
people would have done an export to actually build packages **
The whole idea of the proposal is to NOT create an export.
for each tree_root and nested; do
run $TLA CHANGES
map { $list{${NESTED_PATH}/$_} = 1; } join ,, `$TLA inventory -s`
done
For all files in exclude list, go and set values in %list to 0 (or
delete the key)
** I have no idea what the prune and shallow copy commands do, or the
arch equivalent **
git gc --prune deletes old data that isn't needed anymore. This is
needed since all other git commands never change or overwrite data
(file data, this is obviously not true for meta data), they only
add some.
sub post_unpack_tar
make sure we have an ./{arch} directory.Look for nested submodules:
$tree_root=$($TLA tree-root);
@nested=`$TLA inventory -t --nested $tree_root`;
** arch hooks are per user, not per repo -- iirc **
** what does git-config do? or bzr checkout? **
git-config is just an cli interface to the .git/config file.
Since we only ship the repository we need to create the working
tree. This is what git/bzr checkout do.
Actually, at this point I am beginning to question my
understanding of the proposal. If we are shipping a working tree, what
is this step doing?
Is this an svn update equivalent?
No, that would be git fetch/pull (and probably something similar named
in bzr)
Gruesse,
--
Frank Lichtenheld [EMAIL PROTECTED]
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote:
OK, commenting on this with my I use arch hat on. If I understand
correctly, we are proposing shipping a working directory in the .deb;
and not shipping an orig.tar.gz nor a diff.gz file. I like
You probably mean source package here and not .deb. Also the original
proposal just means shipping the repository data, since most DVCS can
easily create a working directory from that.
Hmm. The repository data, as far as I can tell, means the name
of the archive, and the location. Do you really mean we are not
shipping any, say, foo.c file in the sources, just a locatio where you
can get the foo.c file from, at a particular version?
The whole idea of the proposal is to NOT create an export.
If we are not creating and export, and we are only shipping the
repository data, how come there needs to be a check for uncommitted
files? If the changes are uncommitted, that means the repo does not
know about it; and if we only ship the repository data, we are not
shipping stuff not in the repo.
What am I missing?
for each tree_root and nested; do run $TLA CHANGES map {
$list{${NESTED_PATH}/$_} = 1; } join ,, `$TLA inventory -s` done
For all files in exclude list, go and set values in %list to 0 (or
delete the key)
** I have no idea what the prune and shallow copy commands do, or the
arch equivalent **
git gc --prune deletes old data that isn't needed anymore. This is
needed since all other git commands never change or overwrite data
(file data, this is obviously not true for meta data), they only add
some.
I am unsure what this means in term of arch.
sub post_unpack_tar make sure we have an ./{arch} directory.Look for
nested submodules: $tree_root=$($TLA tree-root); @nested=`$TLA
inventory -t --nested $tree_root`;
** arch hooks are per user, not per repo -- iirc **
** what does git-config do? or bzr checkout? **
git-config is just an cli interface to the .git/config file. Since we
only ship the repository we need to create the working tree. This is
what git/bzr checkout do.
Well, I do not see how this is done in arch. If you are not
shipping the working tree; all I can see shipping for arch is the URI
of the repo. I am pretty sure this is not what you mean, since then any
arch based source would be three lines or so, and would need network
access to unpack the source tree.
Actually, at this point I am beginning to question my understanding
of the proposal. If we are shipping a working tree, what is this
step doing?
Is this an svn update equivalent?
No, that would be git fetch/pull (and probably something similar named
in bzr)
I don't think I know what this means when you are using arch.
manoj
--
Earn cash in your spare time -- blackmail your friends.
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 12:24:46 -0400, Clint Adams [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 11:10:41AM -0500, Manoj Srivastava wrote:
Hmm. If I have just the ./{arch} directory, and none of the files,
then arch thinks the files have just been deleted; and you can't just
check out stuff, since the tree is up to date. Ah. Baz undo restores
all the files, cool.
I presume you could ship all the normal files in one tarball, the
.arch-ids and {arch} directories in another, and the debian/ directory
in a third.
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
That would give the NMUer a full working tree to run $TLA diff in.
Only shipping a grab file would burden the end user with a need for
http access and no guarantee that the source will be available.
How is git reconstituting the files if there is no network
access? Are they shipping all the bits needed to get a full working
dir without any network access?
The problem here is that the repository in question _has_ to be
registered by the user running this; so all the users would have to
register the arch repository in question before unpacking the source
tarball in order to tell baz/tla how to get access to the repo. Is
this going to be an issue?
It shouldn't be too difficult to add an --autoregister switch to tla
grab, though I don't know how safe it'd be.
caveat emptor, I think, given that some repository access seems
to be required for unpacking a version 3 source package. This is not
something I would do in an un-constrained environment.
manoj
--
It is impossible to make anything foolproof, because fools are so
ingenious.
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 12:14:39 -0400, Clint Adams [EMAIL PROTECTED] said: On Sun, Oct 07, 2007 at 10:52:45AM -0500, Manoj Srivastava wrote: What does this mean in non-git context? I think truncating the patch-log history is unimportant for Arch, but any ++pristine-trees should definitely be nuked prior to packing. OK, that's fair. I use revision libs, so I never have pristine trees in my working dir anyway. manoj -- Linux is obsolete (Andrew Tanenbaum) Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Manoj Srivastava [EMAIL PROTECTED] writes: How is git reconstituting the files if there is no network access? Are they shipping all the bits needed to get a full working dir without any network access? As I understand it, yes, that's the basic idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 02:19:36PM -0500, Manoj Srivastava wrote:
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
As opposed to an .orig.tar.gz and all the debian/, {arch}/, and
.arch-ids/ components in the .diff.gz ?
How is git reconstituting the files if there is no network
access? Are they shipping all the bits needed to get a full working
dir without any network access?
Yes. the .git/ (or .bzr/ ) directory contains the entire (or abridged
in the case of these shallow clones) history so you can check out any
of the covered revisions.
This would be akin to you including a cachedrev of an arbitrary version
followed by all the subsequent patches.tar.gz files, except that I
believe git et al. are meant to be more space-efficient.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 02:16:12PM -0500, Manoj Srivastava wrote: On Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld [EMAIL PROTECTED] said: On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote: You probably mean source package here and not .deb. Also the original proposal just means shipping the repository data, since most DVCS can easily create a working directory from that. Hmm. The repository data, as far as I can tell, means the name of the archive, and the location. Do you really mean we are not shipping any, say, foo.c file in the sources, just a locatio where you can get the foo.c file from, at a particular version? bzr and git always ship the complete repository with each working directory. This is why they are called distributed. Arch seems to be some weird thing in between truly central and truly distributed VCS. The whole idea of the proposal is to NOT create an export. If we are not creating and export, and we are only shipping the repository data, how come there needs to be a check for uncommitted files? If the changes are uncommitted, that means the repo does not know about it; and if we only ship the repository data, we are not shipping stuff not in the repo. What am I missing? They might be uncommitted because the maintainer forgot to commit them. The only question is whether we should abort, commit the changes, or ignore the changes. There is no technical problem with either of these cases. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
Hi,
On Sun, 7 Oct 2007 15:49:55 -0400, Clint Adams [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 02:19:36PM -0500, Manoj Srivastava wrote:
On Sun, 7 Oct 2007 12:24:46 -0400, Clint Adams [EMAIL PROTECTED] said:
I presume you could ship all the normal files in one tarball, the
.arch-ids and {arch} directories in another, and the debian/ directory
in a third.
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
As opposed to an .orig.tar.gz and all the debian/, {arch}/, and
.arch-ids/ components in the .diff.gz ?
Umm, I was asking about why the normal and the arch-ids and
{arch} directories are being separated, and the ./debian dir as well.
The idea of the wig pen was so that we no longer used diff as
an version control system, or were able to use more than one tar ball
for the source.
How is this working in this proposal? I do not ship the
orig.tar.gz file, but I ship and orig.arch.tar.gz file with the
upstream branch?
Then I mostly duplicate this by shipping a working dir, and each
also somehow ship an delta that recreates the orig.tar.gzx file from
the upstream branch I am shipping?
How is git reconstituting the files if there is no network access?
Are they shipping all the bits needed to get a full working dir
without any network access?
Yes. the .git/ (or .bzr/ ) directory contains the entire (or abridged
in the case of these shallow clones) history so you can check out
any of the covered revisions.
A history as in RCS-like history, with parches, as opposed to
the patch-log that is what the {arch} directories contain?
This would be akin to you including a cachedrev of an arbitrary
version followed by all the subsequent patches.tar.gz files, except
that I believe git et al. are meant to be more space-efficient.
wow.
gulp.
OK, so for arch I suppose I just ship a working dir, period, and
people need network access to get the older versions, unless people
want terabytes of the archive in every source versions.
manoj
--
Mind your own business, Mr. Spock. I'm sick of your halfbreed
interference.
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld [EMAIL PROTECTED] said: On Sun, Oct 07, 2007 at 02:16:12PM -0500, Manoj Srivastava wrote: On Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld [EMAIL PROTECTED] said: On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote: You probably mean source package here and not .deb. Also the original proposal just means shipping the repository data, since most DVCS can easily create a working directory from that. Hmm. The repository data, as far as I can tell, means the name of the archive, and the location. Do you really mean we are not shipping any, say, foo.c file in the sources, just a locatio where you can get the foo.c file from, at a particular version? bzr and git always ship the complete repository with each working directory. This is why they are called distributed. Arch seems to be some weird thing in between truly central and truly distributed VCS. I am not sure I see this. Arch repositories are distributed, and you can pull, branch, and tag off any repository out there in the meta-verse. But every directory also has a semi permanent URI; and checking pout a branch locally does not end up with you downloading the terabytes of stuff in the repo out there. This might be because you can have more than one project in a repo; my repo contains CVS emacs, unicode emacs, as well as most of the SELinux packages, etc, and I mirror partially to arch.d.o. I would hate to see all of emacs in the local dir of people who just want to check out devotee. So arch does have a different mechanism of doing distributed repositories; but the repositories are distributed in the sense that I control one repo, but branches in my repo are children of other repositories, and can be merged and tagged back and from, The whole idea of the proposal is to NOT create an export. If we are not creating and export, and we are only shipping the repository data, how come there needs to be a check for uncommitted files? If the changes are uncommitted, that means the repo does not know about it; and if we only ship the repository data, we are not shipping stuff not in the repo. What am I missing? They might be uncommitted because the maintainer forgot to commit them. The only question is whether we should abort, commit the changes, or ignore the changes. There is no technical problem with either of these cases. Well, as a developer, I would rather that someone else running dpkg source on a package not try to commit to my repo, since it shall fail. Assuming we consider trying to support arch-like distributed version control systems in the new dpkg; it might well be that the current approach is too focussed on git/bzr type version control to work well with arch. manoj -- DEATH: The penultimate commercial transaction finalized by probate. Bernard Rosenberg Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 06:24:15PM -0500, Manoj Srivastava wrote: On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld [EMAIL PROTECTED] said: bzr and git always ship the complete repository with each working directory. This is why they are called distributed. Arch seems to be some weird thing in between truly central and truly distributed VCS. I am not sure I see this. Arch repositories are distributed, and you can pull, branch, and tag off any repository out there in the meta-verse. But every directory also has a semi permanent URI; and checking pout a branch locally does not end up with you downloading the terabytes of stuff in the repo out there. Lets not exagerate. At least for git the repository will usually be smaller or only little larger than the working directory. It will probably compress worse though. This might be because you can have more than one project in a repo; my repo contains CVS emacs, unicode emacs, as well as most of the SELinux packages, etc, and I mirror partially to arch.d.o. I would hate to see all of emacs in the local dir of people who just want to check out devotee. So arch does have a different mechanism of doing distributed repositories; but the repositories are distributed in the sense that I control one repo, but branches in my repo are children of other repositories, and can be merged and tagged back and from, Out of interest, which of the following actions would need remote access? log view (including diffs between revisions) annotation/blame view creating a new commit/revision/tag reverting a dirty working tree to a clean one For git/bzr, the answer is usually no to all of these. If you have a shallow copy in git, the answers to the first two become yes, since you will need it convert to a full copy first . [...] Assuming we consider trying to support arch-like distributed version control systems in the new dpkg; it might well be that the current approach is too focussed on git/bzr type version control to work well with arch. It most probably is. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 06:24:15PM -0500, Manoj Srivastava wrote:
On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld
[EMAIL PROTECTED] said:
bzr and git always ship the complete repository with each working
directory. This is why they are called distributed. Arch seems to
be some weird thing in between truly central and truly distributed
VCS.
I am not sure I see this. Arch repositories are distributed, and you
can pull, branch, and tag off any repository out there in the
meta-verse. But every directory also has a semi permanent URI; and
checking out a branch locally does not end up with you downloading
the terabytes of stuff in the repo out there.
Lets not exagerate. At least for git the repository will usually be
smaller or only little larger than the working directory. It will
probably compress worse though.
How is this magic done? If I have several dozen feature
branches, all feeding back and forth, and have made lots and lots of
changes in my sources, how does git preserve all this information
without a commensurate increase in size? This makes the information
theory geek in me very very skeptical.
Or are you talking about typical usage, and is that why people
go around making shallow copies to cut down on the size of the
shipped repo?
This might be because you can have more than one project in a repo;
my repo contains CVS emacs, unicode emacs, as well as most of the
SELinux packages, etc, and I mirror partially to arch.d.o. I would
hate to see all of emacs in the local dir of people who just want to
check out devotee.
So arch does have a different mechanism of doing distributed
repositories; but the repositories are distributed in the sense that
I control one repo, but branches in my repo are children of other
repositories, and can be merged and tagged back and from,
Out of interest, which of the following actions would need remote
access?
log view (including diffs between revisions)
The ./{arch} directory does contain logs. Diffs between
revisions requires access to the repository (or the local cache
library, if that contains the revision we want to diff with or from)
annotation/blame view
Same thing; you need access to the repo since the code for the
other revisions is not in the checked out directory.
creating a new commit/revision/tag
Committing it would require access to the repo.
reverting a dirty working tree to a clean one
I think you are talking about reverting local changes to the
latest revision from the repository. Well, that needs acess to the
repo or a local cache.
For git/bzr, the answer is usually no to all of these. If you have a
shallow copy in git, the answers to the first two become yes, since
you will need it convert to a full copy first .
For arch, the answer is yes to all these cases.
[...]
Assuming we consider trying to support arch-like distributed version
control systems in the new dpkg; it might well be that the current
approach is too focussed on git/bzr type version control to work well
with arch.
It most probably is.
As far as I can tell, most of the things being done for git are
not required if I ship a working directory for for arch ({arch} and
.arh-ids); and the only other thing required would be to also ship what
lives in the grab file in the control file; so people can know where to
register the archive location from to get access to the other
information.
If people wanted to provide changes, all that is needed is for
them to tag the developers branch, hack, and ask the developers to pull
from their branch (people have done that for ucf and devotee in the
past).
What exactly is the goal of this dpkg addition? With arch, I can
ship a full working copy; and as long as people have the repository
registered, they have full access to older revisions and feature
branches and all.
Would shipping the full working dir get by the requirement of
shipping the diff.gz? If so, we can support arch with no changes to
dpkg whatsoever.
manoj
--
You never hesitate to tackle the most difficult problems.
Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 09:45:20AM -0400, Joey Hess wrote: Anthony Towns wrote: So the logic there would be: if there's an upstream tag, then generate an .orig.tgz if there's a pristine-tar info, hax0r it to be pristine generate a .diff.gz if the .diff failed goto bailout generate a .dsc containing the orig and diff It's not generally possible to generate a .diff.gz that expresses all the changes that might be in a git repository. Right, but it is possible to detect that, and bailout to generating a .tar.gz, no? Repo formats that bzr in etch can unpack could be denoted by Source-Depends: dpkg-bzr (= 0.11) I was thinking about Source-Depends too, the main problem seems to be that it would need to be supported in apt-get source too. I wonder if we could just use build-depends. apt-get source support could just be a warning This package cannot be unpacked without installed. Using Build-Depends: would make it pretty complicated to know which bits were needed for unpacking, if that's all you're trying to do. Cheers, aj signature.asc Description: Digital signature
Re: Next upload 2007-09-30 (dpkg 1.14.7)
Hi, On Fri, 2007-09-28 at 07:06:59 +0300, Guillem Jover wrote: We talked about uploading next version soon, so that we can proceed with the dpkg-shlibdeps rewrite Raphael has been working on. So I'll commit some minor pending issues, try to merge the dpkg-cross stuff, and upload late this weekend. Hmm, this took a bit more than expected, been busy at work and quite tired afterwards most of last week. Will be catching up with the mails this one. About starting the dpkg-cross merge, after some conversations with Neil and reading some of the dpkg-cross code, I think I've got a pretty good idea but needs done, but I've some reservations about the paths used, I'll post a separate mail later. I've deferred it until next version, sorry Neil... regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg 1.14.7 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of dpkg-source's -i and -I options. Closes: #323911, #440956 * Add --utf8-strings to gpg call in dpkg-buildpackage since that seems to be the better default. Suggested by Székelyi Szabolcs. Closes: #379418 * Let dpkg-buildpackage error out early if the version number from the changelog is not a valid Debian version. Closes: #216075 * Fix dpkg-source to create correct diffs for files with spaces in their name (apparantly we don't have many of those ;). Based on a patch by Marcel Toele. Closes: #445380 . [ Updated dpkg translations ] * Basque (Piarres Beobide). Closes: #440859 * Danish (Claus Hindsgaul). Closes: #441106 * French (Frédéric Bothamy). * German (Sven Joachim). Closes: #440537 * Nepali (Shiva Prasad Pokharel). Closes: #437825 * Portuguese (Miguel Figueiredo). Closes: #441113 * Romanian (Eddy Petri?or). * Vietnamese (Clytie Siddall). Closes: #440502 * Korean (Sunjae Park). Closes: #443190 . [ Updated man pages translations ] * German (Helge Kreutzmann). * Swedish (Peter Karlsson). * Korean (Sunjae Park). Closes: #443191 . [ Updated scripts translations ] * Correct a typo in the French translation. Closes: #443276 * Swedish (Peter Karlsson). Files: 95f1bea363e91623bff37c6ca6f7ac27 995 admin required dpkg_1.14.7.dsc 909dbcbab6d77d1af18430336b7cb256 5935888 admin required dpkg_1.14.7.tar.gz e36cfe7a3c85bb13a8e7458696e12fff 2093642 admin required dpkg_1.14.7_i386.deb 99e739b9c8f50f1773555227efcae534 510314 admin required dselect_1.14.7_i386.deb c7af636e7bbea0ee19aaccc8c2c39715 228114 utils optional dpkg-dev_1.14.7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHCbhduW9ciZ2SjJsRAhc0AKC1pZsD622xHuJoR6xaaFVLd8arKACg+G/y 3l/y6E2FB470Q6PsZ1bhoVY= =XsVF -END PGP SIGNATURE- Accepted: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg_1.14.7_alpha.changes ACCEPTED
Accepted: dpkg_1.14.7_alpha.deb to pool/main/d/dpkg/dpkg_1.14.7_alpha.deb dselect_1.14.7_alpha.deb to pool/main/d/dpkg/dselect_1.14.7_alpha.deb Override entries for your package: dpkg_1.14.7_alpha.deb - required admin dselect_1.14.7_alpha.deb - required admin Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382673: [PATCH/RFC] dpkg-source.pl: Support a subset of wigpen on build
On Sun, 2007-10-07 at 03:17:49 +0200, Frank Lichtenheld wrote: On Sat, Oct 06, 2007 at 11:09:21PM +0200, Frank Lichtenheld wrote: Use .orig.tar.(bz2|lzma) if they are available and no .gz can be found. Also let the user specify via -C(gz|bz2|lzma) how files that need to be generated should be compressed. Hmm, I just noticed that dpkg-genchanges already uses -C, so it would be difficult to pass this option down from dpkg-buildpackage. Anyway, the name of the option is not really important at this point, yet. (-z perhaps? Seems to be free) You can use -Z which is the one used for that purpose in dpkg-deb. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: dpkg usertagging and merging
Processing commands for [EMAIL PROTECTED]: user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). usertag 445270 u-a Bug#445270: dpkg: update-alternatives logging There were no usertags set. Usertags are now: u-a. usertag 445552 dpkg-buildpackage Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean There were no usertags set. Usertags are now: dpkg-buildpackage. usertag 441021 u-a Bug#441021: dpkg: update-alternatives breaks config on uninstall There were no usertags set. Usertags are now: u-a. usertag 444341 u-a Bug#444341: update-alternatives doesn't describe the generic names There were no usertags set. Usertags are now: u-a. usertag 440841 dpkg-source Bug#440841: dpkg-dev: source package gpg verification doesn't restrict valid keys to debian-keyring There were no usertags set. Usertags are now: dpkg-source. usertag 440657 s-s-d Bug#440657: dpkg: start-stop-daemon --stop kills process and then complains failed to kill: No such process There were no usertags set. Usertags are now: s-s-d. usertag 427210 dpkg-gencontrol Bug#427210: dpkg-gencontrol: confusing error message when using inofficial architecture There were no usertags set. Usertags are now: dpkg-gencontrol. usertag 437060 u-a Bug#437060: dpkg: [update-alternatives] order --config list alphabetically There were no usertags set. Usertags are now: u-a. usertag 441904 u-a Bug#441904: dpkg: [update-alternatives]: Please add a machine-readable variant of --display There were no usertags set. Usertags are now: u-a. usertag 443535 s-s-d Bug#443535: start-stop-daemon: should offer an option for ionice There were no usertags set. Usertags are now: s-s-d. usertag 443241 u-a Bug#443241: dpkg: slave link for rxvt alternative lost, not being re-created There were no usertags set. Usertags are now: u-a. merge 213907 437409 Bug#213907: Dynamic registration of files to packages Bug#437409: list /etc/default/exim4 Bug#163657: [CONFFILE] dpkg: should support conffile hijacking Bug#234286: debian-policy: log file should be in packages' file list Merged 163657 213907 234286 437409. merge 32877 440640 Bug#32877: [CONFFILE] Cleverer conffile merge Bug#440640: Please introduce a sane way to merge config file differences during package installation Bug#48717: [CONFFILE] dpkg: could be more useful wrt conffile diffs Bug#120152: [CONFFILE] dpkg: Merge changes to conffiles in with sdiff(1) Bug#189805: improvment: use of sdiff to merge configuration-files Bug#247336: allow viewing diff of configuration file changes Bug#268154: [DPKG] should offer configurable diff/merge program Bug#290854: [CONFFILE] add conflict options to start an editor or start a merge Bug#294073: [CONFFILE] add 'R' command to resolve diffs with external program Bug#413436: [CONFFILE] Cleverer conffile merge Merged 32877 48717 120152 189805 247336 268154 290854 294073 413436 440640. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Sat, Oct 06, 2007 at 09:17:21PM +0200, Loïc Minier wrote: Per policy 7.6, build-deps must be available for clean; pbuilder calls dpkg-buildpackage -S to generate a source suitable to be copied into the build environment; by default, this involves cleaning before building the source, but dpkg-checkbuilddeps isn't run before cleaning. I think dpkg-builcpackage should run dpkg-checkbuilddeps and fail at this point when called with -S. Currently, clean might fail if build-deps are unavailable (such as missing patch system package), but this should really be an error detected earlier on. This behaviour is as old as dpkg-checkbuilddeps itself (see cf5d2919f686a15e8e623130b74af3ba2428fbeb in git). Changing the behaviour would obviously be correct, the question is whether it would actually be better. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Processed: setting package to dpkg dpkg-dev dselect, tagging 173463, tagging 427210
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.9 package dpkg dpkg-dev dselect Ignoring bugs not assigned to: dselect dpkg-dev dpkg tags 173463 + pending Bug#173463: [DOC] dpkg-dev: deb-control(5) does not document Bugs: and Origin: There were no tags set. Tags added: pending tags 427210 + pending Bug#427210: dpkg-gencontrol: confusing error message when using inofficial architecture Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392317: dpkg: Empty lines in install/configure output (Setting up ...)
Hi Colin,
On Tue, 2007-10-02 at 16:27:52 +0100, Colin Watson wrote:
On Wed, Oct 11, 2006 at 10:01:43AM +0200, Roland Stigge wrote:
I always wondered which scheme dpkg follows when installing packages
and writing the Setting up ... lines. Sometimes, empty lines are
interspersed.
Looking into the code, the reason is in src/configure.c where a
putchar('\n'); is done when maintainer_script_installed() returns !=
0. Maybe someone wanted to make sure that after execution of
maintainer scripts, a proper CR is done? On the other hand side, all
the other invocations of maintainer_script_installed() (including the
post-installation ones like the above one) don't handle it that way.
I always thought this was useful information; it made it easy to see in
upgrade logs from users when a postinst script was being run (and while
it was a bit inconsistent, postinst scripts are usually the most
interesting case so this was OK).
Could you explain how is the fact that the script is being run
(supposedly w/o errors) useful information or have you found a
particular situation when you used that information?
thanks,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#18567:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427210: marked as done (dpkg-gencontrol: confusing error message when using inofficial architecture)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#427210: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- package: dpkg-dev version: 1.14.4 severity: minor dpkg-gencontol does: grep(debarch_is($host_arch, $_), @archlist) || error(sprintf(_g(current build architecture %s does not. appear in package's list (%s)), $host_arch, @archlist)); which in current unstable results in a confusing error message like: dpkg-gencontrol: error: current build architecture abacus does not appear in package's list (abacus) (I'm using abacus as architecture name in my test-suite, so that the results do not depend on the architecture it is run on). Hochachtungsvoll, Bernhard R. Link ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of
Bug#168160:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#173463: marked as done ([DOC] dpkg-dev: deb-control(5) does not document Bugs: and Origin:)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#173463: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.10.9 Severity: minor deb-control(5) does not mention or document the control fields Origin: and Bugs:, which seem to exist and get used according to the dpkg changelog. Cheers, Bastian -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ap-lnx-bastiank 2.4.20 #1 Mon Dec 16 15:38:10 CET 2002 i686 Locale: LANG=C, [EMAIL PROTECTED] Versions of packages dpkg-dev depends on: ii binutils 2.13.90.0.16-1 The GNU assembler, linker and bina hi cpio 2.5-1 GNU cpio -- a program to manage ar hi make 3.80-1 The GNU version of the make util hi patch 2.5.4-11 Apply a diff file to an original hi perl [perl5] 5.8.0-14 Larry Wall's Practical Extraction hi perl-modules 5.8.0-14 Core Perl modules. -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in
Bug#323911: marked as done (dpkg-dev: [manual] dpkg-buildpackage: Please clarify -i option explanation)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#323911: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.13.11 Severity: wishlist The manual page reads: -i[regexp] You may specify a perl regular expression to match files you want filtered out of the list of files for the diff. (This list is generated by a find command.) -i by itself enables the option, with a default that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. This is very helpful in cutting out extraneous files that get included in the .diff.gz, (eg: debian/BUGS_TODO/* or debian/RCS/*,v). For instance, if you maintain a package that you track via remote CVS, where you don't have access permis- Although the above text says that perl regexps are used, a quick look may confuse reader to take * as shell wind character. Perhaps this could be better worded: This is very helpful in cutting out extraneous files that get included in the .diff.gz. E.g. to exclude + debian/BUGS_TODO/* or debian/RCS/*,v files, one possible + regexp could be 'debian/(BUGS_TODO|RCS)/'. For instance, if you maintain a package that you track via remote CVS, where you don't have access permis- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages dpkg-dev depends on: ii binutils 2.16.1-2 The GNU assembler, linker and bina ii cpio 2.6-3 GNU cpio -- a program to manage ar ii dpkg 1.13.11package maintenance system for Deb ii make 3.80-11The GNU version of the make util ii patch 2.5.9-2Apply a diff file to an original ii perl [perl5] 5.8.7-4Larry Wall's Practical Extraction ii perl-modules 5.8.7-4Core Perl modules Versions of packages dpkg-dev recommends: ii bzip21.0.2-8 high-quality block-sorting file co ii gcc [c-compiler] 4:4.0.1-3 The GNU C compiler ii gcc-2.95 [c-compiler]1:2.95.4-22 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-8 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.1-5 The GNU C compiler ii tcc [c-compiler] 0.9.23-1The smallest ANSI C compiler -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user
Bug#163657:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#12859:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440962: marked as done (/usr/bin/822-date: Can't locate controllib.pl)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440962: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.14.6 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 rangda[/home/sean/debian/libcompizconfig-0.52] /usr/bin/822-date Can't locate controllib.pl in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/bin/822-date line 11. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii cpio 2.9-3 GNU cpio -- a program to manage ar ii dpkg 1.14.6 package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules 5.8.8-7Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-6The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-16 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.1-5The GNU C compiler - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3vvlynjLPm522B0RArAnAJ0URbQUb/DPiDsLGPdr68DiQR1ZtwCeNDrw EcmkEEh7yeBklA3ESLGxnZo= =oYWO -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds,
Bug#163183:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440537: marked as done (dpkg: [INTL:de] German translation update)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440537: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg Severity: wishlist Tags: l10n patch Attached is an updated German translation for the next dpkg release (1.14.6). de.po.bz2 Description: Binary data ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of dpkg-source's -i and -I options. Closes: #323911, #440956 * Add --utf8-strings to gpg call in dpkg-buildpackage since that seems to be the better default. Suggested by Székelyi Szabolcs. Closes: #379418 * Let dpkg-buildpackage error out early if the version number from the changelog is not a valid Debian version. Closes: #216075 * Fix dpkg-source to create correct diffs for files with spaces in their name (apparantly we don't have
Bug#440973: marked as done (dpkg-scanpackages.1.gz: bzip2 vs. gzip)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440973: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.14.5 Severity: minor The dpkg-scanpackages manpage notes: Note: If you want to access the generated Packages file with apt you will probably need to compress the file with gzip(1) (generating a Packages.gz file). apt ignores uncompressed Packages files except on local access (i.e. file:// sources). However APT now seems to require a Packages.bz2 file. Thanks, Jack -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii cpio 2.9-3 GNU cpio -- a program to manage ar ii dpkg 1.14.5 package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules 5.8.8-7Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-16 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.1-5The GNU C compiler -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when
Bug#143302:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443191: marked as done ([INTL:ko] dselect debconf Korean translation update)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#443191: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dselect Version: N/A Severity: wishlist Tags: l10n patch -- Sunjae Park(daréhanl) GPG: 1024D/AAA96037 We choose to go to the moon and do the other things, not because they are easy, but because they are hard. - John F. Kennedy dselect.ko.po.bz2 Description: BZip2 compressed data signature.asc Description: This is a digitally signed message part. ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of dpkg-source's -i and -I options. Closes: #323911, #440956 * Add --utf8-strings to gpg call in dpkg-buildpackage since that seems to be the better default. Suggested by Székelyi Szabolcs. Closes: #379418 * Let dpkg-buildpackage error out early if the
Bug#186809:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379418: marked as done (dpkg-buildpackage: signing .dsc and .changes fails with UTF-8 encoded uid)
Your message dated Mon, 08 Oct 2007 05:17:03 +
with message-id [EMAIL PROTECTED]
and subject line Bug#379418: fixed in dpkg 1.14.7
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: dpkg-dev
Version: 1.13.22
Severity: normal
Tags: patch l10n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Lintian (and Policy?) requires the Debian changelog to be UTF-8
encoded. But if -- for example, -- the maintainer name is encoded this
way, then gpg fails to find the secret key because assumes by default
that the command line parameters are not UTF-8 encoded. Passing
- --utf8-strings to gpg solves the problem.
Patch attached.
Bye,
- --
cc
- -- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.5
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages dpkg-dev depends on:
ii binutils 2.17-1 The GNU assembler, linker and bina
ii cpio 2.6-16 GNU cpio -- a program to manage ar
ii dpkg 1.13.22package maintenance system for Deb
ii make 3.81-2 The GNU version of the make util
ii patch 2.5.9-4Apply a diff file to an original
ii perl [perl5] 5.8.8-6Larry Wall's Practical Extraction
ii perl-modules 5.8.8-6Core Perl modules
Versions of packages dpkg-dev recommends:
ii bzip2 1.0.3-3high-quality block-sorting file co
ii gcc [c-compiler] 4:4.1.1-5 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-13 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.6-4The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.3-5The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.1-9The GNU C compiler
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEw2+iGJRwVVqzMkMRAj4iAKCeeM6oTaZ5SnwwW2PLM7sDJYe4bwCfd2rl
8PfJER8KLNl4zUz8WvhZhRo=
=LJak
-END PGP SIGNATURE-
--- scripts/dpkg-buildpackage.sh.orig 2006-07-23 14:41:08.0 +0200
+++ scripts/dpkg-buildpackage.sh2006-07-23 14:41:57.0 +0200
@@ -172,7 +172,7 @@
signfile () {
if test $signinterface = gpg ; then
(cat ../$1 ; echo ) | \
- $signcommand --local-user ${signkey:-$maintainer} --clearsign
--armor \
+ $signcommand --utf8-strings --local-user
${signkey:-$maintainer} --clearsign --armor \
--textmode ../$1.asc
else
$signcommand -u ${signkey:-$maintainer} +clearsig=on -fast
../$1 \
---End Message---
---BeginMessage---
Source: dpkg
Source-Version: 1.14.7
We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:
dpkg-dev_1.14.7_all.deb
to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb
dpkg_1.14.7.dsc
to pool/main/d/dpkg/dpkg_1.14.7.dsc
dpkg_1.14.7.tar.gz
to pool/main/d/dpkg/dpkg_1.14.7.tar.gz
dpkg_1.14.7_i386.deb
to pool/main/d/dpkg/dpkg_1.14.7_i386.deb
dselect_1.14.7_i386.deb
to pool/main/d/dpkg/dselect_1.14.7_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 08 Oct 2007 07:31:34 +0300
Source: dpkg
Binary: dpkg dselect dpkg-dev
Architecture: source i386 all
Version: 1.14.7
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers [EMAIL PROTECTED]
Changed-By: Guillem Jover [EMAIL PROTECTED]
Description:
dpkg - package maintenance system for Debian
dpkg-dev - package building tools for Debian
dselect- user tool to manage Debian packages
Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636
440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276
444362 445380
Changes:
dpkg
Bug#432893: marked as done (dpkg: Failed install followed by failed remove results in installed state)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#432893: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: libghc6-hslogger-dev Version: 1.0.3 Severity: serious Hi, I don't know all the event leading up to this problem, since I can't even remove some of the current packages, but I now get: Setting up libghc6-hslogger-dev (1.0.3) ... Reading package info from stdin ... done. ghc-pkg: package hslogger-1.0.2 is already installed dpkg: error processing libghc6-hslogger-dev (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: libghc6-hslogger-dev E: Sub-process /usr/bin/dpkg returned an error code (1) ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a default list of pattern similar to -i without regexp. Patch by Jari Aalto. Closes: #440972 * Rework documentation of dpkg-source's -i and -I options. Closes: #323911,
Bug#143307:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323911: marked as done (dpkg-dev: [manual] dpkg-buildpackage: Please clarify -i option explanation)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440956: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.13.11 Severity: wishlist The manual page reads: -i[regexp] You may specify a perl regular expression to match files you want filtered out of the list of files for the diff. (This list is generated by a find command.) -i by itself enables the option, with a default that will filter out control files and directories of the most common revision control systems, backup and swap files and Libtool build output directories. This is very helpful in cutting out extraneous files that get included in the .diff.gz, (eg: debian/BUGS_TODO/* or debian/RCS/*,v). For instance, if you maintain a package that you track via remote CVS, where you don't have access permis- Although the above text says that perl regexps are used, a quick look may confuse reader to take * as shell wind character. Perhaps this could be better worded: This is very helpful in cutting out extraneous files that get included in the .diff.gz. E.g. to exclude + debian/BUGS_TODO/* or debian/RCS/*,v files, one possible + regexp could be 'debian/(BUGS_TODO|RCS)/'. For instance, if you maintain a package that you track via remote CVS, where you don't have access permis- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages dpkg-dev depends on: ii binutils 2.16.1-2 The GNU assembler, linker and bina ii cpio 2.6-3 GNU cpio -- a program to manage ar ii dpkg 1.13.11package maintenance system for Deb ii make 3.80-11The GNU version of the make util ii patch 2.5.9-2Apply a diff file to an original ii perl [perl5] 5.8.7-4Larry Wall's Practical Extraction ii perl-modules 5.8.7-4Core Perl modules Versions of packages dpkg-dev recommends: ii bzip21.0.2-8 high-quality block-sorting file co ii gcc [c-compiler] 4:4.0.1-3 The GNU C compiler ii gcc-2.95 [c-compiler]1:2.95.4-22 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-8 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.1-5 The GNU C compiler ii tcc [c-compiler] 0.9.23-1The smallest ANSI C compiler -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user
Bug#216075: marked as done (Don't care about correct version numbers (until the very end))
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#216075: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg Version: 1.10.15 Severity: normal dpkg-buildbackage checks for debian/changelog version number to late. Meaning, it should check it before starting to build backage, not to mention later on, after hours of compiling package, when its done and building package that, sorry, version number is errenous :( -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux bonifaatsius 2.6.0-test7 #2 Sun Oct 12 23:45:55 EEST 2003 i686 Locale: LANG=et_EE, LC_CTYPE=et_EE (ignored: LC_ALL set to et_EE) Versions of packages dpkg depends on: ii dselect 1.10.15a user tool to manage Debian packa ii libc6 2.3.2-8GNU C Library: Shared libraries an -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields in deb-control.5. Closes: #173463 * Do not replace substvars for build dependencies (it was not supported anyway). . [ Frank Lichtenheld ] * Add _MTN to dpkg-source -i default regex. Suggested by Jari Aalto. * Convert dpkg-buildpackage to a Perl script. Fix some bugs in the new script detected in experimental: Closes: #444362 * dpkg-buildpackage accepts a -jn option now which will set MAKEFLAGS(-jn) and DEB_BUILD_OPTIONS(parallel=n) accordingly. parallel=n in DEB_BUILD_OPTIONS will be passed to MAKEFLAGS as well. Based on an idea by Robert Millan. Closes: #440636 * Allow dpkg-source -I without a pattern which will load a
Bug#441051: marked as done ('man dpkg-deb' 'man start-stop-daemon' typos: seperated themself)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#441051: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg Version: 1.14.6 Severity: minor Tags: patch Found a few typos in '/usr/share/man/man1/dpkg-deb.1.gz' and '/usr/share/man/man8/start-stop-daemon.8.gz', see attached '.diff' files. Hope this helps... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 5.97-5.4 The GNU core utilities ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information --- dpkg-deb.1 2007-09-05 01:18:32.0 -0400 +++ /tmp/dpkg-deb.1 2007-09-06 03:11:53.0 -0400 @@ -97,7 +97,7 @@ specified by the .B \-\-showformat argument. The default format displays the package's name and version -on one line, seperated by a tabulator. +on one line, separated by a tabulator. .TP .BR \-f , \-\-field \fIarchive\fP [\fIcontrol-field-name\fP...] Extracts control file information from a binary package archive. --- start-stop-daemon.8 2007-09-05 01:18:34.0 -0400 +++ /tmp/start-stop-daemon.8 2007-09-06 03:15:29.0 -0400 @@ -213,7 +213,7 @@ .B any reason. This is a last resort, and is only meant for programs that either make no sense forking on their own, or where it's not feasible to add the -code for them to do this themself. +code for them to do this themselves. .TP .BR \-N , \-\-nicelevel \fIint\fP This alters the priority of the process before starting it. ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to
Bug#440636: marked as done (support for parallel builds (dpkg-buildpackage -j N))
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440636: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.13.25 Severity: wishlist Tags: patch Attached patch adds support for parallel builds (dpkg-buildpackage -j N). It is based on the one from bug #355654. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Versions of packages dpkg-dev depends on: ii binutils 2.17-3 The GNU assembler, linker and bina ii cpio 2.6-17 GNU cpio -- a program to manage ar ii dpkg 1.13.25package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules 5.8.8-7Core Perl modules Versions of packages dpkg-dev recommends: ii bcc [c-compiler] 0.16.14-1.4 16-bit x86 C compiler ii bzip21.0.3-6 high-quality block-sorting file co ii gcc [c-compiler] 4:4.1.1-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-5 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.3-7 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-21The GNU C compiler -- no debconf information diff -ur dpkg-1.14.5.old/scripts/dpkg-buildpackage.sh dpkg-1.14.5/scripts/dpkg-buildpackage.sh --- dpkg-1.14.5.old/scripts/dpkg-buildpackage.sh2007-06-19 14:11:37.0 +0200 +++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh2007-09-03 12:20:25.0 +0200 @@ -23,6 +23,7 @@ Options: -rgain-root-command -psign-command + -jN allow N jobs at once. -d do not check build dependencies and conflicts. -D check build dependencies and conflicts. -kkeyid the key to use for signing. @@ -59,6 +60,7 @@ } rootcommand='' +makecommand='make' signcommand= if [ -e $GNUPGHOME ] || [ -e $HOME/.gnupg ] \ command -v gpg /dev/null 21; then @@ -96,6 +98,7 @@ admindir=$value ;; -r*)rootcommand=$value ;; -p*)signcommand=$value ;; + -j*)makecommand=$makecommand -j $value ;; -k*)signkey=$value ;; -d) checkbuilddep=false ;; -D) checkbuilddep=true ;; @@ -220,14 +223,14 @@ if [ -n $desc]; then set -- $@ -C$desc ; fi if [ x$noclean != xtrue ]; then - withecho $rootcommand debian/rules clean + withecho $rootcommand $makecommand -f debian/rules clean fi if [ x$binaryonly = x ]; then cd ..; withecho dpkg-source $passopts $diffignore $tarignore -b $dirn; cd $dirn fi if [ x$sourceonly = x ]; then - withecho debian/rules build - withecho $rootcommand debian/rules $binarytarget + withecho $makecommand -f debian/rules build + withecho $rootcommand $makecommand -f debian/rules $binarytarget fi if [ $usepause = true ] \ ( [ $signchanges != : ] || ( [ -z $binaryonly ] [ $signsource != : ] ) ) ; then @@ -281,7 +284,7 @@ fi if $cleansource; then - withecho $rootcommand debian/rules clean + withecho $rootcommand $makecommand -f debian/rules clean fi echo dpkg-buildpackage: $srcmsg ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier
Bug#440956: marked as done (dpkg: dpkg-source [manual] Clarify text of options -i)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440956: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.14.5 Severity: minor The dpkg-source manual reads: -i[regexp] You may specify a perl regular expression to match files you ... This is very helpful in cutting out extraneous files that get !included in the .diff.gz, (eg: debian/BUGS_TODO/* or !debian/RCS/*,v). For instance, if you maintain a package that you track via remote CVS, where you don't have access permis- sions for committing the debian control files and making tags for cvs-buildpackage(1), it is necessary to perform an extra checkout/update into a directory you keep pristine, to generate ... In the marked lines, these wild cards examples do not constitute a regular expresssions. The text would be better replaced with real regular expression example to suppress mentioned file. SUGGESTION This is very helpful in cutting out extraneous files that get included in the .diff.gz. E.g. to ignore files debian/BUGS_TODO/* and debian/RCS/*,v, the options passed would be -idebian/BUGS_TODO -idebian/RCS. For instance, if you maintain a package that you track via remote CVS, where you don't have access permissions for committing the debian control files and making tags for cvs-buildpackage(1), it is necessary to perform an extra checkout/update into a directory you keep pristine, to generate ... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii cpio 2.9-3 GNU cpio -- a program to manage ar ii dpkg 1.14.5 package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules 5.8.8-7Core Perl modules Versions of packages dpkg-dev recommends: ii bcc [c-compiler]0.16.17-216-bit x86 C compiler ii bzip2 1.0.3-7 high-quality block-sorting file co ii gcc [c-compiler]4:4.2.1-5The GNU C compiler ii gcc-4.0 [c-compiler 4.0.3-7 The GNU C compiler ii gcc-4.1 [c-compiler 4.1.2-16 The GNU C compiler ii gcc-4.2 [c-compiler 4.2.1-4 The GNU C compiler ii tcc [c-compiler]0.9.24~cvs20070502-1 the smallest ANSI C compiler -- no debconf information ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover
Bug#68981:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440972: marked as done (dpkg-dev: [PATHC] dpkg-source: Default value for standalone -I)
Your message dated Mon, 08 Oct 2007 05:17:03 +
with message-id [EMAIL PROTECTED]
and subject line Bug#440972: fixed in dpkg 1.14.7
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: dpkg-dev
Version: 1.14.5
Severity: wishlist
Tags: patch
Here is patch to make -I behave like -i, that is to supply default option
of given standalone.
Available from git repository git://git.cante.net/debian-dpkg.git
Branch: dpkg-source+option-I--default-value
Jari
From ecd6426c05129a17b07d70f400c380e6b82b1040 Mon Sep 17 00:00:00 2001
From: Jari Aalto [EMAIL PROTECTED]
Date: Wed, 5 Sep 2007 22:17:55 +0300
Subject: [PATCH] Make option -I like option -i with default values
- (top level): Introduce variable $diff_I_opt_default_regexp to hold
similar ignore patters for tar(1) as used for option -i.
- (usage): Updated documentation of option -I, which now can
not take optional arguments.
- (while @ARGV): Added case to check alone -I options to
ustilize $diff_I_opt_default_regexp.
---
scripts/dpkg-source.pl | 40 +---
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index 70b4682..aaf22fe 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -31,9 +31,40 @@ my $diff_ignore_default_regexp = '
(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory|\.bzrignore|\.gitignore)$|
# File or directory names that should be ignored
(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg|_darcs|\.git|
-\.shelf|\.bzr(?:\.backup|tags)?)(?:$|/.*$)
+_MTN|\.shelf|\.bzr(?:\.backup|tags)?)(?:$|/.*$)
';
+my $diff_I_opt_default_regexp =
+--exclude=.[#~]*
+--exclude=*[#~]
+--exclude='{arch}'
+--exclude=.a
+--exclude=.arch-ids
+--exclude=.arch-inventory
+--exclude=.bzr
+--exclude=.bzr.backup
+--exclude=.bzr.tags
+--exclude=.bzrignore
+--exclude=.cvsignore
+--exclude=.deps
+--exclude=.git
+--exclude=.gitignore
+--exclude=.hg
+--exclude=.la
+--exclude=.o
+--exclude=.shelf
+--exclude=.so
+--exclude=.svn
+--exclude=.swp
+--exclude=CVS
+--exclude=DEADJOE
+--exclude=RCS
+--exclude=_MTN
+--exclude=_darcs
+;
+
+$diff_I_opt_default_regexp =~ s/#*\s*[\r\n]+//gm;
+
# Take out comments and newlines
$diff_ignore_default_regexp =~ s/^#.*$//mg;
$diff_ignore_default_regexp =~ s/\n//sg;
@@ -129,7 +160,8 @@ Build options:
-q quiet operation, do not print warnings.
-i[regexp] filter out files to ignore diffs of
(defaults to: '%s').
- -Ifilename filter out files when building tarballs.
+ -I[filename] filter out files when building tarballs
+ (defaults to: '%s').
-sa auto select orig source (-sA is default).
-sk use packed orig source (unpack keep).
-sp use packed orig source (unpack remove).
@@ -147,7 +179,7 @@ Extract options:
General options:
-h, --help show this help message.
--versionshow the version.
-), $progname, $diff_ignore_default_regexp;
+), $progname, $diff_ignore_default_regexp, $diff_I_opt_default_regexp;
}
sub handleformat {
@@ -183,6 +215,8 @@ while (@ARGV $ARGV[0] =~ m/^-/) {
$diff_ignore_regexp = $1 ? $1 : $diff_ignore_default_regexp;
} elsif (m/^-I(.+)$/) {
push @tar_ignore, --exclude=$1;
+} elsif (m/^-I$/) {
+push @tar_ignore, $diff_I_opt_default_regexp;
} elsif (m/^-V(\w[-:0-9A-Za-z]*)[=:]/) {
$substvar{$1}= $';
} elsif (m/^-T/) {
--
1.5.3.rc5
From 40ace6ceb9af98862f886bec91d1f7325a7e13ce Mon Sep 17 00:00:00 2001
From: Jari Aalto [EMAIL PROTECTED]
Date: Wed, 5 Sep 2007 22:23:15 +0300
Subject: [PATCH] Document new -I option behavior (standalone)
---
man/dpkg-source.1 | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/man/dpkg-source.1 b/man/dpkg-source.1
index e83156f..527179b 100644
--- a/man/dpkg-source.1
+++ b/man/dpkg-source.1
@@ -126,12 +126,19 @@ from the ones in your working directory, thus causing
them to be
unnecessarily included in every .diff.gz, unless you use the \fB\-i\fR
switch.
.TP
-.BI \-I filename
-If this option is specified, the filename will be passed to tar's \-\-exclude
-option when it is called to generate a .orig.tar.gz or .tar.gz file. For
-example, \-ICVS will make tar skip over CVS directories when generating
-a .tar.gz file. The option may be repeated multiple times to list
Bug#128560:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441359: marked as done (822-date can't locate controllib.pl)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#440962: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dh-make Version: 0.43 Severity: normal I'm using dh-make to create a new package with : 'dh_make -f ../Upstream-tarball.tar.gz' and dh-make is'nt parsing the date info, so debian/changelog annd debiand/copyright does'nt show info about date/time I check my local conf and IMHO seens right anyway, I try with a clean chroot environment with pbuilder and I have de same problem (this info is with root since I do with pbuilder --login just for confirm) -- dh_make -f ../ Type of package: single binary, multiple binary, library, kernel module or cdbs? [s/m/l/k/b] s Maintainer name : root Email-Address : [EMAIL PROTECTED] Date: ^^ Date and time should be here --- System information. --- Architecture: amd64 Kernel: Linux 2.6.22-1-amd64 Debian Release: lenny/sid 500 unstableftp.debian.org --- Package information. --- Depends(Version) | Installed -+-=== debhelper (= 5) | 5.0.53 make | 3.81-3 perl | 5.8.8-7 dpkg-dev | 1.14.6 Cheers -- Rene Mauricio Mayorga | GPG: A209C305 http://rmayorga.org | -- 08B6 58AB A691 DD56 C30B 8D37 8040 19FA A209 C305 signature.asc Description: Esta parte del mensaje está firmada digitalmente ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to Packages.gz. Closes: #440973 * Stop recognizing the obsolete Optional field when building packages. * Use fakeroot, if present, by default to gain root privileges in dpkg-buildpackage. * Fix typos in dpkg-deb.1 and start-stop-daemon.8. Closes: #441051 Thanks to A. Costa. * After 'prerm remove' fails and while doing the error unwinding, if the 'postinst abort-remove' call succeeds, preserve the old status instead of unconditionally setting it to 'Installed'. Closes: #432893 Thanks to Brian M. Carlson. * Add Vcs-Browser and Vcs-Git fields to debian/control. * Add a Homepage field to debian/control (to be changed later when there's a more formal site). * Allow comparing unsupported architectures for equality and identity. Based on a patch by Frank Lichtenheld. Closes: #427210 * Document Origin and Bugs fields
Bug#175740:
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444362: marked as done (dpkg-dev: dpkg-buildpackage fails in experimental chroot)
Your message dated Mon, 08 Oct 2007 05:17:03 + with message-id [EMAIL PROTECTED] and subject line Bug#444362: fixed in dpkg 1.14.7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: dpkg-dev Version: 1.14.7~newshlib.1 Severity: important debian:/gfire-trunk# LANG=C linux32 dpkg-buildpackage dpkg-buildpackage: source package gaim-xfire dpkg-buildpackage: source version 0.7.0-trunk0 dpkg-buildpackage: source changed by Peter Green [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 debian/rules clean Can't exec : No such file or directory at /usr/bin/dpkg-buildpackage line 324. dpkg-buildpackage: failure: debian/rules clean failed with unknown exit code -1 debian:/gfire-trunk# downgrading dpkg-dev to unstable's version makes the package build fine. Running debian/rules clean manually also works fine. -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.18-1The GNU assembler, linker and bina ii cpio 2.9-3 GNU cpio -- a program to manage ar ii dpkg 1.14.7~newshlib.1 package maintenance system for Deb ii make 3.81-3The 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-11 Larry Wall's Practical Extraction ii perl-modules 5.8.8-11 Core Perl modules Versions of packages dpkg-dev recommends: pn bzip2 none (no description available) ii gcc [c-compiler]4:4.3-20070902-0 The GNU C compiler ii gcc-4.3 [c-compiler]4.3-20070902-1 The GNU C compiler -- debconf information: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = en_GB.UTF-8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). ---End Message--- ---BeginMessage--- Source: dpkg Source-Version: 1.14.7 We believe that the bug you reported is fixed in the latest version of dpkg, which is due to be installed in the Debian FTP archive: dpkg-dev_1.14.7_all.deb to pool/main/d/dpkg/dpkg-dev_1.14.7_all.deb dpkg_1.14.7.dsc to pool/main/d/dpkg/dpkg_1.14.7.dsc dpkg_1.14.7.tar.gz to pool/main/d/dpkg/dpkg_1.14.7.tar.gz dpkg_1.14.7_i386.deb to pool/main/d/dpkg/dpkg_1.14.7_i386.deb dselect_1.14.7_i386.deb to pool/main/d/dpkg/dselect_1.14.7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Guillem Jover [EMAIL PROTECTED] (supplier of updated dpkg package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 08 Oct 2007 07:31:34 +0300 Source: dpkg Binary: dpkg dselect dpkg-dev Architecture: source i386 all Version: 1.14.7 Distribution: unstable Urgency: low Maintainer: Dpkg Developers [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: dpkg - package maintenance system for Debian dpkg-dev - package building tools for Debian dselect- user tool to manage Debian packages Closes: 173463 216075 323911 379418 427210 432893 437825 440502 440537 440636 440859 440956 440962 440972 440973 441051 441106 441113 443190 443191 443276 444362 445380 Changes: dpkg (1.14.7) unstable; urgency=low . [ Guillem Jover ] * Add back $dpkglib into @INC, needed by the controllib.pl require in 822-date. Closes: #440962 * Document in dpkg-scanpackages that apt now requires Packages.bz2 in preference to
