Quoting Mauro Lizaur ([EMAIL PROTECTED]):
> Package: wnpp Owner: Mauro Lizaur <[EMAIL PROTECTED]> Severity: wishlist
>
>
> * Package name: python-twitter
> Version : 0.5
> Upstream Author : DeWitt Clinton <[EMAIL PROTECTED]>
> * URL : http://code.google.com/p/python-tw
Hi all,
http://wiki.debian.org/debian/patches is world-writeable, and attempts
to summarize what was said in this thread and in the Policy discussions
about 'README.source'. Do not hesitate to edit it !
Le Sat, Feb 02, 2008 at 10:52:01PM +0900, Osamu Aoki a écrit :
>
> You have column for "accep
On Sat, Feb 02, 2008 at 05:36:40PM +1100, martin f krafft said:
On Sat, Feb 02, 2008 at 05:38:03PM +1100, martin f krafft said:
On Sat, Feb 02, 2008 at 05:41:25PM +1100, martin f krafft said:
On Sat, Feb 02, 2008 at 05:47:13PM +1100, martin f krafft said:
On Sat, Feb 02, 2008 at 05:52:22PM +1100, m
I demand that I definitely did write...
[snip]
> Whatever DSCM is used, it needs history truncation. This rules out
> mercurial (at present? certainly 0.9.5); I tarred up the bits needed to
> recreate a checked-out repository of xine-lib - 8.6MB orig.tar.gz
> (1.1.9.1), 28MB hg.tar.gz (tip, but th
On Sat, Feb 02, 2008 at 07:18:26PM +1100, martin f krafft wrote:
> also sprach David Nusinow <[EMAIL PROTECTED]> [2008.01.27.0334 +1100]:
> > External patch systems are not ideal by any means, but they do
> > clearly address these issues as well as I could ask for. It's
> > trivial to update the pa
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0323 +1100]:
>> For example when you need different series of patches per
>> architecture (the libc e.g. has specific hurd patches).
>
> Wouldn't this be handled better with preprocessor #if
On Sat, Feb 02, 2008 at 05:00:42PM -0500, Theodore Tso wrote:
> And I think it is a much better idea to encourage people to spend
> their time working on good, upstreamable patches, than to tell them
> that the need to learn some specific DSCM.
Very well said. The most important thing is to make
Daniel Leidert <[EMAIL PROTECTED]> writes:
> What I mean is: Say you have addressed 5 different issues in the
> code. I still think it is easier to understand, if 5 separate
> patches are provided instead of one. And tracking each of them be
> checking commits for the initial fix and changes done
Package: wnpp
Severity: wishlist
Owner: "Székelyi Szabolcs" <[EMAIL PROTECTED]>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: vamp-plugin-sdk
Version : 1.1b
Upstream Author : Chris Cannam <[EMAIL PROTECTED]>
* URL : http://www.vamp-plugins.org/
* Licen
also sprach Cyril Brulebois <[EMAIL PROTECTED]> [2008.01.26.0129 +1100]:
> Does anything prevent you from doing something like the following in
> the clean target? (In addition to the usual patch/unpatch dependencies
> as suggested when using quilt.make.)
> | quilt push 00_fix_upstream_clean
> | #
also sprach Mike Hommey <[EMAIL PROTECTED]> [2008.01.27.0551 +1100]:
> On Sat, Jan 26, 2008 at 07:10:42PM +0100, Pierre Habouzit wrote:
> > On Sat, Jan 26, 2008 at 04:35:24PM +, Mike Hommey wrote:
> > > On Sat, Jan 26, 2008 at 05:23:16PM +0100, Pierre Habouzit wrote:
> > > > On Sat, Jan 26, 200
This is a copy of what I just sent to the following bugs: #403237,
#415677, #425647, #440330. I wanted to put debian-devel on the CC, but
simply forgot to. Sorry.
Hi all, hi Ron.
I am fully aware that this is not a nice thing to propose and I know
that even though Ron does not know me and proba
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.25.1959 +1100]:
> Oh and don't try to ask for complete uniformity in packaging, there
> are 1000 DDs, 10 times as many packages, different needs (you don't
> package a perl extension like you package mozilla or gcc or a java
> library) henc
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0939 +1100]:
> On Fri, Jan 25, 2008 at 06:00:02PM +, Raphael Hertzog wrote:
> > On Fri, 25 Jan 2008, Michael Banck wrote:
> > > On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > > > On 25/01/08 at 08:01 +, Steve L
also sprach Steve Langasek <[EMAIL PROTECTED]> [2008.01.29.1144 +1100]:
> And to answer the original question, sure, quilt can handle it; as well as
> any patch management system can handle the fact that the things you're
> applying the patches against are external to the VCS and require rain dance
also sprach Andreas Tille <[EMAIL PROTECTED]> [2008.01.28.1859 +1100]:
> The only problem that me and I guess at least 50% of DDs have with
> debcheckout(1) and debcommit(1) is that they did not know them before
> this thread. Feel free to call me ignorant, but I was not aware of
> these tools (an
also sprach Colin Watson <[EMAIL PROTECTED]> [2008.01.27.0133 +1100]:
> include this sort of cruft. If patch systems must stay around,
> I would be happy if somebody could design and write a standard
> wrapper that could figure out the differences automatically, and
> get it into devscripts.
I thi
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0323 +1100]:
> For example when you need different series of patches per
> architecture (the libc e.g. has specific hurd patches).
Wouldn't this be handled better with preprocessor #ifdefs? I'd say
it would make the code clearer and mor
also sprach Josselin Mouette <[EMAIL PROTECTED]> [2008.01.30.0458 +1100]:
> The easiest way I found to manage quilt patches with SVN in
> mergeWithUpstream mode is to extract the tarball in a temporary
> directory and to link the debian/ directory from the SVN repository. All
> modifications made t
also sprach Josselin Mouette <[EMAIL PROTECTED]> [2008.01.25.2008 +1100]:
> I’d be glad if we could standardize on quilt.
Standardisation is not something you do, IMHO, it's something that
emerges. So if you want quilt to become the standard, test it,
experiment it, smooth out the rough edges, tea
also sprach Darren Salt <[EMAIL PROTECTED]> [2008.01.26.1105 +1100]:
> So no need for .git.tar.gz, then - just carry on shipping
> .orig.tar.gz and .diff.gz, and use debcheckout if you need the
> history.
As Debian moves more and more into developing countries, where
Internet access is not (yet) u
also sprach David Nusinow <[EMAIL PROTECTED]> [2008.01.27.0334 +1100]:
> External patch systems are not ideal by any means, but they do
> clearly address these issues as well as I could ask for. It's
> trivial to update the patches, just go one by one through them.
> You can trivially see the patch
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.01.27.0505 +1100]:
> Seconded. I'd add, that in fact we should standardize on quilt
> as an exchange format for patches, because it's simple, and that
> there are powerful tools to handle them.
Except those patches contain no VCS-specific
also sprach Theodore Tso <[EMAIL PROTECTED]> [2008.01.28.1613 +1100]:
> From: Author O' The Patch <[EMAIL PROTECTED]>
> Detailed patch description
> Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
>
> This is at the beginning of every single quilt patch, and because of
> this, we can easily imp
also sprach Riku Voipio <[EMAIL PROTECTED]> [2008.01.26.0205 +1100]:
> We have managed to get almost complete uniformity of the binary
> packages produced. And imho, it's one of the things that makes
> Debian great. In this background it's kinda sad that our source
> packaging such a mess with so m
also sprach Daniel Leidert <[EMAIL PROTECTED]> [2008.01.31.0538 +1100]:
> I read your post/blog entry. That doesn't mean, that I agree to
> everything. I especially cannot agree to the flame on Fedora/Gentoo/BSDs
> way to just hold a spec (compares to our debian/*) + patches in a VCS,
> beecause it
On Sat, Feb 02, 2008 at 10:26:52PM +0100, Pierre Habouzit wrote:
> Bah that's the worst reason I ever seen to not use a DVCS in Debian.
> Please look at the debian packages with patches, and please tell me how
> many come with a comment about what the patch do. Please start with the
> glibc if yo
On Sat, Feb 02, 2008 at 10:26:52PM +0100, Pierre Habouzit wrote:
> Bah that's the worst reason I ever seen to not use a DVCS in Debian.
> Please look at the debian packages with patches, and please tell me how
> many come with a comment about what the patch do.
For one, you have the filename...
On Sat, Feb 02, 2008 at 02:59:01PM +, Theodore Tso wrote:
> On Sat, Feb 02, 2008 at 12:04:16PM +, Roger Leigh wrote:
> >
> > While the time might not be yet, DVCS systems are getting to the point
> > where they could make our lives all much simpler. Having all of
> > Debian in git, where
Moritz Muehlenhoff wrote:
> Julian Andres Klode wrote:
>
* License : non-free / CC By-SA 3.0
>>> Is it non-free because of its being CC-BY-SA 3.0, or does it contain
>>> non-free stuff?
>>>
>> AFAIK, CC-BY-SA is non-free.
>> 'non-free / CC BY-SA 3.0 '=3D> 'non-free (CC BY-SA 3.0)'
>
Package: wnpp Owner: Mauro Lizaur <[EMAIL PROTECTED]> Severity: wishlist
* Package name: python-twitter
Version : 0.5
Upstream Author : DeWitt Clinton <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/python-twitter/
* License : Apache-2.0
Programming Lang
Charles Plessy <[EMAIL PROTECTED]> writes:
> As said before, the direction that is currently taken at the Policy
> level would be to require documenting how to "make the source ready for
> editing" in a file called README.source. It would be recommended to
> implement a 'patched' target that would
On Sat, Feb 02, 2008 at 12:21:25PM +0900, Charles Plessy wrote:
> Le Fri, Feb 01, 2008 at 11:11:19PM +0100, Matthias Klose a écrit :
> > Package: general
> > Severity: important
> >
> > There are no i386 and powerpc build daemons which run a 64bit kernel.
> > This means that packages requiring tes
On Sat, Feb 02, 2008 at 12:04:16PM +, Roger Leigh wrote:
>
> While the time might not be yet, DVCS systems are getting to the point
> where they could make our lives all much simpler. Having all of
> Debian in git, where anyone can clone and hack would be (IMHO) a
> worthy goal to aim for. C
On Sat, Feb 02, 2008 at 02:34:59PM +0100, Daniel Baumann wrote:
> Russ Allbery wrote:
> >> Such a field would allow us to make packages like ndisgtk arch-indep,
> >> while installing them only into the architectures specified in
> >> Install-Architecture.
> make your package arch all and request an
On 2008-02-02, Charles Plessy <[EMAIL PROTECTED]> wrote:
> http://wiki.debian.org/debian/patches
It claims that debian/patches is "not very convenient for very big
projects"
I very much don't agree. I am quite satisfied with working with
debian/patches and quilt and cdbs simple patchsys.
But of
This is a bit going out of original post but...
On Sat, Feb 02, 2008 at 05:14:25PM +0900, Charles Plessy wrote:
> http://wiki.debian.org/debian/patches
You have column for "accepts diff -u output" and "No" for dpatch. I am
not quite sure what is the criteria for you but to me dpatch accepts
"dif
Russ Allbery wrote:
>> Such a field would allow us to make packages like ndisgtk arch-indep,
>> while installing them only into the architectures specified in
>> Install-Architecture.
make your package arch all and request an entry in p-a-s; given that
p-a-s maintainers react timely, there's imho
On Fri, Feb 01, 2008 at 06:06:04PM +0100, Raphael Hertzog wrote:
> No, I said "rebase" and not merge.
> See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
>
> (Note that this means that nobody should derive from upstream-patched as
> the branch is regularly rewritten and one can'
Daniel Leidert <[EMAIL PROTECTED]> writes:
> I read your answer to Raphael, where you point to so called "feature
> branches". This leads to the question, if people should be forced to use
> a special VCS (which is already discussed somewhere else in the thread),
> whereas creating Debian packages
In this message I'm only speaking about the orig.tar.gz+diff.gz and
patches-as-separate-files approach and its possible standardization.
I'm not very familiar with VCS brances approach.
Most of these thoughts have already been given by different people in
this thread. I just collect (some of) t
Le Fri, Feb 01, 2008 at 11:42:49AM +0200, Lars Wirzenius a écrit :
>
> At the moment, I can unpack a source package and then review it before I
> run anything. You propose to make things more complicated by having to
> review things before unpacking. I find that to be an unwanted,
> unnecessary, a
42 matches
Mail list logo
