George Danchev <[EMAIL PROTECTED]> writes:
> I strongly believe that [...] there is no any urgent need for more
> infrastrucre enhancements and yet another places to look at (like
> teaching BTS/PTS of doing additional DD-upstream communication
> processing which brings even more complexity to the
On Sunday 18 May 2008, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite natu
Filipus Klutiero <[EMAIL PROTECTED]> writes:
> I'm not sure whether you mean bug in the strict sense or in the BTS's
> sense. Do you think a divergence is a minor bug or a wishlist "bug"? I
> disagree that any divergence is a bug, but there may be a request to get
> rid of a divergence.
I won't s
Ben Finney wrote:
> Care to discuss what tags you plan to use, so an attempt at consensus
> can be made on naming the tags for this purpose?
I'm using a "divergence" usertag, with users [EMAIL PROTECTED] and
[EMAIL PROTECTED] (so it'll show up on my bugs page, and the
package's bug page -- not ide
Ben Finney wrote:
> Saying that the plural 3.0 source formats allow Debian tools to
> consume multiple package source formats is equivalent to saying that
> upstream developers have no standard source format to rely on from
> Debian.
Upstream largely don't touch distribution source packages. Where
I'm not sure whether you mean bug in the strict sense or in the BTS's
sense. Do you think a divergence is a minor bug or a wishlist "bug"? I
disagree that any divergence is a bug, but there may be a request to get
rid of a divergence.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
Josselin Mouette wrote:
> Le samedi 17 mai 2008 à 19:35 -0400, Joey Hess a écrit :
> > No, the equivilant of those targets is the Source field in
> > debian/control, and dpkg-source's plugin interface.
>
> To sum up, you don’t want to standardize on an interface that would
> force you to serialize
Ben Finney <[EMAIL PROTECTED]> writes:
> Joey Hess <[EMAIL PROTECTED]> writes:
>> (And then an automatic system closing any I forget to mention would be
>> nice.)
> What information would trigger such automation, in the absence of you
> noting it as such in the changelog entry?
For a patch that
Joey Hess <[EMAIL PROTECTED]> writes:
> I think that going back and collecting all the patches I've sent to
> upstreams over the years, and any I've dropped on the floor, and
> keeping it up-to-date going forward will help me maintain my
> packages better anyway, so I plan to do that this week. Th
Joey Hess <[EMAIL PROTECTED]> writes:
> Hmm, another thought is, I sometimes have a changelog like this:
>
> * New upstream release.
> - Including my fix for foo.
> - And a better approach than my old hack to fix bar.
>
> It would be nice to be able to add bug numbers to close the
> divergen
Joey Hess <[EMAIL PROTECTED]> writes:
> Pierre Habouzit wrote:
> > The 3 first. I assumed that everyone knows it's best to present
> > a summary of your idea in the first paragraph.
>
> You seem to have actually missed the second sentence, "A change
> might be a bug in upstream, or in the debia
Joey Hess <[EMAIL PROTECTED]> writes:
> I think it's about time to file mass bugs on whatever packages are
> left that use version control and lack the fields.
How would the putative filer of these bugs determine which packages
are in this set?
--
\ "...one of the main causes of the fall
Mike Hommey <[EMAIL PROTECTED]> writes:
> If we're to say that we need a format such that external entities can
> easily parse it, that will need to be a standardized format, and an
> unique one. And despite what you'd like, I don't think this is git.
+1.
Saying that the plural 3.0 source format
On Sat, 17 May 08 20:40, Vincent Bernat wrote:
> OoO Lors de la soirée naissante du samedi 17 mai 2008, vers 17:57, Armin
> Berres <[EMAIL PROTECTED]> disait:
>
> > Replaces must not come with Conflicts.
> > Consider a package foo which contains a lot of architecture independent
> > files. One day
Le samedi 17 mai 2008 à 19:35 -0400, Joey Hess a écrit :
> No, the equivilant of those targets is the Source field in
> debian/control, and dpkg-source's plugin interface.
To sum up, you don’t want to standardize on an interface that would
force you to serialize your changes. And unless you do thi
Josselin Mouette wrote:
> Le samedi 17 mai 2008 à 19:14 -0400, Joey Hess a écrit :
> > The entire point of having support for multiple source formats in
> > dpkg-source, and allowing it to extract any of those formats, and build
> > a source package using any of those formats, is to allow multiple
On Sat, May 17, 2008 at 07:14:31PM -0400, Joey Hess wrote:
> Lucas Nussbaum wrote:
> > At some point, we will need to find a way to decide which v3 format we
> > are going to choose in adddition to the v3 (native) format (with a GR?).
> > We can't afford to allow several different v3 formats to coe
Russ Allbery wrote:
> Some of that divergence is, realistically, bugs that won't be fixed. For
> example, I patch the Shibboleth SP Makefile because I remove one XML
> schema which is under a non-free license (no modification allowed).
> Realistically, that upstream difference isn't ever going to
On Sat, May 17, 2008 at 10:57:54PM +, Joey Hess wrote:
> Pierre Habouzit wrote:
> > No I read them, and I'm interested in how you intend to do so
> > _automatically_. Because if it isn't automatic, then we're back to the
> > current situation _plus_ filing bug in our own BTS. I fail to see wh
Le samedi 17 mai 2008 à 19:14 -0400, Joey Hess a écrit :
> The entire point of having support for multiple source formats in
> dpkg-source, and allowing it to extract any of those formats, and build
> a source package using any of those formats, is to allow multiple
> formats to be used.
Indeed, b
On Sat, 17 May 2008, Joey Hess wrote:
> A mail to the bug is marked as a summary by a special pseudo-header
> or such, right?
Right. There will also be a control command so you can indicate a
message is the summary post-facto (or remove a summary.
Don Armstrong
--
why the hell does kernel-sou
Le samedi 17 mai 2008 à 15:53 -0700, Don Armstrong a écrit :
> If people actually decide to do this, it's not that huge of a deal to
> make whatever changes are necessary to the BTS to make packages with
> large numbers of such bugs easily manageable.
>
> [In fact, making the handling of packages
Lucas Nussbaum wrote:
> At some point, we will need to find a way to decide which v3 format we
> are going to choose in adddition to the v3 (native) format (with a GR?).
> We can't afford to allow several different v3 formats to coexist.
The entire point of having support for multiple source forma
Joey Hess <[EMAIL PROTECTED]> writes:
> The biggest reason for using the BTS is not technical. It's that, if we
> decide that the project will treat divergence from upstream as a bug,
> then we've effectively decided that maintainers will be responsible for
> both minimising unncessary divergence,
Don Armstrong wrote:
> > Other tags and BTS data can be used if desired. For example,
> > "divergence fixed-upstream", "divergence wontfix", "divergence
> > help". Versioning information can be used to track when an upstream
> > version resolves the divergence. Discussion and updated patches can
>
Le dimanche 18 mai 2008 à 00:29 +0200, Pierre Habouzit a écrit :
> And I believe the "automation" of sending bugs upstream unsolvable,
> because I tried to solve it, and failed. Of course, when upstream is
> Mailing-list driven this is easy. But when your upstream is KDE (or
> glibc, or ..) that
Don Armstrong wrote:
> One of the wishlist features for the BTS that I've been contemplating
> setting up is a "summary" feature, whre the current summary of a bug
> is shown at the top, with the history continuing below.
Ah, I think that's the thing I was remembering from the DEP thread.
A mail
Lucas Nussbaum wrote:
> (This discussion is similar to the one about DEPs vs BTS bugs -- a
> discussion on the BTS would always miss a "summary".)
IIRC someone (possibly me or maybe it was aj) posted a design to solve
the lack of a bug summary in the DEP thread.
--
see shy jo
signature.asc
Des
Pierre Habouzit wrote:
> No I read them, and I'm interested in how you intend to do so
> _automatically_. Because if it isn't automatic, then we're back to the
> current situation _plus_ filing bug in our own BTS. I fail to see where
> the revolution is.
>
> And I believe the "automation" of s
On Sat, 17 May 2008, Joey Hess wrote:
> Mike Hommey wrote:
> > The BTS would also need something to make it easier to spot patches in a
> > bug. Patch tracking is one of the few things bugzilla is not bad at, for
> > instance.
>
> I guess you're talking about a way for the BTS allow downloading o
Russ Allbery wrote:
> At first glance, I liked this idea in general, but some of the details
> make me wonder if the same concept implemented as a patch tracker separate
> from the BTS would work better. I'm still not sure, though, so some
> thinking out loud about the pros and cons.
Sure (and I
On Sat, 17 May 2008, Pierre Habouzit wrote:
> The BTS is not well suited for that, so we're back to discussing about
> which tool is best for doing that, as discussing how to do that in the
> source package failed, we go to the BTS.
If people actually decide to do this, it's not that huge of a d
On Sat, 17 May 2008, Joey Hess wrote:
> The bug can be tracked, with a patch, in our BTS. The bug can be
> forwarded upstream as the patch is sent upstream. A tag "divergence"
> can be used to query for all such bugs, or to sort such bugs out of
> the way.
It actually might even be useful to expos
On Sat, May 17, 2008 at 10:07:33PM +, Joey Hess wrote:
> > > In my original mail, I said that bugs tagged as divergences could
> > > likewise be sorted out of the way.
> >
> > I'm not convinced
>
> You're not convinced that divergences could be sorted out of the way in
> the bug display? Is
On 17/05/08 at 23:00 +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote:
> > On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
> > > All in all, pointing to VCSes is just making things harder, because
> > > you fight against direct product o
On 17/05/08 at 17:01 -0400, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote:
> I think it's about time to file mass bugs on whatever packages are left that
> use version control and lack the fields.
Unfortunately this is not easy to do, as least not as "mass bug filing".
Point is that it is not easy to spot which
Mike Hommey <[EMAIL PROTECTED]> writes:
> On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:
>> Also, these aren't bugs in the Debian package, but rather bugs in
>> upstream (at least arguably), which put them into a different
>> brainspace than Debian bugs at least for me, and I'd find
Pierre Habouzit wrote:
> The 3 first. I assumed that everyone knows it's best to present a
> summary of your idea in the first paragraph.
You seem to have actually missed the second sentence, "A change might be
a bug in upstream, or in the debianisation, or in Debian for requiring
the change.".
On Sat, May 17, 2008 at 09:54:54PM +, Pierre Habouzit wrote:
> and tracking actual content (like patches, modifications of them, and if
> they got merged fully, partially, modified, rejected …) both ways.
And to be frank, when rereading that sentence, I know a project that
does that, and it'
On Sat, May 17, 2008 at 02:50:33PM -0700, Russ Allbery wrote:
> Also, these aren't bugs in the Debian package, but rather bugs in upstream
> (at least arguably), which put them into a different brainspace than
> Debian bugs at least for me, and I'd find it awkward and confusing to have
> them mixed
On Sat, May 17, 2008 at 09:38:06PM +, Joey Hess wrote:
> Loïc Minier wrote:
> allows solving a large percentage of the requirements, and already
> interoperates with other tools (including upstream BTSes and mailing lists).
If by "interoperates with upstream BTSes" you mean bts-link, then
i
Theodore Tso <[EMAIL PROTECTED]> writes:
> On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote:
>> In fact, despite being one of the big quilt advocates in the last round
>> of this discussion, I am at this point pretty much sold on using Git
>> due to its merges and branch support and ha
On Sat, May 17, 2008 at 09:42:47PM +, Joey Hess wrote:
> Pierre Habouzit wrote:
> > Okay, still I dislike the idea a lot.
>
> You actually only read the first sentence at first?
The 3 first. I assumed that everyone knows it's best to present a
summary of your idea in the first paragraph.
Joey Hess <[EMAIL PROTECTED]> writes:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite natur
On Sat, 2008-05-17 at 23:22 +0200, Pierre Habouzit wrote:
> Okay, still I dislike the idea a lot. the BTS is unusable past 100
> bugs.
? there are ways of managing lots and lots of bugs via custom scripts
and the SOAP interface or usertags or the filters at the end of each bug
index page.
> Fo
Pierre Habouzit wrote:
> Okay, still I dislike the idea a lot.
You actually only read the first sentence at first?
> the BTS is unusable past 100 bugs.
Every package accumulates > 100 closed bugs after some period of time,
and this does not make the BTS unusable for that package, because the
c
Loïc Minier wrote:
> The bug tracker is a tool for me; not everything needs to go via bug
> tracking.
I'm not thinking about using the BTS for this just because it happens to
be the hammer at hand, but instead because it looks to be a tool that
allows solving a large percentage of the requiremen
On Sat, May 17, 2008 at 05:21:52PM -0400, Joey Hess wrote:
> Mike Hommey wrote:
> > The BTS would also need something to make it easier to spot patches in a
> > bug. Patch tracking is one of the few things bugzilla is not bad at, for
> > instance.
>
> I guess you're talking about a way for the BTS
On Sat, May 17, 2008 at 09:22:53PM +, Neil Williams wrote:
> email from incoming that a new version needs to be prepared for Emdebian
> because it nearly always fails first time, despite working last time.
welcome to our (mostly Aurélien's) world, because if you see the
revisions, you'll kno
On Sat, 2008-05-17 at 23:08 +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
> > What if we just decide that changes made to upstream sources[1] qualify
> > as a bug?
>
> WTF ? What's the point of free software if we invent rules for not
> modifying them
On Sat, May 17, 2008 at 09:13:03PM +, Mike Hommey wrote:
> On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
> > On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
> > > What if we just decide that changes made to upstream sources[1] qualify
> > > as a bug?
> >
> > WTF
Mike Hommey wrote:
> The BTS would also need something to make it easier to spot patches in a
> bug. Patch tracking is one of the few things bugzilla is not bad at, for
> instance.
I guess you're talking about a way for the BTS allow downloading of the last
(or preferred) patch sent to a bug. And
Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
>> On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]>
>> said:
>>
>>
>> > (publishing my branch in a gitweb) isn't normalized, and won't
>> > probably ever be, o
On Sat, May 17, 2008 at 11:08:06PM +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
> > What if we just decide that changes made to upstream sources[1] qualify
> > as a bug?
>
> WTF ? What's the point of free software if we invent rules for not
> modifyi
On Sat, May 17, 2008, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
The bug tracker is a tool for me; not everyth
On Sat, May 17, 2008 at 05:01:08PM -0400, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows f
On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug?
WTF ? What's the point of free software if we invent rules for not
modifying them ? And well, we're in a bad posture then, because glibc
without patche
What if we just decide that changes made to upstream sources[1] qualify
as a bug? A change might be a bug in upstream, or in the debianisation,
or in Debian for requiring the change. But just call it a bug.
Everything else follows from that quite naturally..
The bug can be tracked, with a patch, i
On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote:
> On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
> > All in all, pointing to VCSes is just making things harder, because
> > you fight against direct product of VCSes, workflows, and almost
> > packages. And no tool is
On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote:
> On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
> > On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]>
> > said:
> >
> >
> > > (publishing my branch in a gitweb) isn't normalized, and won't
On Sat, May 17, 2008 at 07:05:20PM +, Joey Hess wrote:
> And conversely, as upstream I'm git-aming patches emailed to me every
> day from people from all over, including other distributions, and that
> works quite well. The quality of the patches is often high since they are
> worked up to the
On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote:
> On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said:
>
>
> > (publishing my branch in a gitweb) isn't normalized, and won't
> > probably ever be, or not under this form.
>
> Don't you think that
Josselin Mouette wrote:
> Are you deliberately omitting the sane formats to distribute patched
> debian sources that are implemented?
I'm talking about the formats that I expect to be using. The implication
thst I'm somehow insane is not very useful.
--
see shy jo
signature.asc
Description: Di
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote:
> George Danchev wrote:
> > Then comes even more, even Ben Laurie (as he writes in
> > his blog) with all his aggression missed to find the debian's pkg-openssl
> > VCS
> > repo [1] unless he has been helped by someone at some point. I'm
Le samedi 17 mai 2008 à 15:12 -0400, Joey Hess a écrit :
> > Aren't "patch files in debian/patches/ with some headers" a defined
> > interface?
>
> It's an interface, that if you stop there in defining it, means that I
> have to check debian/patches/ into revision control, and bloat my
> .diff.gz
Le samedi 17 mai 2008 à 11:51 -0500, Manoj Srivastava a écrit :
> > Diffing the tips of branches in a SCM will not show you which lines
> > were changed by which changeset. If you want that information - which
> > is one of the most useful ones, because the same file can be changed
> > for many dif
Raphael Hertzog wrote:
> On Fri, 16 May 2008, Joey Hess wrote:
> > Coming up with a complex set of requirements that everyone has to follow
> > up front in their workflow[1] is not going to yeld the best results, and
> > I think that's my core reason for disliking Raphael's proposal. Now, if
> > yo
Theodore Tso wrote:
> How often is a logical change more than just a single commit?
I think the most common case for me is when I need to bring the change
forward to new upstream versions (with conflicts). In that case, I'll
end up with multiple commits in the VCS hostory for the change.
> So nor
Raphael Hertzog wrote:
> A VCS surely allows browsing and examining patches. But when I dig in a
> VCS history, it's because I have something precise to look up, I will
> rarely check it ouf of curiosity. debian/patches/ on the contrary is
> something that gets my attention when I unpack a source p
On Saturday 17 May 2008, Joey Hess wrote:
> George Danchev wrote:
> > Then comes even more, even Ben Laurie (as he writes in
> > his blog) with all his aggression missed to find the debian's pkg-openssl
> > VCS repo [1] unless he has been helped by someone at some point. I'm not
> > against the VCS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
we had to have this
http://xkcd.com/424/
a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFILybU9B/tjjP8QKQRAr5xAJ4gI/2k/LQqlsVKWXtCW0Nsli0RPgCfTSMH
fCHEC7M6erNUs
On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote:
> In fact, despite being one of the big quilt advocates in the last round of
> this discussion, I am at this point pretty much sold on using Git due to
> its merges and branch support and have started to switch my packages over.
> Howeve
OoO Lors de la soirée naissante du samedi 17 mai 2008, vers 17:57, Armin
Berres <[EMAIL PROTECTED]> disait:
> Replaces must not come with Conflicts.
> Consider a package foo which contains a lot of architecture independent
> files. One day you decide to split the arch independent files into a new
George Danchev wrote:
> Then comes even more, even Ben Laurie (as he writes in
> his blog) with all his aggression missed to find the debian's pkg-openssl VCS
> repo [1] unless he has been helped by someone at some point. I'm not against
> the VCS repo (I myself use some for my packaging), I jus
On Sat, 17 May 2008 09:07:08 +0200, Mike Hommey <[EMAIL PROTECTED]> said:
>> I find a quilt series to not fit the bill very well. On the other
>> hand, creating ./debian/topics/foo/ with a git-format-patch series
>> for each branch in there might be doable -- but then, these
>> individual patches
On Sat, May 17, 2008 at 11:51:22AM -0500, Manoj Srivastava wrote:
> On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette <[EMAIL PROTECTED]>
> said:
>
> > Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit :
> >> diffing the tips of branches in a SCM has been far more friendly. So
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said:
> (publishing my branch in a gitweb) isn't normalized, and won't
> probably ever be, or not under this form.
Don't you think that Vcs-Browse and Vcs-$SCN headers are
normalized ways for telling end users wher
On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette <[EMAIL PROTECTED]> said:
> Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit :
>> diffing the tips of branches in a SCM has been far more friendly. So
>> I find my old and new SCM's preferable to a quilt series -- since any
>> f
On Saturday 17 May 2008, Vincent Untz wrote:
> Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit :
> > On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
> > > [I'm not subscribed to debian-devel, so feel free to cc me if you want
> > > to keep me in the loop]
> >
> > done.
>
On Sat, May 17, 2008 at 03:48:03PM +0200, Alexander Bürger <[EMAIL PROTECTED]>
was heard to say:
> 0==0
> Info for debian-devel: we try to figure out how to package figtoipe.
> Before version 6.0pre30-1, a version of figtoipe was
On 17-May-08, 04:30 (CDT), Vincent Bernat <[EMAIL PROTECTED]> wrote:
> [This message is about using Replaces without Conflicts]
>
> I am not sure either. As you noted, the policy does not say to not use
> it alone, but this just seems odd to me. Let's hope that someone else
> will enlighten
Guillem Jover <[EMAIL PROTECTED]> writes:
> On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote:
>> That would work, although it does... well, not double, but at least
>> increase the work for any branch that also has a submission branch,
>> since any upstream merge conflicts have to be resol
On Sat, 17 May 08 11:30, Vincent Bernat wrote:
> OoO En cette fin de matinée radieuse du samedi 17 mai 2008, vers 11:17,
> Alexander Bürger <[EMAIL PROTECTED]> disait:
>
> >> When using Conflicts and having files in common with the other package,
> >> you need Replaces as well. Otherwise, durin
Le Sat, May 17, 2008 at 11:36:00AM +0200, Cyril Brulebois a écrit :
> On 17/05/2008, Charles Plessy wrote:
> > Other idea: when the package is produced through a workflow that uses
> > debian/patches, shipping them in /usr/share/doc/package/patches.
>
> Do you really want that?
> openoffice.org_2.
Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit :
> On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
> > [I'm not subscribed to debian-devel, so feel free to cc me if you want
> > to keep me in the loop]
> done.
>
> > + it also seems that some debian developers would pr
OoO Vers la fin de l'après-midi du samedi 17 mai 2008, vers 16:02,
Vincent Fourmond <[EMAIL PROTECTED]> disait:
> Vincent Bernat wrote:
>> The valid way to replace a file without conflicting with a package is to
>> use diversion. This is not a solution in your case because you would
>> h
Hello,
Vincent Bernat wrote:
> The valid way to replace a file without conflicting with a package is to
> use diversion. This is not a solution in your case because you would
> have to ask maintainer of ipe to use diversion too and since figtoipe is
> no longer shipped with ipe, he won't be
Hi,
0==0
Info for debian-devel: we try to figure out how to package figtoipe.
Before version 6.0pre30-1, a version of figtoipe was included in the ipe
package. Since then, figtoipe is a separate upstream package and also
gone from
* Martin Uecker
| Tollef Fog Heen wrote:
|
| > How would you go about doing that? If you just mean «all packages
| > should be built on the buildds», that's fairly easy to do, but if you
| > are talking about actual verification of source => binary which can be
| > done post-mortem, that's much
On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote:
> [I'm not subscribed to debian-devel, so feel free to cc me if you want
> to keep me in the loop]
done.
> + it also seems that some debian developers would prefer the VCS way
>instead of patches.debian.org. Well, if all the debian
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote:
> > To me this one proof more than even when VCS are used to maintain
> > packages, our source packages must clearly identify the Debian patches
> > that are applied.
>
> You're insinuatiog that a VCS does not allow easily browsing and
> e
On Fri, May 16, 2008 at 08:07:38PM +0200, Goswin von Brederlow wrote:
> >> Someone recently posted an example of this. IMO we should write a DEP
> >> on patch management and standardize those headers. And probably enforce
> >> their usage for patches on sensitive packages (lintian checks?).
> It wo
Le samedi 17 mai 2008 à 14:37 +0200, Lucas Nussbaum a écrit :
> If I understand things correctly (but I'm really not sure I do), 3.0
> (quilt) won't really help with that: it won't prevent maintainers to
> directly modify files outside of debian/ , and generate a huge
> debian/patches/debian-change
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote:
> Raphael Hertzog wrote:
> > I totally agree that we need to make our changes more visible. In the
> > openssl case, the patch in question is inside the .diff.gz and you don't
> > notice it in the unpacked source package. I tend to give a l
* Sune Vuorela
| 3) do the real ugly hack and invent a a-m-t-a depending on the default mta
FWIW, aa sorts together with å (after x, y, z, æ and ø (or ø and æ, in
da_DK, I think)) in some locales, so that might not be the best
choice.
--
Tollef Fog Heen
UNIX is user friendly, it's just pic
Tollef Fog Heen wrote:
> * Martin Uecker
>
> | Another problem I have argued about before, not directly related to this
> | incident, but IMHO another desaster waiting to happen: There is no
> | way to independetly validate that a debian binary package was
> | created from the corresponding sourc
On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote:
> In the general case, I do believe that the new source package format "3.0
> (quilt)" will help as all Debian specific changes will always end up in
> debian/patches/.
If I understand things correctly (but I'm really not sure I do), 3.0
(quilt) w
[I'm not subscribed to debian-devel, so feel free to cc me if you want
to keep me in the loop]
Le samedi 17 mai 2008, à 00:19 +0200, Raphael Hertzog a écrit :
> On Fri, 16 May 2008, Joey Hess wrote:
> > I can certianly see some good benefits to the lines that you're
> > thinking, but if this turns
Package: wnpp
Severity: wishlist
Owner: Stephane Glondu <[EMAIL PROTECTED]>
* Package name: mumudvb
Version : 1.2.5
Upstream Author : Brice Dubost <[EMAIL PROTECTED]>
* URL : http://mumudvb.braice.net
* License : GPL
Programming Lang: C
Description : Mul
1 - 100 of 106 matches
Mail list logo
