* martin f krafft [Sat, 22 Nov 2008 14:57:37 +0100]:
> As I said in the other mail, ikiwiki does not really do attachments
> yet, I think.
ikiwiki (2.52) unstable; urgency=low
* attachment: New plugin for uploading and managing attachments.
This includes a fairly powerful PageSpec based ad
also sprach Sam Liddicott <[EMAIL PROTECTED]> [2008.11.19.1648 +0100]:
> No, just a few scripts.
Hm, I am not sure you can, yet. For now, I could add them to the Git
repo (unless you wanted to do that) as plain-text.
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian develope
also sprach Sam Liddicott <[EMAIL PROTECTED]> [2008.11.19.1533 +0100]:
> err how shall I post it for comment?
As I said in the other mail, ikiwiki does not really do attachments
yet, I think. If someone wanted to work out how to do that, let me
know your alioth.debian.org username and I can ad
also sprach Sam Liddicott <[EMAIL PROTECTED]> [2008.11.19.1533 +0100]:
> A set of patches between the source tar and the target released is
> automatically generated, coping with merging and branching by
> selecting the paths that have the most number of commits - as was
> done for the bitkeeper ex
* Philipp wrote, On 19/11/08 15:36:
> Hi Sam,
>
> Sam Liddicott wrote:
>> err how shall I post it for comment?
>
> If it's not too long, just attach the plain bash script to a mail here.
> Otherwise maybe just post it in the wiki at http://vcs-pkg.org/ ?
I can create new wiki pages, how do I ad
Hi Sam,
Sam Liddicott wrote:
> err how shall I post it for comment?
>
If it's not too long, just attach the plain bash script to a mail here.
Otherwise maybe just post it in the wiki at http://vcs-pkg.org/ ?
Or does it need a lot of supporting infrastructure ?
Bye,
Philipp
_
Sam Liddicott said on Wed, Nov 19, 2008 at 02:45:13PM -:
> Yes that is interesting, I think there could be a lot of overlap.
I also thought so ;-)
> Maybe the package maintainer could have their own git branch with the
> distro's extra patches in it.
Indeed. The way I use it myself is with
* Bruno Cornec wrote, On 19/11/08 14:37:
> Sam Liddicott said on Wed, Nov 19, 2008 at 02:33:09PM -:
>
>
>> I'm lately playing with building rpm's from GIT and SVN repositories.
>>
>
> You may find what I'm doing around project-builder interesting then. I'd
> be happy to receive feedback
Sam Liddicott said on Wed, Nov 19, 2008 at 02:33:09PM -:
> I'm lately playing with building rpm's from GIT and SVN repositories.
You may find what I'm doing around project-builder interesting then. I'd
be happy to receive feedbacks ... and contributions ;-)
Cf: http://trac.project-builder.or
I've been using CVS, SVN, QUILT and GIT over 10 years.
I'm lately playing with building rpm's from GIT and SVN repositories.
I have a nice set of scripts called make-srpm (with a git helper and a
less mature svn helper).
The scripts will export a "pristine" source and a set of patches from
the a
On Thu, 2008-11-13 at 10:11 -0500, James Westby wrote:
> > No, why? Short commit IDs are usually enough in Git.
>
> Why not use [f] then?
>
> The short ID may be unambiguous when you create the entry, but it's not
> future proof. The chances of a collision increase over time.
Right, but every d
also sprach Petr Baudis <[EMAIL PROTECTED]> [2008.11.14.1301 +0100]:
> > In the long run, I really want to supersede "Closes:" anyway.
> > Ideally, the bug gets marked 'fix-committed' when a signed-off
> > commit closing the bug hits the repo (or a tag like
> > closes-123456 appears), and an upload
* martin f krafft [Fri, 14 Nov 2008 07:42:02 +0100]:
> Yes, but we are talking about commits, about changes which resolve
> a given bug. It's only SVN's limitation that you cannot do 'svn show
> r123' and get what you want to see.
% svn diff -c 123
HTH,
--
Adeodato Simó
On Fri, Nov 14, 2008 at 07:47:06AM +0100, martin f krafft wrote:
> In the long run, I really want to supersede "Closes:" anyway.
> Ideally, the bug gets marked 'fix-committed' when a signed-off
> commit closing the bug hits the repo (or a tag like closes-123456
> appears), and an upload would ident
On Fri, Nov 14, 2008 at 07:42:02AM +0100, martin f krafft wrote:
> also sprach Martin Bähr <[EMAIL PROTECTED]> [2008.11.13.1540 +0100]:
> > On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote:
> > > Except, of course, there is no such thing as an SVN-Commit. r123
> > > is a state, a sna
On Thu, Nov 13, 2008 at 10:11:15AM -0500, James Westby wrote:
> > > You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you?
> > No, why? Short commit IDs are usually enough in Git.
> Why not use [f] then?
Well, even thought the likelihood of clashes increase trivially with
time, we are in t
also sprach James Westby <[EMAIL PROTECTED]> [2008.11.13.1611 +0100]:
> The short ID may be unambiguous when you create the entry, but
> it's not future proof. The chances of a collision increase over
> time. You could disambiguate collisions by walking the history
> from the root and finding the f
also sprach Petr Baudis <[EMAIL PROTECTED]> [2008.11.13.1540 +0100]:
> On Thu, Nov 13, 2008 at 01:28:17PM +0100, Manuel Prinz wrote:
> > Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
> > > Though I agree with your reasoning here, I find (2) a tad too verbose
> > > (mostly becaus
also sprach Martin Bähr <[EMAIL PROTECTED]> [2008.11.13.1540 +0100]:
> On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote:
> > Except, of course, there is no such thing as an SVN-Commit. r123
> > is a state, a snapshot, the commit if the diff against r-1.
> > I think hg is like Git
>
On Thu, 2008-11-13 at 08:00 +0100, martin f krafft wrote:
> also sprach James Westby <[EMAIL PROTECTED]> [2008.11.12.1709 +0100]:
> > You mean
> >
> >[fc5473a06be960382582ddbfb40e2a5f824be122]
> >
> > don't you?
>
> No, why? Short commit IDs are usually enough in Git.
Why not use [f] then?
On Thu, Nov 13, 2008 at 01:28:17PM +0100, Manuel Prinz wrote:
> Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
> > Though I agree with your reasoning here, I find (2) a tad too verbose
> > (mostly because of the colon appearing twice, which requires two passes
> > from your brain
On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote:
> Except, of course, there is no such thing as an SVN-Commit. r123 is
> a state, a snapshot, the commit if the diff against r-1. I think hg
> is like Git
well, in git the commit-ids also represent the state of the whole tree
like in
also sprach Manuel Prinz <[EMAIL PROTECTED]> [2008.11.13.1328 +0100]:
> If it should be clear to someone outside of Debian (packaging), the
> notation "{Git,SVN,Hg,*}-Commit" might also be reasonable, as it shows
> that the entry has something to do with a VCS commit.
Except, of course, there is n
On Thu, Nov 13, 2008 at 12:54:03PM +0100, Adeodato Simó wrote:
> > 2) (Closes: #1234567, Commit: git:fba134)
>
> Though I agree with your reasoning here, I find (2) a tad too
> verbose (mostly because of the colon appearing twice, which requires
> two passes from your brain, if you see what I mean
Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
> Though I agree with your reasoning here, I find (2) a tad too verbose
> (mostly because of the colon appearing twice, which requires two passes
> from your brain, if you see what I mean). May I suggest:
>
> 3) (Closes: #123456
* Stefano Zacchiroli [Thu, 13 Nov 2008 12:41:33 +0100]:
> On Thu, Nov 13, 2008 at 11:22:56AM +0100, martin f krafft wrote:
> > But instead of one parser, I'd really rather think of it as a number
> > of parsers, each getting a chance. So Closes would be handled by the
> > dak-bts parser, and Git:
On Thu, Nov 13, 2008 at 11:22:56AM +0100, martin f krafft wrote:
> But instead of one parser, I'd really rather think of it as a number
> of parsers, each getting a chance. So Closes would be handled by the
> dak-bts parser, and Git: by a git parser, SVN: by an SVN parser,
> etc.
Consider the foll
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.11.13.1109 +0100]:
> OK, but note that there are drawbacks. For example if we go for
> "(Git:af14e5)" that would be annoying, as parsing will depend on the
> number of supported, or "known", VCS. That was a wrong design choice
> of Vcs-* whic
On Thu, Nov 13, 2008 at 10:40:15AM +0100, Guido Günther wrote:
> I don't have a need for it either - just iff we want to have a
> qualifier inside the braces we should at least use the type of VCS
> not only "Commit:".
OK, but note that there are drawbacks. For example if we go for
"(Git:af14e5)"
On Thu, Nov 13, 2008 at 10:36:05AM +0100, Stefano Zacchiroli wrote:
> On Thu, Nov 13, 2008 at 09:03:32AM +0100, Guido Günther wrote:
> > If we really want a tag in front of the commit identifier we should
> > specify the VCS: [Git:fed3f3d], [Svn:r1234], [Hg:fed3f3d] this would
> > help in the case
On Thu, Nov 13, 2008 at 09:03:32AM +0100, Guido Günther wrote:
> If we really want a tag in front of the commit identifier we should
> specify the VCS: [Git:fed3f3d], [Svn:r1234], [Hg:fed3f3d] this would
> help in the case where a package switches VCSs.
>
> > Finally, I missed if the aim is findi
also sprach Guido Günther <[EMAIL PROTECTED]> [2008.11.13.0903 +0100]:
> If we really want a tag in front of the commit identifier we should
> specify the VCS: [Git:fed3f3d], [Svn:r1234], [Hg:fed3f3d] this would
> help in the case where a package switches VCSs.
... except we wouldn't have the old
On Wed, Nov 12, 2008 at 11:09:45AM -0500, James Westby wrote:
> On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote:
> > also sprach Guido Günther <[EMAIL PROTECTED]> [2008.11.08.1419 +0100]:
> > > Does this look like a worthwhile extension to the current changelog
> > > format? For me it make
On Wed, Nov 12, 2008 at 01:20:10PM +0100, Stefano Zacchiroli wrote:
> Following the (good) path of "Closes", it should probably be something
> like "[Commit: fed3f3d]". Also, can't it be put inside the same
> parentheses than "Closes", as in "(Closes: #7005180, #7005181; Commit:
> fed3f3d)".
If we
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.11.12.1320 +0100]:
> Following the (good) path of "Closes", it should probably be
> something like "[Commit: fed3f3d]". Also, can't it be put inside
> the same parentheses than "Closes", as in "(Closes: #7005180,
> #7005181; Commit: fed3f3d)"
* James Westby [Wed, 12 Nov 2008 11:09:45 -0500]:
> How would this differ from using annotate on the changelog? Do some
> people write the changelog at the end?
I think that's what git-dch(1) does.
--
Adeodato Simó dato at net.com.org.es
Debian Developer
On Wed, Nov 12, 2008 at 11:09:45AM -0500, James Westby wrote:
> On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote:
> > also sprach Guido Günther <[EMAIL PROTECTED]> [2008.11.08.1419 +0100]:
> > > Does this look like a worthwhile extension to the current changelog
> > > format? For me it make
On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote:
> also sprach Guido Günther <[EMAIL PROTECTED]> [2008.11.08.1419 +0100]:
> > Does this look like a worthwhile extension to the current changelog
> > format? For me it makes reviewing changes a lot easier.
>
> I think this is very important
On Wed, Nov 12, 2008 at 08:39:05AM +0100, martin f krafft wrote:
> So, similar to how we close bugs, how about
> * fixed segfault during daemon startup (Closes: #7005180) [fed3f3d]
> instead?
Following the (good) path of "Closes", it should probably be something
like "[Commit: fed3f3d]". Also, c
also sprach Guido Günther <[EMAIL PROTECTED]> [2008.11.08.1419 +0100]:
> Does this look like a worthwhile extension to the current changelog
> format? For me it makes reviewing changes a lot easier.
I think this is very important to have, but why put them at the
front? Changelogs are for consumpti
Hi,
I think i'd be nice if once could link changelog entries back to VCS
commits more easily (to see how a bug actually got fixed). Git-dch has
support for including parts of the SHA1 for some time so together with
Vcs-Browser we can easily link back to the VCS:
http://honk.sigxcpu.org/con/Linking
On Wed, Oct 01, 2008 at 03:14:12PM -0500, Manoj Srivastava wrote:
> ,
> | base_dir=$(git-rev-parse --show-cdup 2>/dev/null) || return 1
> | if [[ -n "$base_dir" ]]; then
> | base_dir=$(readlink -f "$base_dir")
> | else
> | base_dir=$PWD
> | fi
> `
>
>
On Wed, Oct 01 2008, Guido Günther wrote:
> On Wed, Oct 01, 2008 at 08:33:56AM -0500, Manoj Srivastava wrote:
>> On Wed, Oct 01 2008, Guido Günther wrote:
>>
>> > Patches are easily accesible from within gitweb (using Vcs-Browser) when
>> > the package uses git-dch to generate the changelog. Git-
On Wed, Oct 01, 2008 at 08:33:56AM -0500, Manoj Srivastava wrote:
> On Wed, Oct 01 2008, Guido Günther wrote:
>
> > Patches are easily accesible from within gitweb (using Vcs-Browser) when
> > the package uses git-dch to generate the changelog. Git-dch allows to
> > store the abbreviated commit id
On Wed, Oct 01 2008, Guido Günther wrote:
> Patches are easily accesible from within gitweb (using Vcs-Browser) when
> the package uses git-dch to generate the changelog. Git-dch allows to
> store the abbreviated commit id in the changelog so people can find
> patches easily by looking at the chan
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.10.01.0302 +0200]:
> This is a strawman, really. The options are not the giant big
> diff vs quilt (equally horrible, IMHO). The options are 3.0 (quilt) vs
> 3.0 (git). I would have gone for the 3.0 (git) format myself, except
> that
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.10.01.0302 +0200]:
> Only if you like working with patch series, and prefer to lose
> all the information that the original VCS contained. I prefer to see
> the whole history, not just a snapshot, when I am joining a development
> ef
Manoj Srivastava wrote:
> Only if you like working with patch series, and prefer to lose
> all the information that the original VCS contained. I prefer to see
> the whole history, not just a snapshot, when I am joining a development
> effort.
I agree.
>
>> I find it quite unenviable
On Tue, Sep 30, 2008 at 10:27:13PM +0200, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
> > Not really. I prefer to have the source packages be unpackged
> > even on a machine which does not run Debian, using just plain old tar
> > and patch. Thus
On Wed, Oct 01 2008, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 04:50:21PM -0500, Manoj Srivastava wrote:
>> With a patch series that changes slowly from release to release,
>> trackign changes in a patch from one release to the nhext becomes,
>> for me, a nightmare.
> how is that? (not that
On Tue, Sep 30, 2008 at 04:50:21PM -0500, Manoj Srivastava wrote:
> With a patch series that changes slowly from release to release,
> trackign changes in a patch from one release to the nhext becomes,
> for me, a nightmare.
how is that? (not that i have never done this yet so i simply have no
On Tue, Sep 30 2008, Aidan Van Dyk wrote:
> * Manoj Srivastava <[EMAIL PROTECTED]> [080930 21:15]:
>> On Tue, Sep 30 2008, Stéphane Glondu wrote:
> Only if you like working with patch series, and prefer to lose
>> all the information that the original VCS contained. I prefer to see
>> t
* Manoj Srivastava <[EMAIL PROTECTED]> [080930 21:15]:
> On Tue, Sep 30 2008, Stéphane Glondu wrote:
Only if you like working with patch series, and prefer to lose
> all the information that the original VCS contained. I prefer to see
> the whole history, not just a snapshot, when I am j
On Tue, Sep 30 2008, Stéphane Glondu wrote:
> Martin Bähr wrote:
>>> I see the source package as something useful perhaps even in a
>>> non distro specific setting.
>>
>> indeed, they are. but exactly for working outside of debian it would be
>> preferable to have the patches easely acce
Martin Bähr wrote:
>> I see the source package as something useful perhaps even in a
>> non distro specific setting.
>
> indeed, they are. but exactly for working outside of debian it would be
> preferable to have the patches easely accessible seperately. i
> occasionally try to pick patc
On Tue, Sep 30 2008, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
>> Not really. I prefer to have the source packages be unpackged
>> even on a machine which does not run Debian, using just plain old tar
>> and patch. Thus I tend to ship the dif
On Tue, Sep 30, 2008 at 10:46 PM, martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Teemu Ikonen <[EMAIL PROTECTED]> [2008.09.30.1222 +0200]:
>> First, find a path from tagged release commit in master to the
>> commit in topgit branch patch/x preceding the commit in master
>> where patch/x w
also sprach Teemu Ikonen <[EMAIL PROTECTED]> [2008.09.30.1222 +0200]:
> First, find a path from tagged release commit in master to the
> commit in topgit branch patch/x preceding the commit in master
> where patch/x was last merged in. Let's call this commit Px. Next,
> starting from Px, find the c
On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
> Not really. I prefer to have the source packages be unpackged
> even on a machine which does not run Debian, using just plain old tar
> and patch. Thus I tend to ship the diff.gz as something that creates
> the set of b
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.2104 +0200]:
> OK, my bad than, I didn't know this (rather gory) detail. I thought it
> was just a problem of not being able to create the exact
> representation (e.g., to preserve checksums of the source package), I
> didn't get that t
On Tue, Sep 30, 2008 at 12:22:03PM +0200, Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb"
On Tue, Sep 30, 2008 at 10:42:37AM +0200, martin f krafft wrote:
> > who cares if you won't be able to recreate the exactly same
> > package?
> Because the topgit branches you used to create the stable package
> cannot be used anymore to create the patches that went into the
> stable package.
OK,
On Tue, Sep 30 2008, Stefano Zacchiroli wrote:
> On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
>> c) Therefore, we need to additionally store the patch series generated
>> from git branches into yet another git branch (presumably not one
>> the patch series are genera
On Tue, Sep 30, 2008 at 10:02 AM, martin f krafft <[EMAIL PROTECTED]> wrote:
> I always thought the point of tagging commits in the VCS was to be
> able to recreate pristine Debian source packages, no? Why do we
> bother tagging packages debian/1.0-1 if the tag cannot be used to
> actually obtain t
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.1036 +0200]:
> [ unrelated: is the list configured to not deliver a message Cc-ed
> to a subscriber also via the list?
This is a per-user setting in Mailman.
> Please avoid Cc-ing me, since the result is that I receive the
> message o
[ unrelated: is the list configured to not deliver a message Cc-ed to
a subscriber also via the list? Please avoid Cc-ing me, since the
result is that I receive the message only in my INBOX and (I guess due
to the setting above) without a List-Id header ... ]
On Tue, Sep 30, 2008 at 10:02:34AM +02
also sprach Guido Günther <[EMAIL PROTECTED]> [2008.09.30.0902 +0200]:
> We can certainly (at least) add another hook that calls a script
> that does what's described under 4.) and git-import-orig could
> help with importing new upstream but I think Manoj has some valid
> points about the current w
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.0932 +0200]:
> Hence, I see no need of versioning the patch series. Having just
> the last series, most likely in the Debian source package, would
> be enough.
I always thought the point of tagging commits in the VCS was to be
able to
On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
> *Sigh*. You are missing context. And the point.
I was in fact missing some context, but still I think you don't see my
big picture.
> c) Therefore, we need to additionally store the patch series generated
> from git
On Tue, Sep 30, 2008 at 09:02:31AM +0200, Guido Günther wrote:
> > Can git-buildpackage use information stored in the repository, such
> > as which branch to build from? It would be handy to be able to tell
> > people just to use git-buildpackage without expecting them to pass
> > the right branch
I wish people would change subject lines more often...
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.2242 +0200]:
> Of course, it would be great that with some tagging topgit could
> keep track of the history itself (as VCS' are supposed to be doing),
> and not make me sto
On Mon, Sep 29, 2008 at 12:01:25PM +0200, martin f krafft wrote:
[..snip..]
> Have you looked at topgit:debian/README.source? Do you think
> git-buildpackage could help automate this process?
We can certainly (at least) add another hook that calls a script that
does what's described under 4.) and
On Mon, Sep 29 2008, Stefano Zacchiroli wrote:
> On Mon, Sep 29, 2008 at 12:44:57PM -0500, Manoj Srivastava wrote:
>> Arguably, we should all use debhelper and use quilt+subversion,
>> to make it easier for more people to follow the package. And, really,
>> we should all be using rpm or
On Mon, Sep 29, 2008 at 12:44:57PM -0500, Manoj Srivastava wrote:
> Arguably, we should all use debhelper and use quilt+subversion,
> to make it easier for more people to follow the package. And, really,
> we should all be using rpm or tar.gz. (More people use subversion than
> do unders
On Mon, Sep 29 2008, martin f krafft wrote:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.1908 +0200]:
>> My goal is not to have a patch series in a Debian package. My goal
>> is to be able to develop software that is packaged for Debian --
>
> This argument has been taken ad infi
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.1908 +0200]:
> My goal is not to have a patch series in a Debian package. My goal
> is to be able to develop software that is packaged for Debian --
This argument has been taken ad infinitum on debian-devel. The idea
of a patch series in
On Mon, Sep 29 2008, martin f krafft wrote:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.1745 +0200]:
>> I don't really want to add ./debian/patches directory to keep
>> track of previous patch series;
>
> Well, it is the only truly-accepted, VCS-agnostic way to have
> a
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.1745 +0200]:
> I don't really want to add ./debian/patches directory to keep
> track of previous patch series;
Well, it is the only truly-accepted, VCS-agnostic way to have
a patch series in a Debian package, so why not?
> and
On Sun, Sep 28 2008, martin f krafft wrote:
> also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.28.1158 +0200]:
>> I've read topgit's README.source. I am currently experimenting with it.
>> Is there any other source package using topgit?
>
> None that I know of. It'll be hard to come up wit
On Mon, Sep 29, 2008 at 12:01:25PM +0200, martin f krafft wrote:
> Can git-buildpackage use information stored in the repository, such
> as which branch to build from? It would be handy to be able to tell
> people just to use git-buildpackage without expecting them to pass
> the right branch name.
also sprach Guido Günther <[EMAIL PROTECTED]> [2008.09.29.1053 +0200]:
> > If git-buildpackage expects master, then it is inflexible; you
> > should be able to tell it to build from build.
> git-buildpackage builds from any branch you tell it to.
I will have to look at git-buildpackage one of thes
On Mon, Sep 29, 2008 at 08:43:18AM +0200, martin f krafft wrote:
[..snip..]
> If git-buildpackage expects master, then it is inflexible; you
> should be able to tell it to build from build.
git-buildpackage builds from any branch you tell it to.
-- Guido
_
On Mon, Sep 29, 2008 at 07:50:17AM +0200, martin f krafft wrote:
> In a way that we could run this over the entire archive to produce
> statistics? Well, all Vcs-Git packages anyway...?
Yes.
> > It would be better to avoid adding that behavior to "debcheckout -p"
> > though, as currently that fla
also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.28.1524 +0200]:
> I understood this, but I wonder why you use two distinct branches for
> this. IIUC, your build branch will consist only on merges with the
> master branch and updates of patches, right? What benefits do you get by
> clutteri
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.28.1756 +0200]:
> Thinking out loud: remember the bug you (or me, doesn't matter)
> reported against debcheckout in Debian to better support, via
> heuristics, topgit? Well, once I have time to fix it :), we can
> ask debcheckout if some p
On Sun, Sep 28, 2008 at 02:07:36PM +0200, martin f krafft wrote:
> also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.28.1158 +0200]:
> > I've read topgit's README.source. I am currently experimenting with it.
> > Is there any other source package using topgit?
> None that I know of. It'll be
On Sun, Sep 28, 2008 at 11:58:37AM +0200, Stéphane Glondu wrote:
> I've read topgit's README.source. I am currently experimenting with it.
Shameless OT: Stéphane, I had a look at topgit myself, and I was going
to propose on top of it a workflow to be adopted for *all*
debian-ocaml-maint packages m
martin f krafft wrote:
> master is the Debianisation branch which provides ./debian/. All
> changes to ./debian/ are done there. It is not serialised,
> obviously, but serves as the base for build (it's merged into build
> for each new release) and then the patches are modified and
> committed.
I
also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.28.1158 +0200]:
> I've read topgit's README.source. I am currently experimenting with it.
> Is there any other source package using topgit?
None that I know of. It'll be hard to come up with statistics here,
since topgit is neither a build-d
martin f krafft wrote:
> I am currently all crazy about topgit (0.4 to be uploaded ASAP), and
> maybe you want to check it out. The topgit source package contains
> a debian/README.source file to explain what I am doing there. There
> are still rough edges, but I think it's a pretty nice way of doi
also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.25.1538 +0200]:
> I am interested in this list because I am interested in issues
> raised by packaging, and, more generally, in VCSs. I am familiar
> with packaging with subversion (as member of the OCaml Team) and
> git. Our team is slowly m
Hello,
My name is Stéphane Glondu. I've been using Debian for many years, and
I've been contributing to Debian for one year now. I am DM (and in NM
process). I work mainly in the Debian OCaml Team¹.
I am interested in this list because I am interested in issues raised by
packaging, and, more g
92 matches
Mail list logo
