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 those
Theodore Ts'o ty...@mit.edu 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
On 8 October 2014 12:50, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
Russ Allbery writes (Re: dgit and upstream git repos):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
(There is a problem with dgit and .pc/ which I am hoping to fix with a
(perhaps-incompatible) change RSN
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 patches against the
tree applied
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 a
On 9 October 2014 15:38, Ian Jackson ijack...@chiark.greenend.org.uk 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...
git-dpm
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 .
$ echo $?
0
Oh excellent.
I just tested
On 9 October 2014 15:49, Ian Jackson ijack...@chiark.greenend.org.uk 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-dpm does), .pc directory
Dimitri John Ledkov writes (Re: dgit and upstream git repos):
On 9 October 2014 15:49, Ian Jackson ijack...@chiark.greenend.org.uk 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!!
http
Dimitri John Ledkov writes (Re: dgit and upstream git repos):
On 9 October 2014 15:38, Ian Jackson ijack...@chiark.greenend.org.uk 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.
$ apt-get
On 9 October 2014 17:24, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
Dimitri John Ledkov writes (Re: dgit and upstream git repos):
On 9 October 2014 15:38, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
If I can feed a .pc-less source tree to dpkg-source -b and get
roughtly
Russ Allbery writes (Re: dgit and upstream git repos):
Ian Jackson ijack...@chiark.greenend.org.uk 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
Ian Jackson ijack...@chiark.greenend.org.uk 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
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 git checkout -b dgit/sid dgit/dgit/sid and
all was
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
Ian Jackson ijack...@chiark.greenend.org.uk 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
2014-10-07 12:01 GMT-03:00 Matthias Urlichs matth...@urlichs.de:
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
Enrico Zini enr...@enricozini.org 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
18 matches
Mail list logo
