Joey Hess [EMAIL PROTECTED] writes:
...
However, stashing away uncommitted changes and not including them in the
build violates least suprise. I'd except to see them either commited
automatically, or the current error forcing me to resolve them before
building. The advantage to
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
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.
I've now added
Frank Lichtenheld wrote:
I've now added this branch to the official dpkg repository on alioth
with the intention to work on it. I've at least fixed it up so that
it works with the current code base.
Excellent. I had kept it merged to master, but haven't checked that it's
not bit-rotted lately.
On Tue, Oct 16, 2007 at 01:42:06PM -0400, Joey Hess wrote:
Phillip Susi wrote:
Joey Hess wrote:
A sample dpkg source package built using this is at
http://kitenet.net/~joey/tmp/git-demo/. This demo package includes only
the last 200 commits to the dpkg git repo, so it's more than 1 mb
On Wed, Oct 17, 2007 at 05:24:10PM -0400, Phillip Susi wrote:
Exactly... it seemed to be an 8 MB difference though, which would
account for why the git repo was smaller; it started with 8 MB less
files. My point is that git doesn't magically make the same set of
files plus their history
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
On Mon, 15 Oct 2007 17:55:13 +0100, Ian Jackson [EMAIL PROTECTED] said:
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
Well, this is tricky. I am not sure how the NMU'er
Phillip Susi wrote:
Joey Hess wrote:
A sample dpkg source package built using this is at
http://kitenet.net/~joey/tmp/git-demo/. This demo package includes only
the last 200 commits to the dpkg git repo, so it's more than 1 mb
*smaller*
than dpkg's normal .tar.gz!
What was removed from
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
Well, this is tricky. I am not sure how the NMU'er communicates
with the developer; I assume it is by sending in a diff. If so, this
works with an arch checked out dir, and unmodified dpkg.
Ideally
On Tue, Oct 09, 2007 at 06:58:19PM +0100, Ian Jackson wrote:
[...] Goals I would suggest:
* Abolish dpatch (and similar excresences) and specifically to get
back to the point where a Debian source package can be unpacked to
the point of seeing the source code without having to execute any
Ian Jackson wrote:
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
What exactly is the goal of this dpkg addition?
This is a sensible question to ask. Goals I would suggest:
I find myself wondering the same thing. It seems to me that one
* Phillip Susi [Wed, 10 Oct 2007 14:25:46 -0400]:
Why go into it half assed by packaging git inside the old format?
Because otherwise the change won't happen (TM).
--
Adeodato Simó dato at net.com.org.es
Debian Developer
Adeodato Simó wrote:
* Phillip Susi [Wed, 10 Oct 2007 14:25:46 -0400]:
Why go into it half assed by packaging git inside the old format?
Because otherwise the change won't happen (TM).
Why is that a bad thing? What good does it do to have the git repo
packed inside the source archive?
Phillip Susi wrote:
Why is that a bad thing? What good does it do to have the git repo packed
inside the source archive?
http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/
--
see shy jo, over and over, and out
signature.asc
Description: Digital
Hi,
On Wed, 10 Oct 2007, Phillip Susi wrote:
Adeodato Simó wrote:
* Phillip Susi [Wed, 10 Oct 2007 14:25:46 -0400]:
Why go into it half assed by packaging git inside the old format?
Because otherwise the change won't happen (TM).
Why is that a bad thing? What good does it do to have the
Raphael Hertzog wrote:
Because Debian is all about cooperation and making the git repository
available is an essential step in the process. We currently use
alioth.debian.org for that purpose but it's not related to our standard
packaging process and the logic to go further is either the idea of
On Tue, 9 Oct 2007 14:17:17 +1000, Anthony Towns [EMAIL PROTECTED] said:
So that leaves:
I still think that shipping a full working dir, with no dpkg changes,
seem to be the way to go, along with a tla grab file, which I think I
should consider putting into the package itself (If I can work
Firstly I'd just like to say that I think this is a fantastic
direction to be heading in. I look forward very much to the demise of
dpatch :-).
I do however very much share Colin's view about the desirability of
preserving the .orig.tar.gz's, the ability to unpack a Debian source
package with
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
What exactly is the goal of this dpkg addition?
This is a sensible question to ask. Goals I would suggest:
* Enable all people who work with a Debian source package to do so
with the benefits
Ian Jackson wrote:
How about we ship the .orig.tar.gz, plus an rsync batched update (with
a suitably early rsync version) which turns the unpacked source into
working tree plus revision history ?
I'm afraid that due to consisting of many small gzipped compontents,
.git is not ameanable to
FWIW, I listed my goals and reasons for working on this in the blog post
linked to in the head of this thread.
I feel that I should bow out of this thread here. I've presented an
idea, a working implementation, and addressed the issues with it to the
best of my ability. Far too many times in this
On Tue, 9 Oct 2007 16:42:38 -0400, Joey Hess [EMAIL PROTECTED] said:
FWIW, I listed my goals and reasons for working on this in the blog
post linked to in the head of this thread.
I feel that I should bow out of this thread here. I've presented an
idea, a working implementation, and
On Tue, 9 Oct 2007 18:58:19 +0100, Ian Jackson
[EMAIL PROTECTED] said:
I am going to comment on this with my I use arch hat on.
Manoj Srivastava writes (Re: [PATCH] proposed v3 source format using
.git.tar.gz):
What exactly is the goal of this dpkg addition?
This is a sensible
On Sun, Oct 07, 2007 at 10:59:18PM -0500, Manoj Srivastava wrote:
On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld [EMAIL PROTECTED]
said:
Lets not exagerate. At least for git the repository will usually be
smaller or only little larger than the working directory. It will
probably
Joey Hess [EMAIL PROTECTED] writes:
Frank Lichtenheld wrote:
This should probably error out. Aren't v3 packages always native in the
sense tested here?
Not necessarily. I wanted to leave the option open to use wig-n-pen to
constuct mixed source packages that maybe use vcs for debian/ and
On Mon, Oct 08, 2007 at 12:59:52PM +0200, Frank Lichtenheld wrote:
On Sun, Oct 07, 2007 at 10:59:18PM -0500, Manoj Srivastava wrote:
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,
On Mon, 8 Oct 2007 12:59:52 +0200, Frank Lichtenheld [EMAIL PROTECTED] said:
On Sun, Oct 07, 2007 at 10:59:18PM -0500, Manoj Srivastava wrote:
On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld
[EMAIL PROTECTED] said:
Lets not exagerate. At least for git the repository will usually be
On Mon, Oct 08, 2007 at 09:16:52AM -0500, Manoj Srivastava wrote:
In any case, I think the kinds of actions taken by joey's and
Colin's patches are probably not things that we'll have to do to
support shipping an arh working directory in the source packagel if we
have {arch} and
On Tue, 9 Oct 2007 01:10:00 +1000, Anthony Towns [EMAIL PROTECTED] said:
On Mon, Oct 08, 2007 at 09:16:52AM -0500, Manoj Srivastava wrote:
In any case, I think the kinds of actions taken by joey's and Colin's
patches are probably not things that we'll have to do to support
shipping an arh
On Mon, Oct 08, 2007 at 03:59:05PM -0500, Manoj Srivastava wrote:
Where it starts becoming relevant (afaics) is when there's a
Debian-specific patch history (either due to it being a native
package, complicated packaging, or significant patches against
upstream) and we want the archive, as
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
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
* 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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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),
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
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
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
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
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
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
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,
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
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
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/,
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
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
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
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
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
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
Here's an updated patch, full diff from head again, with:
- use git-config --null
- git-config --filename only needs a full path if not run from a git WC
- import the VCS module so it can check if the VCS is available
- fix all commands that spawn a subshell
- delete the reflog
--
see shy jo
Russ Allbery wrote:
It's a little disturbing to have content in parentheses be significant in
a format based on RFC 822, although we have broken this rule elsewhere
(most notably in dependency fields, of course).
If it helps, the (git) comment is only used in debian/control, it's
not put in
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. The idea is that a source package has only a .dsc and a
.git.tar.gz, which is just a git repo.
Is a .gitdiff.tar.gz possible, so the archive
Anthony Towns wrote:
Is a .gitdiff.tar.gz possible, so the archive doesn't need to have the
full git repo replaced by each upload? ie, something like
Files:
foo_1.0-1.git.tar.gz
foo_1.0-2.gitdiff.tar.gz
so that a small patch only adds a small file to the
Joey Hess 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
Joey Hess wrote:
Bonus points: rather than debian/rules clean, create a diff, build,
have dpkg do debian/rules clean, commit any uncommitted changes with the
commit message being the changes from the changelog, create a .git.tgz,
build for git-source-format packages.
I have a feeling
On Sat, Oct 06, 2007 at 05:27:04PM +1000, Anthony Towns wrote:
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
This means you can't build the package by hand with standard unix tools
-- at the very least you need git installed, and if other VC systems
are to be supported, you need
On Sat, Oct 06, 2007 at 11:19:43AM -0400, Joey Hess wrote:
Anthony Towns wrote:
Is a .gitdiff.tar.gz possible, so the archive doesn't need to have the
full git repo replaced by each upload? ie, something like
Files:
foo_1.0-1.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. The idea is that a source package has only a
.dsc and a .git.tar.gz, which is just a git repo.
So, I can't stand git's user interface. I
On Sat, Oct 06, 2007 at 11:17:58PM +0200, Frank Lichtenheld wrote:
On Sat, Oct 06, 2007 at 05:27:04PM +1000, Anthony Towns wrote:
This means you can't build the package by hand with standard unix tools
-- at the very least you need git installed, and if other VC systems
are to be supported,
On Sat, Oct 06, 2007 at 10:37:48PM +, Colin Watson wrote:
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. The idea is that a source package has only a
.dsc and a .git.tar.gz, which is
Frank Lichtenheld wrote:
I think there is a mechanism in git to disallow replacing old pack
files (i.e. forcing to create additional ones with only new objects),
however, I haven't used that myself, yet.
The packs in the diff package would be basically the same packs that
git-send-pack
Colin Watson wrote:
So, I can't stand git's user interface. I generally try to avoid making
a huge issue of this since it seems to be massively political on places
like Planet at the moment, there seems to be a certain amount of
confusion of people's personal opinions with that of their
Frank Lichtenheld wrote:
I guess if we use Joey's idea at all we will not be able to avoid
shipping such a module for each distributed VCS, and I didn't get
the impression that Joey thought otherwise.
I do think otherwise. If the distributed (or other) VCS does not meet
our criteria for
On Sat, Oct 06, 2007 at 11:19:43AM -0400, Joey Hess wrote:
Anthony Towns wrote:
Changes in repository formats will presumably result in versioned
dependencies too.
I don't think that dpkg should add vcs formats that we don't have a good
expectation of remaining supported by newer versions
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
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.
I've blogged[1] about some of what led me to this idea, and I've also written
a short FAQ[2]. Suggest reading
Joey Hess [EMAIL PROTECTED] writes:
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
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
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.
A little code
One thing I forgot:
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
@@ -825,14 +881,17 @@ if ($opmode eq 'build') {
if ($native) {
warning(_g(multiple tarfiles in native package)) if @tarfiles 1;
warning(_g(native package with .orig.tar))
- unless
Thanks a lot for the code review. Any comments on the big picture or design?
Frank Lichtenheld wrote:
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
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
Frank Lichtenheld wrote:
One thing I forgot:
On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
@@ -825,14 +881,17 @@ if ($opmode eq 'build') {
if ($native) {
warning(_g(multiple tarfiles in native package)) if @tarfiles 1;
warning(_g(native package with
86 matches
Mail list logo
