Theodore Ts'o writes:
> The flip side is that you can get burned by people trying to compile
> from your git tree on either significantly older or significantly newer
> system than what you typically use to develop against, and if autoconf
> and friends have introduced incompatible changes to the
On Tue, Oct 07, 2014 at 08:26:45AM -0700, Russ Allbery wrote:
> I understand why you feel this way, particularly given the tools that
> you're working on, but this is not something I'm going to change as
> upstream. Git does not contain generated files, and the tarball release
> does, because thos
Dimitri John Ledkov writes ("Bug#764606: dgit and upstream git repos [and 1
more messages]"):
> On 9 October 2014 17:24, Ian Jackson wrote:
> > However,
> >
> >$ apt-get source sword
> >$ cd sword-*
> >$ rm -rf .pc
> >$ echo '
On 9 October 2014 17:24, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
>> On 9 October 2014 15:38, Ian Jackson wrote:
>> > If I can feed a .pc-less source tree to dpkg-source -b and get
>> > roughtly the right outp
Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
> On 9 October 2014 15:38, Ian Jackson wrote:
> > If I can feed a .pc-less source tree to dpkg-source -b and get
> > roughtly the right output then that would obviously be a big
> > improvement.
>
Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
> On 9 October 2014 15:49, Ian Jackson wrote:
> > I think that means that I can make dgit work directly with the tip
> > trees produced by git-dpm which will make some people happy.
>
> YES!!
On 9 October 2014 15:49, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
>> $ apt-get source sword
>> $ cd sword-*
>> $ rm -rf .pc
>> # a tree with up-to-date debian/patches, all patches are applied (as
>> e.g. git
Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
> $ apt-get source sword
> $ cd sword-*
> $ rm -rf .pc
> # a tree with up-to-date debian/patches, all patches are applied (as
> e.g. git-dpm does), .pc directory is gone
> $ dpkg-source -b .
> $ ech
On 9 October 2014 15:38, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
>> Sounds intriguing, can you please share design / intentions there?
>
> I haven't done the research needed yet. Facts are welcome.
>
> In particular
Hi,
On 10/09/2014 16:38, Ian Jackson wrote:
> ... I had thought that the stuff in .pc is necessary for dpkg-source
> to be able to build the package, and unpack the result.
>
> If I can feed a .pc-less source tree to dpkg-source -b and get
> roughtly the right output then that would obviously be
Dimitri John Ledkov writes ("Re: dgit and upstream git repos"):
> Sounds intriguing, can you please share design / intentions there?
I haven't done the research needed yet. Facts are welcome.
In particular...
> git-dpm currently generates debian/patches/* with patch
On 8 October 2014 12:50, Ian Jackson wrote:
> Russ Allbery writes ("Re: dgit and upstream git repos"):
>> Ian Jackson writes:
> (There is a problem with dgit and .pc/ which I am hoping to fix with a
> (perhaps-incompatible) change RSN, but that's not related.)
Ian Jackson writes:
> I hope you understand the rest of my mail, in which I said or implied:
> 1. Even if upstream disagrees, it should be obviously why dgit needs
>the dgit git history to have identical contents to the Debian
>packages.
> 2. This dgit requirement is not difficult to wo
Russ Allbery writes ("Re: dgit and upstream git repos"):
> Ian Jackson writes:
> > On `source code': I think everyone should have the same definition of
> > `source code' for git as for tarballs.
>
> I understand why you feel this way, particularly give
2014-10-07 12:01 GMT-03:00 Matthias Urlichs :
> Hi,
>
> Ian Jackson:
> > On `source code': I think everyone should have the same definition of
> > `source code' for git as for tarballs.
> >
> I beg to differ. Not in principle, but because tarballs and git trees
> target different groups of users.
Ian Jackson writes:
> On `source code': I think everyone should have the same definition of
> `source code' for git as for tarballs.
I understand why you feel this way, particularly given the tools that
you're working on, but this is not something I'm going to change as
upstream. Git does not c
Hi,
Ian Jackson:
> On `source code': I think everyone should have the same definition of
> `source code' for git as for tarballs.
>
I beg to differ. Not in principle, but because tarballs and git trees
target different groups of users.
I expect people who use my git trees to have a reasonably-re
Enrico Zini writes ("dgit and upstream git repos"):
> This is my scenario: I'm the upstream developer, I have an existing git
> repo with all the project history, and I'd like to be able to git push
> to debian using dgit.
>
> I ran "dgit fetch", I ran
Enrico Zini writes:
> When I had my new upstream version ready, however, and tried to merge it
> into the dgit branch, I realised that my development branch did not
> contain ./configure, Makefile.in and other autogenerated stuff, while
> the dgit branch of course did.
> If anyone is working in
Hello,
I gave my first try to dgit.
This is my scenario: I'm the upstream developer, I have an existing git
repo with all the project history, and I'd like to be able to git push
to debian using dgit.
I ran "dgit fetch", I ran "git checkout -b dgit/sid dgit/dgit/sid" and
all was fine.
When I ha
20 matches
Mail list logo
