m...@linux.it (Marco d'Itri) writes:
On May 18, Russ Allbery r...@debian.org 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
m...@linux.it (Marco d'Itri) writes:
On May 18, Russ Allbery r...@debian.org 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
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
On May 18, Russ Allbery r...@debian.org 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
Adam Borowski kilob...@angband.pl 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
Adam Borowski kilob...@angband.pl writes:
On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
Charles Plessy ple...@debian.org 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
Hello,
On Thu, 17 May 2012 16:52:02 +0200
Gergely Nagy alger...@balabit.hu 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
On 05/17/2012 04:52 PM, Gergely Nagy wrote:
Chris Knadle chris.kna...@coredump.us 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
18.05.2012 00:11, Russ Allbery пишет:
Tollef Fog Heen tfh...@err.no 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
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
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 to the source
]] 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
Hello,
On Fri, 18 May 2012 11:37:08 +0200
Adam Borowski kilob...@angband.pl 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,
Jon Dowland j...@debian.org 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
On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
Charles Plessy ple...@debian.org 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
Chris Knadle chris.kna...@coredump.us 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
On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
On Fri, 18 May 2012 11:37:08 +0200
Adam Borowski kilob...@angband.pl 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
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 ple...@debian.org 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
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 kilob...@angband.pl wrote:
Quilt is a kind of really primitive VCS. It does not make sense to
use both it and a modern one, and
* Adam Borowski kilob...@angband.pl [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
-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 changes to
Henrique de Moraes Holschuh h...@debian.org 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
Le Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery a écrit :
Charles Plessy ple...@debian.org 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
]] 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 Upstream
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, myself. But
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
Chris Knadle chris.kna...@coredump.us 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
Tollef Fog Heen tfh...@err.no 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
* Russ Allbery (r...@debian.org) [120517 19:53]:
Tollef Fog Heen tfh...@err.no 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
]] 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 Git
On Thursday, May 17, 2012 10:52:02, Gergely Nagy wrote:
Chris Knadle chris.kna...@coredump.us 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:
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
Tollef Fog Heen tfh...@err.no 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
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
On Tue, May 15, 2012 at 11:10 AM, Jon Dowland j...@debian.org 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
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 (quilt)
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 /debian/patches
Adam Borowski kilob...@angband.pl 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
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-squeeze,
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
Charles Plessy ple...@debian.org 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
]] 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.
On 2012-05-15, Norbert Preining prein...@logic.at 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.
Norbert Preining prein...@logic.at 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
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
Hi,
(Caveat: I am not a dpkg-source maintainer.)
Sune Vuorela wrote:
On 2012-05-15, Norbert Preining prein...@logic.at 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
Norbert Preining prein...@logic.at 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
Russ Allbery wrote:
Norbert Preining prein...@logic.at 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
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
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
Norbert Preining prein...@logic.at 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
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 patches
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
Norbert Preining prein...@logic.at 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
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?
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
56 matches
Mail list logo
