On Fri, May 16, 2008 at 03:27:42PM -0500, Adam Majer wrote:
Russ Allbery wrote:
Martin Uecker [EMAIL PROTECTED] writes:
In this case, the security advisory should clearly be updated. And all
advise about searching for weak keys should be removed as well, because
it leads to false sense
On Sat, May 17, 2008 at 12:45:20AM +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
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
the openssl
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 your
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, and
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 liked it!
* 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 :
[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) won't
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 source.
* 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
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 look to
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
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 would be
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
examining
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
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
have to
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 prefer the
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?
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, during upgrade,
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 resolved on
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 us on
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.
+ it
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
feature
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 where
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
I find
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 might
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 just
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.
However,
-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
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 repo (I
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
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
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
you can
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 different
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 or
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 not
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:
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
probably
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,
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 patches
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 from
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
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
modifying them
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, or not under this
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 ? What's
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 know
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 allow
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
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
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.
For
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
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 have
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
it's
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 in
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's
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 it
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 of VCSes,
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 there
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 expose the
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
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 of the
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 sending
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
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 to
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 uses
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
be CCed to
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 formats
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 with
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
--
Clint why the hell does
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, but
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 where
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 go
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 coexist.
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 this
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 you
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 formats
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 of
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 debianisation,
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
divergences when
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. Though
1 - 100 of 206 matches
Mail list logo
