On Fri, May 16, 2008 at 05:13:24PM -0500, Manoj Srivastava wrote:
> On Fri, 16 May 2008 23:27:03 +0300, George Danchev <[EMAIL PROTECTED]> said:
>
> > On Friday 16 May 2008, Joey Hess wrote:
> >> Raphael Hertzog wrote:
> >> > I totally agree that we need to make our changes more visible. In
> >>
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, during upgrade, the user may see
>> error messages about you
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.4.0-6.diff.gz 82,595.1 kB
Not to mention all packages where an autoreconf run
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 feature can be compared to any other feature, or
> upstream, independently,
On 17/05/08 at 00:45 +0200, Miriam Ruiz wrote:
> 2008/5/16 martin f krafft <[EMAIL PROTECTED]>:
>
> > Lucas Nussbaum threw the idea of having a webpage with posisbly
> > annotated patches for each Debian package on *.debian.org at me the
> > other day, in response to the OpenSSL debacle. I really
* Thibaut Paumard:
> Actually, I seem to remember that the issue of critical packages being
> maintained by only one person have been pointed out here several times
> already this year (although I don't remember the particular
> threads). Certainly, such packages needs a better QA than the rest.
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
[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
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
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
* 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
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
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 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
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 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
* 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
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
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
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
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
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.
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
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 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
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 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, 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 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, 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 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
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
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
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
-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 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
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
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:
> 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
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
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
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
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 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
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 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 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
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 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
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, 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 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
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
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
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
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: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, 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
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
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
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
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, 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.
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: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
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: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'
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.".
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
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
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 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 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 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, 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
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, 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
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
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
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
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:
> > 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
>
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,
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
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
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 à 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, 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
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 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
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
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
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
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
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
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:
> 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:
> 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
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
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
1 - 100 of 106 matches
Mail list logo
