m...@linux.it (Marco d'Itri) writes:
> On May 18, Russ Allbery wrote:
>
>> I do this work in cases where keeping the patches separate is useful for
>> some reason, but mostly it's not.
> Some of my packages have 30-60 patches ("mature" software...), and
> merging them would make them impossibile
gitpkg with quilt hook is very nice.
Have a branch with debian change, one for patch queue, one for upstream
Use git cherry pick for porting patch
I use it for imagemagick
Will post my workflow tomorrow I post from my phone, sorry for top post and
brievety
Bastien
Le 21 mai 2012 02:56, "Marco
m...@linux.it (Marco d'Itri) writes:
> On May 18, Russ Allbery wrote:
>> I do this work in cases where keeping the patches separate is useful for
>> some reason, but mostly it's not.
> Some of my packages have 30-60 patches ("mature" software...), and
> merging them would make them impossibile
On May 18, Russ Allbery wrote:
> I do this work in cases where keeping the patches separate is useful for
> some reason, but mostly it's not.
Some of my packages have 30-60 patches ("mature" software...), and
merging them would make them impossibile to understand.
Is there a VCS workflow which w
Adam Borowski writes:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
>> Charles Plessy writes:
>>
>> > Also, it is very sad that, as a project, we can not decide whether we go
>> > for 3.0 (git) or not, or have a concrete list of resolvable objections
>> > from the people whose
Adam Borowski writes:
> On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
>> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
>> >> I'm confused concerning the above; the point of a VCS in this context is
>> >> to
>> >> track changes to the source package, and the patches are themselves
]] Roger Leigh
> I think this is a key point. The aim of the git format should not be
> provide the entire history, any more than the other formats do (not).
>
> What should be provided needs to be
> - sufficient to build the package
> - sufficient to determine the changes made between the Upst
Le Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery a écrit :
> Charles Plessy writes:
>
> > Also, it is very sad that, as a project, we can not decide whether we go
> > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > from the people whose work is direclty impacted b
Henrique de Moraes Holschuh writes:
> When it is time to release/upload, the branch gets git format-patch'd,
> and makes its way to debian/patches for 3.0(quilt) to handle. That
> branch is never published. git-pq can automate this stuff in an even
> better way that is rebase-less if you want,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/18/2012 11:37 AM, Adam Borowski wrote:
> On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
>> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
I'm confused concerning the above; the point of a VCS in this context
is to track c
* Adam Borowski [120518 11:37]:
> You complain about forcing people to use git, while you push quilt onto
> everyone else.
> [...]
>
> I really wish there was a "3.0" format besides "3.0 (quilt)", so people are
> not mislead into thinking they have to (or even, would gain anything) from
> writing
On Fri, 18 May 2012, Adam Borowski wrote:
> On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
> > On Fri, 18 May 2012 11:37:08 +0200
> > Adam Borowski wrote:
> > > Quilt is a kind of really primitive VCS. It does not make sense to
> > > use both it and a modern one, and when someone
On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
> > Charles Plessy writes:
> >
> > > Also, it is very sad that, as a project, we can not decide whether we go
> > > for 3.0 (git) or not, or have a concrete list of resol
On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
> On Fri, 18 May 2012 11:37:08 +0200
> Adam Borowski wrote:
> > Quilt is a kind of really primitive VCS. It does not make sense to
> > use both it and a modern one, and when someone tries,
>
> I'm sorry to disappoint you, but quilt
Chris Knadle writes:
> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revi
On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
> Charles Plessy writes:
>
> > Also, it is very sad that, as a project, we can not decide whether we go
> > for 3.0 (git) or not, or have a concrete list of resolvable objections
> > from the people whose work is direclty impacted by t
Jon Dowland writes:
> On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides. And working around quilt is simple:
>>
>> echo "single-debian-patch" >debian/source/options
>> echo "/.p
Hello,
On Fri, 18 May 2012 11:37:08 +0200
Adam Borowski wrote:
> Quilt is a kind of really primitive VCS. It does not make sense to
> use both it and a modern one, and when someone tries, this ends up
> with no end of woe. Quilt sprinkles its modifications around the
> source, breaks timestamp
]] Igor Pashev
> What about stable release? Git branches?
Sure. Branches are cheap.
> What about users who want rebuild a package (probably with new patches)?
They'll then just grab the git tree, apply their patches, build their
package.
--
Tollef Fog Heen
UNIX is user friendly, it's just p
On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
> >> I'm confused concerning the above; the point of a VCS in this context is
> >> to
> >> track changes to the source package, and the patches are themselves
> >> important
> >> changes
On Thu, May 17, 2012 at 06:23:49PM -0400, Chris Knadle wrote:
> Another thing I've seen with another package I'm working on in collaboration
> is using a Git repo in which the only contents are the debian/ files and not
> the original source tarball nor source files at all. To do a built the
>
18.05.2012 00:11, Russ Allbery пишет:
> Tollef Fog Heen writes:
>> ]] Russ Allbery
>
>>> If I were to pick between the enhancements to Debian in this area, none
>>> of which I have time to work on and therefore can't vote on via
>>> implementation, I'd be way more interested in avoiding the enti
On 05/17/2012 04:52 PM, Gergely Nagy wrote:
> Chris Knadle writes:
>
>> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> No, I hereby start saying
Hello,
On Thu, 17 May 2012 16:52:02 +0200
Gergely Nagy wrote:
> Git does have a complete view. What the above does, is tell
> dpkg-source to fold any changes made to the upstream sources into a
> single patch. Since the git tree already has the patches applied
> (with upstream sources on a diffe
On Thursday, May 17, 2012 10:54:15, Jon Dowland wrote:
> On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote:
> > I'm confused concerning the above; the point of a VCS in this context is
> > to track changes to the source package, and the patches are themselves
> > important changes to the
Tollef Fog Heen writes:
> ]] Russ Allbery
>> If I were to pick between the enhancements to Debian in this area, none
>> of which I have time to work on and therefore can't vote on via
>> implementation, I'd be way more interested in avoiding the entire
>> source package upload process entirely a
On mar., 2012-05-15 at 14:32 +0900, Norbert Preining wrote:
> Hi dpkg-* maintainers,
I think you missed the correct mailing list to reach the dpkg-*
maintainers.
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
On Thursday, May 17, 2012 10:52:02, Gergely Nagy wrote:
> Chris Knadle writes:
> > On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
> >> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> >> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> >> > > No, I her
]] Russ Allbery
> If I were to pick between the enhancements to Debian in this area, none of
> which I have time to work on and therefore can't vote on via
> implementation, I'd be way more interested in avoiding the entire source
> package upload process entirely and be able to just push signed
* Russ Allbery (r...@debian.org) [120517 19:53]:
> Tollef Fog Heen writes:
>
> > Pushing a signed tag and having source packages and binaries built from
> > that doesn't rely on 3.0 (git), though. «Just» a repository somewhere
> > with hooks that go «oh, a signed tag, let me build a source packa
Tollef Fog Heen writes:
> Pushing a signed tag and having source packages and binaries built from
> that doesn't rely on 3.0 (git), though. «Just» a repository somewhere
> with hooks that go «oh, a signed tag, let me build a source package and
> upload that». Might fire it off as a job to a sep
Chris Knadle writes:
> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revi
On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote:
> I'm confused concerning the above; the point of a VCS in this context is to
> track changes to the source package, and the patches are themselves important
> changes to the source package. If you have Git ignore the patches then Git
On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > > No, I hereby start saying good by to 3.0
> >
> > I'm hoping we can revisit 3.0 (git) post-squeeze, my
]] Russ Allbery
> There was never really a satisfactory resolution to that discussion. We
> can upload very shallow clones, but they end up looking a lot like the
> existing quilt format with single-debian-patch, and it's not horribly
> clear what the advantages of 3.0 (git) are at that point.
Charles Plessy writes:
> Also, it is very sad that, as a project, we can not decide whether we go
> for 3.0 (git) or not, or have a concrete list of resolvable objections
> from the people whose work is direclty impacted by the use of this
> format.
We know what a primary concrete objection is.
On Thu, 17 May 2012, Charles Plessy wrote:
> It strikes me that while we have more than 6,500 source packages
> managed with Git, we are pushing for a source package format that does
> not work transparently with them.
It does, but not on all workflows. A very large number of DDs are using
3.0 (q
Le Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski a écrit :
> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > > No, I hereby start saying good by to 3.0
> >
> > I'm hoping we can revisit 3.0 (git) post-squ
Adam Borowski writes:
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debian/patches" >>.gitignore
I recommend usi
On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
> has a number of upsides. And working around quilt is simple:
>
> echo "single-debian-patch" >debian/source/options
> echo "/.pc" >>.gitignore
> echo "/debi
On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
> On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> > No, I hereby start saying good by to 3.0
>
> I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> found myself to be incompatible iwth 3.0 (qu
On Tue, May 15, 2012 at 11:10 AM, Jon Dowland wrote:
> On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> No, I hereby start saying good by to 3.0
>
> I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
> found myself to be incompatible iwth 3.0 (quilt) and
On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> No, I hereby start saying good by to 3.0
I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also
found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last
few packages.
--
To UNSUBSCRIBE, email
On Tue, May 15, 2012 at 03:59:31PM +0900, Norbert Preining wrote:
> See my other answer. This is conceptually wrong, because you might
> end up with a *wrong* patch and the old one is destroyed due to the
> refresh (patch just messed it up .. and I didn't realize it, uuups).
Why don't you use a VCS
Norbert Preining writes:
> On Mo, 14 Mai 2012, Russ Allbery wrote:
>> If you don't care about checking the patches, it takes fifteen minutes
>> one time to write a shell script and then less than ten seconds to run
>> it before you do an upload.
> See my other answer. This is conceptually wrong,
On Mo, 14 Mai 2012, Russ Allbery wrote:
> If you don't care about checking the patches, it takes fifteen minutes one
> time to write a shell script and then less than ten seconds to run it
> before you do an upload.
See my other answer. This is conceptually wrong, because you might
end up with a *
Hi,
On Di, 15 Mai 2012, Andreas Tille wrote:
> Hmmm, what exactly is "normal testing *as*usual*"? Isn't it a duty of
Like I have, a test bed testing various upgrade and install scenaria
from stable/testing/sid.
> the maintainer to inspect critical parts of the code? IMHO existing
Not all patc
Norbert Preining writes:
> On Mo, 14 Mai 2012, Russ Allbery wrote:
>> Of all the things that one has to do with a package, this is pretty minor.
> If you are talking of a normal small package. Not of 2.6G of packages
> where even the source packages are *generated*, and unfuzzying is a
> proces
On Mo, 14 Mai 2012, Russ Allbery wrote:
> Of all the things that one has to do with a package, this is pretty minor.
If you are talking of a normal small package. Not of 2.6G of packages
where even the source packages are *generated*, and unfuzzying is a
process that takes quite some time.
Best
On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
> On Mo, 14 Mai 2012, Russ Allbery wrote:
> > isn't indicative of an error. A good way to indicate that is to unfuzz
> > the patch.
>
> Or build a source and binary package, do normal testing *as*usual*
> and upload ...
Hmmm, what
Russ Allbery wrote:
> Norbert Preining writes:
>
> > Is there a rational behind not allowing any fuzz?
>
> Fuzz indicates that the source file has changed since the patch has been
> generated, which means that the patch may no longer apply properly. Fuzz
> is a guess of convenience by the patch
Norbert Preining writes:
> On Mo, 14 Mai 2012, Russ Allbery wrote:
>> isn't indicative of an error. A good way to indicate that is to unfuzz
>> the patch.
> Or build a source and binary package, do normal testing *as*usual*
> and upload ...
There was a reason why I added the word "subtle" in f
Hi,
(Caveat: I am not a dpkg-source maintainer.)
Sune Vuorela wrote:
> On 2012-05-15, Norbert Preining wrote:
>> Is there a rational behind not allowing any fuzz?
>
> I think it makes perfect sense to expect the patches to apply perfectly,
> so we don't rely on patch & quilt to be able to unfuz
On Mo, 14 Mai 2012, Russ Allbery wrote:
> isn't indicative of an error. A good way to indicate that is to unfuzz
> the patch.
Or build a source and binary package, do normal testing *as*usual*
and upload ...
No, I hereby start saying good by to 3.0
Best wishes
Norbert
-
Norbert Preining writes:
> Is there a rational behind not allowing any fuzz?
Fuzz indicates that the source file has changed since the patch has been
generated, which means that the patch may no longer apply properly. Fuzz
is a guess of convenience by the patch program that the result is
*proba
On 2012-05-15, Norbert Preining wrote:
> Is there a rational behind not allowing any fuzz?
I think it makes perfect sense to expect the patches to apply perfectly,
so we don't rely on patch & quilt to be able to unfuzz things.
Especially when unfuzzing patches are so simple.
while quilt push ;
Hi dpkg-* maintainers,
I know, it is documented in dpkg-source man page:
Contrary to quilt's default behaviour, patches are expected to apply
without any fuzz. When that is not the case, you should refresh such
patches with quilt, or dpkg-source will error out while t
57 matches
Mail list logo
