tangke writes:
> On 2010å¹´01æ20æ¥ 23:39, Goswin von Brederlow wrote:
>> Norbert Preining writes:
>>
>>
>>> On Mo, 28 Dez 2009, Raphael Hertzog wrote:
>>>
> Mind that git-buildpackage with normal 1.0 source format does NOT pollute
> the git repository, so my expectation is t
On Fri, 22 Jan 2010, Joachim Wiedorn wrote:
> If I had unapplied all patches of debian/patches and later I start with
> debuild, then dpkg-source works with the unpatched sources - it doesn't
> apply the patches as in format 1.0. Is there a chance that dpkg-source
> see the patches and can recogniz
Hello,
Raphael Hertzog wrote:
> On Fri, 22 Jan 2010, tangke wrote:
> > why not apply the patches when build automatically,
>
> This is the case when you build the source package (i.e. dpkg-source does
> it if it was not yet done).
>
> > and make clean to unapply the patches?
>
> The clean proc
On Fri, 22 Jan 2010, tangke wrote:
> why not apply the patches when build automatically,
This is the case when you build the source package (i.e. dpkg-source does
it if it was not yet done).
> and make clean to unapply the patches?
The clean process is controlled by the maintainer. You could in
On 2010年01月20日 23:39, Goswin von Brederlow wrote:
Norbert Preining writes:
On Mo, 28 Dez 2009, Raphael Hertzog wrote:
Mind that git-buildpackage with normal 1.0 source format does NOT pollute
the git repository, so my expectation is that the 3.0 format does the
same, but alas, it do
Norbert Preining writes:
> Hi Goswin,
>
> thanks for the very interesing and profound answer.
>
> On Mi, 20 Jan 2010, Goswin von Brederlow wrote:
>> The other thing is how to manage the source in version control now.
>> Do you commit the source with all patches applied? Or all patches
>> unapplie
Hi Goswin,
thanks for the very interesing and profound answer.
On Mi, 20 Jan 2010, Goswin von Brederlow wrote:
> Bug #557623: Quilt should remember where it first got patches and
> series from
Good idea.
> > $ quilt new
> > ... bummer, there is now ./patches in my git repository
>
> Same as ab
Norbert Preining writes:
> On Mo, 28 Dez 2009, Iustin Pop wrote:
>> cleaner - no longer quilt-specific stuff in debian/rules, and a nice
>> debian.tar.gz instead of a diff.
>
> Beh, I disagree, the 3 different lines in debian/rules are NOT bad
> by itself, it shows that *something* is changed. A
Russ Allbery writes:
> Felipe Sateler writes:
>> On Mon, 2009-12-28 at 22:40 -0800, Russ Allbery wrote:
>
>>> I think the way forward for Git-maintained packages is the 3.0 (git)
>>> format, but changed to ship a bundle. That way, relevant branches and
>>> history can be included, and Git is fa
Raphael Geissert writes:
> Raphael Geissert wrote:
>
>> Russ Allbery wrote:
>> [...]
>>> For Git-maintained packages like openafs, that would mean
>>> ignoring all the patch management features and letting it generate a
>>> single combined Debian diff analogous to the existing 1.0 diff from the
>
Norbert Preining writes:
> On Mo, 28 Dez 2009, Raphael Hertzog wrote:
>> > Mind that git-buildpackage with normal 1.0 source format does NOT pollute
>> > the git repository, so my expectation is that the 3.0 format does the
>> > same, but alas, it doesn't.
>>
>> Well, if you have the usual quilt
Norbert Preining writes:
> Can someone of the proposers of this (nice? stupid? rubbish?) format
> explain me please why on earth:
> - git-buildpackage
> - dpkg-buildpackage
> - and in fact at the bottom dpkg-source
> fuck around in my git repository, applying patches, just for builing
> a source
On Wed, 30 Dec 2009 22:09:51 +0900, Charles Plessy wrote:
> Indeed, I was doubly wrong. It is ‘dget -x’, not ‘dpkg-source -x’ that refuses
> to unpack signed packages whose key is not available.
JFYI: This can be changed by setting
DGET_VERIFY=no
in ~/.devscripts .
Cheers,
gregor
--
.''`. h
Le Wed, Dec 30, 2009 at 01:46:08PM +0100, Andreas Metzler a écrit :
> Charles Plessy wrote:
>
> > Indeed I was wrong: dpkg-source will refuse to unnpack a package
> > that is signed but the key is not available locally, however it will
> > accept to unpack a package that is not signed.
>
> Works
Charles Plessy wrote:
> Le Tue, Dec 29, 2009 at 08:27:56PM -0800, Russ Allbery a écrit :
>> Charles Plessy writes:
[...]
>> > given that 1) dpkg-source will not extract
>> > packages that are not GPG-trusted,
>> Eh? I'm fairly sure it does for me, although it prints a warning.
> Indeed I was w
Le Tue, Dec 29, 2009 at 08:27:56PM -0800, Russ Allbery a écrit :
> Charles Plessy writes:
>
> > There were some concerns that applying patches through debian/rules
> > could be a security hole. In my opinion – that I already expressed in
> > the DEP1 discussion – given that 1) dpkg-source will no
Charles Plessy writes:
> In my opinion, much of the current disagreements come from two false needs:
> * Apply patches so that dpkg-source -x gives buildable source.
That was the need that had as much or more project consensus as anything
else on my list, and as I recall was the impetus for do
Le Tue, Dec 29, 2009 at 10:33:45AM -0800, Russ Allbery a écrit :
>
> * Support for other compression methods.
> * Multiple upstream source tarballs.
> * Apply patches so that dpkg-source -x gives buildable source.
> * Ship debian/* as a tarball instead of a patch.
> * Allow binaries in the debian
>> It would have been MORE than easy to have bz2 support in 1.0. There is
>> absolutely no reason why it needs a 3.0 just for a different compression.
>> But that wasnt wanted.
> By whom? dpkg maintainers, archive admins, package maintainers?
> tar.bz2 support is the only reason I see for conside
Felipe Sateler writes:
> On Mon, 2009-12-28 at 22:40 -0800, Russ Allbery wrote:
>> I think the way forward for Git-maintained packages is the 3.0 (git)
>> format, but changed to ship a bundle. That way, relevant branches and
>> history can be included, and Git is fairly space-efficient so the
>>
On Mon, 2009-12-28 at 22:40 -0800, Russ Allbery wrote:
> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle. That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so is
Peter Samuelson writes:
> Presumably dpkg maintainers. I've long suspected that the main reason
> they chose not to add tar.bz2 to format 1.0 is, if they did, a lot of
> us would have no reason to want format 3.0. Many packagers don't need
> multiple tarballs or non-text files, and are quite ha
On Tue, 29 Dec 2009, Joachim Wiedorn wrote:
> Even though there are some newer Mails this question seems to not be
> solved.
>
> Is it true, that I need an installed quilt to unapply the patches?
Yes. With "3.0 (quilt)", the default state is "patches are applied" (since
that's what you get when
Hi,
On Tue, 29 Dec 2009, Stefano Zacchiroli wrote:
> On Tue, Dec 29, 2009 at 04:52:59PM +, Julien Cristau wrote:
> > > Format 3.0 is more than .bz2 support.
> > And we're saying .bz2 support is the only thing in it we care about, and
> > didn't need to come with 3.0's drawbacks.
>
> And I'm s
Hi,
On Tue, 29 Dec 2009, Norbert Preining wrote:
> On Di, 29 Dez 2009, Raphael Hertzog wrote:
> > That's because you're doing a source only build. With a binary build,
> > patches would have been applied.
>
> I always build my packages in a clean chroot and not in my life system.
I do the same (
On Tue, Dec 29, 2009 at 04:52:59PM +, Julien Cristau wrote:
> > Format 3.0 is more than .bz2 support.
> And we're saying .bz2 support is the only thing in it we care about, and
> didn't need to come with 3.0's drawbacks.
And I'm still saying that ranting _here_ about that is pointless.
Submit
On Tue, Dec 29, 2009 at 17:35:53 +0100, Stefano Zacchiroli wrote:
> Format 3.0 is more than .bz2 support.
And we're saying .bz2 support is the only thing in it we care about, and
didn't need to come with 3.0's drawbacks.
[...]
> Finally, nobody is forced to use it: if you don't like it, just avo
On Tue, Dec 29, 2009 at 10:04:19AM -0600, Peter Samuelson wrote:
> Presumably dpkg maintainers. I've long suspected that the main reason
> they chose not to add tar.bz2 to format 1.0 is, if they did, a lot of
> us would have no reason to want format 3.0. Many packagers don't need
> multiple tarba
> On Mon, Dec 28, 2009 at 12:29:48 +0100, Joerg Jaspert wrote: It would
> > have been MORE than easy to have bz2 support in 1.0. There is
> > absolutely no reason why it needs a 3.0 just for a different
> > compression. But that wasnt wanted.
[Julien Cristau]
> By whom? dpkg maintainers, archiv
On Mon, Dec 28, 2009 at 12:29:48 +0100, Joerg Jaspert wrote:
> It would have been MORE than easy to have bz2 support in 1.0. There is
> absolutely no reason why it needs a 3.0 just for a different compression.
> But that wasnt wanted.
By whom? dpkg maintainers, archive admins, package maintainer
Hello,
Joachim Wiedorn wrote:
> The only missing item for me is: there are no simple command to unapply
> the patches with dpkg-buildpackages (or debuild). For example:
>
>debuild unapply
Even though there are some newer Mails this question seems to not be
solved.
Is it true, that I need
On Di, 29 Dez 2009, Raphael Hertzog wrote:
> That's because you're doing a source only build. With a binary build,
> patches would have been applied.
I always build my packages in a clean chroot and not in my life system.
Best wishes
Norbert
--
Hi,
On Mon, 28 Dec 2009, Norbert Preining wrote:
> $ git-buildpackage -us -uc -rfakeroot -S
[...]
> nothing to commit (working directory clean)
> $
>
> So please tell me *what* has changed?
That's because you're doing a source only build. With a binary build,
patches would have been applied.
I
]] Joey Hess
| I think you should be using a dedicated source format for your patch
| system, preferably one that preserves the pre-patched source on unpack
| invariant. Either the existing 3.0 (custom), or a new 3.0 subformat.
Note that those won't be accepted into the archive (at least not wit
On Mon, Dec 28, 2009 at 10:40:34PM -0800, Russ Allbery wrote:
> Raphael Geissert writes:
>
> > 3.0 would be friendlier if it would only *not* automatically apply the
> > patches when extracting the source. But then there's not much point for
> > dpkg to know about patches.
>
> I do think the pro
Manoj Srivastava writes:
> On Tue, Dec 29 2009, Russ Allbery wrote:
>> I think the way forward for Git-maintained packages is the 3.0 (git)
>> format, but changed to ship a bundle. That way, relevant branches and
>> history can be included, and Git is fairly space-efficient so the
>> additional
On Tue, Dec 29 2009, Russ Allbery wrote:
> I think the way forward for Git-maintained packages is the 3.0 (git)
> format, but changed to ship a bundle. That way, relevant branches and
> history can be included, and Git is fairly space-efficient so the
> additional cost of doing so isn't that bad.
Raphael Geissert writes:
> 3.0 would be friendlier if it would only *not* automatically apply the
> patches when extracting the source. But then there's not much point for
> dpkg to know about patches.
I do think the problem of not having buildable source after dpkg-source -x
is worth solving, a
Raphael Geissert wrote:
> Russ Allbery wrote:
> [...]
>> For Git-maintained packages like openafs, that would mean
>> ignoring all the patch management features and letting it generate a
>> single combined Debian diff analogous to the existing 1.0 diff from the
>> patched upstream source maintaine
On Tue, Dec 29, 2009 at 10:16 AM, Charles Plessy wrote:
> The source format versions 3.0 (quilt) solves much of the issues in the above
> paragraph, but comes with its own patch management system. How about
> introducing
> a new 3.0 variant that has the following features:
>
> - no patch manage
Le Mon, Dec 28, 2009 at 12:44:29PM -0500, Joey Hess a écrit :
>
> I would prefer not to see such packages in the archive using source
> format 3.0. We've been down that road with 1.0, and it was not pretty.
> Above all other goals, my goal with putting the framework of source 3.0
> in place was to
Russ Allbery wrote:
[...]
> For Git-maintained packages like openafs, that would mean
> ignoring all the patch management features and letting it generate a
> single combined Debian diff analogous to the existing 1.0 diff from the
> patched upstream source maintained in Git.
>
I couldn't agree mo
On Mo, 28 Dez 2009, Neil Williams wrote:
> svn-buildpackage 0.7.1 can cope with dpkg source format 3.0 - in the
> context of using an .orig.tar.bz2 but not (yet) with multiple tarballs.
> Have you tried that version with TeX Live? If there are things that
Honestly, building TL packages is too comp
On Mo, 28 Dez 2009, Iustin Pop wrote:
> As others have remarked, the working copy is polluted with 1.0 too, and
> you would need to run debian/rules clean to get back to a pristine
> state.
See my other email, that is *wrong*. I was talking about
dpkg-buildpackage -us -uc -rfakeroot -S
(
Iustin Pop writes:
> Furthermore, by standardising on quilt patches, I hope that we will move
> away from directly patching upstream source in the debian diff.gz, which
> I find very sloppy work.
If patches to the upstream source are maintained in Git or some other
full-featured revision control
On So, 27 Dez 2009, Russ Allbery wrote:
> >> My .quiltrc includes this:
> >>
> >> QUILT_PATCHES=debian/patches
>
> No, there's a more general recipe for selectively setting QUILT_PATCHES in
> the documentation in the quilt package.
Pointers please? I checked README.Debian, README.gz, quilt.t
On Mo, 28 Dez 2009, Raphael Hertzog wrote:
> > Mind that git-buildpackage with normal 1.0 source format does NOT pollute
> > the git repository, so my expectation is that the 3.0 format does the
> > same, but alas, it doesn't.
>
> Well, if you have the usual quilt rules, you working copy is also m
On Mo, 28 Dez 2009, Norbert Preining wrote:
> > No, there's a more general recipe for selectively setting QUILT_PATCHES in
> > the documentation in the quilt package.
>
> Pointers please? I checked README.Debian, README.gz, quilt.txt.gz,
> and quilt.quiltrc for QUILT_PATCHES but didn't find anythi
Joey Hess wrote:
> Joachim Wiedorn wrote:
> > I still use CDBS and I use "simple-patches" - but now without CDBS
> > support. My minor change is the file "patches/series" which let
> > dpkg-buildpackages know that there are patches. This seems very simple,
> > too. To get the old manner, I must o
Joachim Wiedorn wrote:
> I still use CDBS and I use "simple-patches" - but now without CDBS
> support. My minor change is the file "patches/series" which let
> dpkg-buildpackages know that there are patches. This seems very simple,
> too. To get the old manner, I must only delete the series file an
Joachim Wiedorn wrote:
> No, I don't use an debian/rules based patch system. The patches will be
> used by dpkg-buildpackage because I have created the patches/series
> file. So inside dpkg the quilt-management of the patches will be used.
> But I don't use quilt outside the dpkg system.
>
> Pleas
Hello,
Am Mon, 28 Dec 2009 01:25:17 +0100 schrieb
Iustin Pop :
> Sorry to hear about your bad experience. I use the same workflow,
> git-buildpackage + 3.0 (quilt) and I have no problems so far.
Before I have made official Debian packages I have collected many
experience with format 1.0 and
On Mon, 28 Dec 2009 12:29:48 +0100
Joerg Jaspert wrote:
> > (Personally, I'm not happy with 3.0 either, I see no sufficient
> > benefit to use it unless the upstream tarball is a .tar.bz2. It's
> > not cleaner, lsdiff -z is no different to tar -tzf. However, I will
> > do what I can to allow 3.0
> (Personally, I'm not happy with 3.0 either, I see no sufficient benefit
> to use it unless the upstream tarball is a .tar.bz2. It's not cleaner,
> lsdiff -z is no different to tar -tzf. However, I will do what I can
> to allow 3.0 to work within svn-bp for the few packages that may
> benefit.)
On Mon, 28 Dec 2009 01:38:43 +0100
Norbert Preining wrote:
> > cleaner - no longer quilt-specific stuff in debian/rules, and a nice
> > debian.tar.gz instead of a diff.
>
> Beh, I disagree, the 3 different lines in debian/rules are NOT bad
> by itself, it shows that *something* is changed. And
On Mon, Dec 28, 2009 at 01:38:43AM +0100, Norbert Preining wrote:
> On Mo, 28 Dez 2009, Iustin Pop wrote:
> > Sorry to hear about your bad experience. I use the same workflow,
> > git-buildpackage + 3.0 (quilt) and I have no problems so far.
>
> Good for you.
>
> > Are you using --git-export-dir?
Hi,
On Mon, 28 Dec 2009, Norbert Preining wrote:
> > Are you using --git-export-dir? It seems not, and that you build the
> > package in-place.
>
> No, and it is nowhere mentioned on the wiki page.
>
> Mind that git-buildpackage with normal 1.0 source format does NOT pollute
> the git repository
Norbert Preining writes:
> On Mo, 28 Dez 2009, Iustin Pop wrote:
>> My .quiltrc includes this:
>>
>> QUILT_PATCHES=debian/patches
> That is wrong, because I do other projects where I don't have my
> patches in debian/patches ...
> Is a DD expected to only use quilt in that mode? Arggg.
No
On Mo, 28 Dez 2009, Iustin Pop wrote:
> Sorry to hear about your bad experience. I use the same workflow,
> git-buildpackage + 3.0 (quilt) and I have no problems so far.
Good for you.
> Are you using --git-export-dir? It seems not, and that you build the
> package in-place.
No, and it is nowhere
On Mon, Dec 28, 2009 at 01:14:46AM +0100, Norbert Preining wrote:
> Can someone of the proposers of this (nice? stupid? rubbish?) format
> explain me please why on earth:
> - git-buildpackage
> - dpkg-buildpackage
> - and in fact at the bottom dpkg-source
> fuck around in my git repository, applyin
Can someone of the proposers of this (nice? stupid? rubbish?) format
explain me please why on earth:
- git-buildpackage
- dpkg-buildpackage
- and in fact at the bottom dpkg-source
fuck around in my git repository, applying patches, just for builing
a source package?
If someone is so kind and tell
61 matches
Mail list logo
