Henning Makholm [EMAIL PROTECTED] writes:
If somebody designs and implements (after a suitable architectural
review) some software to support distributed keyring maintenance in a
secure, auditable way, it is likely that calls for adding more people
to the task would be considered more
Andreas Schuldei [EMAIL PROTECTED] writes:
i have not given up that hope yet and i invest a considerable
amount of time working on this issue as part of my work on the
DPL-Team. others there do so, too.
I hope this is true. I really do. However, I have no particular
evidence that it is
Marc Haber [EMAIL PROTECTED] writes:
What are you trying to do instead? If you might have noticed, we have
_just_ _another_ ftpmaster situation _right_ _now_, and from handling
of #339686 by a member of the DPL team I don't get the impression that
the DPL team actually cares.
I can't
Marc Haber [EMAIL PROTECTED] writes:
According to the reports of another member of the ftp-master team, the
situation was cleared up, but Mr. Troup re-enabled the check that
breaks dpkg-sig on purpose after not being amused about HE's rant on
here.
If this is accurate, it is not reasonable.
libgnutls-dev is a suitable substitute for libssl-dev when one wants
libssl.
However, libssl-dev provides *two* libraries; the other is libcrypto.
Is there a GPL-compatible replacement for the latter?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Steve Langasek [EMAIL PROTECTED] writes:
On Wed, Nov 23, 2005 at 11:43:27PM -0800, Thomas Bushnell BSG wrote:
libgnutls-dev is a suitable substitute for libssl-dev when one wants
libssl.
However, libssl-dev provides *two* libraries; the other is libcrypto.
Is there a GPL-compatible
Anthony Towns aj@azure.humbug.org.au writes:
.deb signatures are aimed at giving users some sort of assurance the
package is valid; but when you actually look into it -- at least in
Debian's circumstances -- those signatures can't actually give any
meaningful assurance for any specific
Goswin von Brederlow [EMAIL PROTECTED] writes:
The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving ftp.de.debian.org for the mirrors and/or
user. In no way does it prevent altering the
Vincent Sanders [EMAIL PROTECTED] writes:
However, we are in need of assistance! Recently ARM was separated
from testing as it is believed it was not keeping up. In fact, the ARM
buildds are generally keeping up well - the problem now is a large
pile of 131 maybe-failed packages [1]. To get
Adeodato Simó [EMAIL PROTECTED] writes:
* Thomas Bushnell BSG [Mon, 05 Dec 2005 10:28:43 -0800]:
Well golly gee. When I sent mail to [EMAIL PROTECTED], saying
that packages had failed due to temporarily missing build
dependencies, it was apparently ignored for weeks. It took the
release
Stephen Gran [EMAIL PROTECTED] writes:
Instead, you could hold a grudge and complain. That would be in keeping
with the Debian tradition, after all.
Not really holding a grudge; the problem was only just resolved
yesterday. In a week, it would be forgotten. It was just ironic.
Note: I am
Josselin Mouette [EMAIL PROTECTED] writes:
Le lundi 05 décembre 2005 à 16:19 -0500, Clint Adams a écrit :
The buildd maintainer is one of the 'notoriously difficult to reach'
people in Debian. If you were interested in trying, contacting the
mailing list for the port is the obvious next
Manoj Srivastava [EMAIL PROTECTED] writes:
On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote:
I can do the analyzing, but what should I do with the results?
Put them on a webpage so anyone can see
Steve Langasek [EMAIL PROTECTED] writes:
Er, did you even *read* this thread? We got on the topic of buildds because
*someone refused to help diagnose build failures because they consider it the
buildd admin's job*.
NO. We got on the topif of this because I said that I was not
interested
Anthony Towns aj@azure.humbug.org.au writes:
That's non-sensical. Everything the buildds do is logged pretty much
immediately onto http://buildd.debian.org/, which also provides long
running statistics on how effective the buildds are, and even a schedule
of what the buildds will be working
Anthony Towns aj@azure.humbug.org.au writes:
On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
That's non-sensical. Everything the buildds do is logged pretty much
immediately onto http://buildd.debian.org/, which also provides
Anthony Towns aj@azure.humbug.org.au writes:
The major task of buildd maintenance (aiui) is handlings logs though,
and that's certainly what was being complained about earlier.
No. What I was complaining about was totally ignoring of requeue
requests sent to the @buildd.debian.org advertised
Anthony Towns aj@azure.humbug.org.au writes:
On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
The major task of buildd maintenance (aiui) is handlings logs though,
and that's certainly what was being complained about earlier
Anthony Towns aj@azure.humbug.org.au writes:
The job of the buildd admin is to make sure packages are built. Mostly
that's automated, which is great, which means the buildd admin's job is
mostly to keep the automation working.
So when the build admin is not doing that job, what should we do?
Anthony Towns aj@azure.humbug.org.au writes:
Upstream is working on #335981 and #336371. In fact, scm has *never*
supported s390;
scm |5d9-4.1 | unstable | s390
And yet, it didn't actually run successfully on s390. Support is not
just a matter of compiling.
when I took
Anthony Towns aj@azure.humbug.org.au writes:
So why was the request ignored for a month? Why did my email result
in no action, twice, not even a response?
I've told you what I'd need to answer that question already.
Perhaps you don't know the answer to these questions. But then how
can
Anthony Towns aj@azure.humbug.org.au writes:
On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
Upstream is working on #335981 and #336371. In fact, scm has *never*
supported s390;
scm |5d9-4.1 | unstable
Anthony Towns aj@azure.humbug.org.au writes:
FTBFS issues are the most common though, as well as the easiest to
resolve; your point would carry more weight if you took the time to fix
yours first. (Looking through -private, I saw someone remark that 1000
bugs was too many -- we have got 1400
Anthony Towns aj@azure.humbug.org.au writes:
(a) seeing if the FTBFS can be fixed immediately, and finding it can't
(b) documenting (this is the transparent bit, so pay attention) that
fact by not having s390 incorrectly listed as a supported arch in
the source and ensuring it
Marc Haber [EMAIL PROTECTED] writes:
(BTW, I see #335981 and #336371 haven't received a response since late
October; or has raptor been down that entire time, so that you haven't been
able to diagnose it further -- it certainly seems down now?)
Upstream is working on #335981 and #336371. In
Anthony Towns aj@azure.humbug.org.au writes:
On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
(a) seeing if the FTBFS can be fixed immediately, and finding it can't
(b) documenting (this is the transparent bit, so pay
Anthony Towns aj@azure.humbug.org.au writes:
Then you're not maintaining your packages properly, and you're making
life more difficult for the rest of the project out of spite.
Notice that in disagreeing with your statement, I have also gone out
of my way to answer the specific questions you
Steve Langasek [EMAIL PROTECTED] writes:
I'm pretty sure I saw him do this already, by noting that it increases the
number of packages that the release and QA teams have to keep track of.
Seems to me that packages which aren't in testing should not occupy
the release team's time at all. Just
Steinar H. Gunderson [EMAIL PROTECTED] writes:
In my entire involvement with Debian from the development side, I've never
seen the NEW queue being processed as quickly as it is these days. It used to
be irritating to me -- it isn't today.
I have the same feeling. I would rather give
Anthony Towns aj@azure.humbug.org.au writes:
On Wed, Dec 14, 2005 at 12:26:50PM -0500, Joe Smith wrote:
It sounds to me like what is needed as a tag for bugs that tells QA (you
post noted that the release team
would ignore RC bugs on packages not in testing) that it can ignore those
bugs.
Thaddeus H. Black [EMAIL PROTECTED] writes:
3. If James' imperial rules are unacceptable to
us, then the alternative is to change the person
in James' position. It has been years since any
other option was credible. We all know this.
This means dismissing James from
Petter Reinholdtsen [EMAIL PROTECTED] writes:
I assume the DPL has been working in the background to try to resolve
this, as an public and open power struggle between the DPL and the
people in key privileged positions would soon become very ugly, and
affect the Debian project badly. How
A Mennucc [EMAIL PROTECTED] writes:
1) people who express kudos to FTP-masters for express accepting new
packages due to the C++ name transitions
2) Anand Kumria and Thaddeus Black criticizing FTP-masters for never
addressing 'mplayer' 'xvidcap' 'rte' and such
Once again, I think these
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, Dec 14, 2005 at 03:51:06PM -0800, Thomas Bushnell BSG wrote:
Steve Langasek [EMAIL PROTECTED] writes:
Rather, it seems much more likely that we would want to push such packages
*out* of unstable.
Really? So now, unstable should
Anthony Towns aj@azure.humbug.org.au writes:
Generally, experimental fits the above role. Unstable's for uploading new
development of packages that will hopefully work, but might turn out not
to. In particular, though, they need to be fixed pretty quickly -- six
months in experimental, and
Russ Allbery [EMAIL PROTECTED] writes:
Anand Kumria [EMAIL PROTECTED] writes:
A simple assurance that your package will be rejected from the NEW queue
if no ftp-master approves it within 2 weeks would actually be a benefit.
Why?
It seems like, if that's the way that you want the world to
Russ Allbery [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] writes:
Anand Kumria [EMAIL PROTECTED] writes:
A simple assurance that your package will be rejected from the NEW queue
if no ftp-master approves it within 2 weeks would
Goswin von Brederlow [EMAIL PROTECTED] writes:
Spare disk space isn't available to add amd64 to mirrors.
Spare bandwith isn't available to add amd64 to mirrors.
I see. Can we please have the numbers? Exactly how much disk space
is needed? Perhaps we can simply go ahead and buy more disks
Joey Hess [EMAIL PROTECTED] writes:
Oh, come on. vim-tiny entered the archive this week. The fact that we
have some slow buildds and ports like hurd-i386 that are perennially
behind is irrelevant to this discussion unless you can point to a build
failure log.
Maybe we shouldn't switch the
Steve Langasek [EMAIL PROTECTED] writes:
AIUI, Ubuntu isn't rotating their archive keys -- something else that their
centralized model more readily affords them.
I'm a little confused about why we do rotate the keys. I'm not
experienced in thinking through the subtle issues concerned, so I'm
Nick Phillips [EMAIL PROTECTED] writes:
On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote:
If the key is compromised, which is the only way the non-expiring key
method can be broken, then the expiring key doesn't seem to be
offering all that much additional security
Anthony Towns aj@azure.humbug.org.au writes:
How so? In the long term you end up with aj signed 2005, aj and 2005
signed 2006, 2005 is expired; I don't think there's anything broken in
that situation.
So I do trust aj's keys, and the keys he signs. Unfortunately, I
don't have any way to
Steve Langasek [EMAIL PROTECTED] writes:
For a user with a compromised local network, the only safe solution is to
validate the new key via some web of trust. This is the feature that's
missing today, to give Joe User some reasonable method of checking keys
against the web of trust before
Anthony Towns aj@azure.humbug.org.au writes:
Oh, the explanation for current practice is that if the key doesn't
change in practice, apps that look at the keys won't cope well with the
key changing, and when that becomes important, such as in the event of
a compromise, we'll have major
Anthony Towns aj@azure.humbug.org.au writes:
No, a key is only as good as (a) how hard it is to break; and (b) how
easy it is to trust. Key rotation helps make it harder to break (since
the 2004 key won't do you much good now); and also forces us to consider
how to make new keys easy to
Anthony Towns aj@azure.humbug.org.au writes:
On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
No, a key is only as good as (a) how hard it is to break; and (b) how
easy it is to trust. Key rotation helps make it harder
James Vega [EMAIL PROTECTED] writes:
The aptitude in unstable and testing has a feature that lists suggested
ways to fix broken packages.
Unfortunately, the feature doesn't work very well.
Frequently I say aptitude remove XXX and the first several
suggestions that aptitude comes up with is
Anthony Towns aj@azure.humbug.org.au writes:
On Sat, Jan 07, 2006 at 02:32:20AM -0800, Steve Langasek wrote:
This is inconsistent with Debian's past policies wrt stable releases,
namely, that it should be possible for a user to skip all point releases and
security updates (at the peril of
Stephan Hermann [EMAIL PROTECTED] writes:
- Do not use foul language; besides, some people receive the lists
via packet radio, where swearing is illegal.
Are you saying some people are transmitting the lists via radio
without taking personal responsiblity for their transmissions? Shame
on
Gustavo Franco [EMAIL PROTECTED] writes:
It's up to Canonical how they will contribute back to the community,
IMHO. I don't the same rant over others Debian related companies so
i'm assuming that we're wasting time shooting Canonical, (mainly)
because Ubuntu is sucessful.
No, I think it's
Jan Nieuwenhuizen [EMAIL PROTECTED] writes:
Thomas Bushnell writes:
No, I think it's because Ubuntu doesn't cooperate well with Debian,
while pretending to cooperate.
Does Debian want to cooperate with Ubuntu, and how well does Debian
do? What steps could Ubuntu and Debian reasonably take
Gustavo Franco [EMAIL PROTECTED] writes:
It was already discussed[0], and there's no consensus on this idea of
every Ubuntu changeset, a patch in Debian BTS between DDs.
Right. I want Ubuntu to exercise judgment, and not just give a big
pile of patches, some of which are Debian-relevant and
Benjamin Seidenberg [EMAIL PROTECTED] writes:
Oh, it gets even better. The fun part is that the one who wants to
receive the list may not be the one who actually transmits the signal
(and hence would be at fault). That'd be the transmitting station. for
those who are having trouble following,
Daniel Ruoso [EMAIL PROTECTED] writes:
Em Qua, 2006-01-11 às 14:36 -0800, Thomas Bushnell BSG escreveu:
Gustavo Franco [EMAIL PROTECTED] writes:
It was already discussed[0], and there's no consensus on this idea of
every Ubuntu changeset, a patch in Debian BTS between DDs.
Right. I want
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Jan 11, 2006 at 02:34:31PM -0800, Thomas Bushnell BSG wrote:
Ubuntu could report in the BTS all the bugs it finds, and submit patches
via the BTS.
As you know, most bugs are reported by users, not discovered by developers
We direct users
Reinhard Tartler [EMAIL PROTECTED] writes:
On 1/11/06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No, I think it's because Ubuntu doesn't cooperate well with Debian,
while pretending to cooperate.
Does Debian want to cooperate with Ubuntu, and how well does Debian
do? What steps
David Nusinow [EMAIL PROTECTED] writes:
http://www.ubuntulinux.org/ubuntu/relationship
Sponsored by Canonical, the Ubuntu project attempts to work with
Debian to address the issues that keep many users from using Debian.
...
When Ubuntu developers fix bugs that are also present in
Matt Zimmerman [EMAIL PROTECTED] writes:
I can't agree. From the sound of this and other threads, there are a number
of folks who are unlikely to be satisfied with any behavior on the part of
the Ubuntu project or its members. Fortunately, there are others who are
actively cooperating to
Matt Zimmerman [EMAIL PROTECTED] writes:
It doesn't say that Ubuntu fixes ALL Debian bugs, or any other absolute. It
does say that Ubuntu submits bug fixes to Debian through the BTS, and there
are in fact hundreds of such fixes in debbugs today.
Does Ubuntu do so for every bug it fixes, or
Steve Langasek [EMAIL PROTECTED] writes:
Every time you find a bug in an Ubuntu package, make some effort to
determine if it is Ubuntu-specific or might rather affect all Debian
users. If it is not Ubuntu-specific, then file a bug report, and
optionally, a patch, in the Debian BTS.
Which
Christian Perrier [EMAIL PROTECTED] writes:
While I'm sure there'll be some people who'll complain no matter what,
I don't see what the problem with mailing patches directly to the BTS
is. As far as tracking is concerned, making use of [EMAIL PROTECTED]
usertags or similar would seem
Raphael Hertzog [EMAIL PROTECTED] writes:
On Fri, 13 Jan 2006, Thomas Bushnell BSG wrote:
Um, I have said nothing against crediting maintainers in the
packages. I have only said that I would like Ubuntu to clearly label
which is the Debian maintainer and which is the Ubuntu maintainer
Kevin Mark [EMAIL PROTECTED] writes:
would it be usefull if the Ubuntu Maintainer would add a
'ubuntu-specific' usertag to those bugs in the Ubuntu BTS as a way of
telling Debian folks (as well as others) that they should not address
this bugs.
You aren't listening. Do not submit irrelevant
Theodore Ts'o [EMAIL PROTECTED] writes:
While I don't disagree with this sentiment, keep in mind that Debian
itself is sometimes guilty of adding changes to packages when the
upstream may or may not approve. Of course, we'll justify by saying
that users want it, or that it is in the best
Theodore Ts'o [EMAIL PROTECTED] writes:
On Sun, Jan 15, 2006 at 03:12:33PM -0800, Thomas Bushnell BSG wrote:
Actually, upstream maintainers have no voice before the technical
committee, which exists to resolve disputes between Debian developers,
not between Debian developers and outsiders
Theodore Ts'o [EMAIL PROTECTED] writes:
On Mon, Jan 16, 2006 at 12:44:01AM -0800, Thomas Bushnell BSG wrote:
I think this is not quite true. In any case, my recollection was that
the bad cooperation was a two-way street, with you being extremely
reluctant to acknowledge the concerns
Matt Zimmerman [EMAIL PROTECTED] writes:
The ratio of Debian developers to upstream developers is *much* closer to
1:1 than the ratio of Ubuntu developers to Debian developers, but even so,
my guess (based on at least some empirical observation of packages I'm
familiar with) is that many of
Matt Zimmerman [EMAIL PROTECTED] writes:
In my opinion, it's much more practical and reasonable for there to be an
agreement on consistent treatment of all packages, than for each Debian
derivative to try to please individual maintainers with differing tastes on
this subject.
Your strategy
Matt Zimmerman [EMAIL PROTECTED] writes:
It is important, in particular, to account for the fact that Ubuntu is not
the only Debian derivative, and that proposals like yours would amount to
Debian derivatives being obliged to fork *every source package in Debian*
for the sake of changing a
Matt Zimmerman [EMAIL PROTECTED] writes:
On Tue, Jan 17, 2006 at 12:37:15PM -0800, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
In my opinion, it's much more practical and reasonable for there to be an
agreement on consistent treatment of all packages, than for each
Matt Zimmerman [EMAIL PROTECTED] writes:
You quite obviously haven't read
http://lists.debian.org/debian-devel/2005/05/msg00260.html yet, where I
wrote (among other important things), it would be fairly straightforward
for Ubuntu to override the Maintainer field in binary packages. I
Matt Zimmerman [EMAIL PROTECTED] writes:
Besides which, do you honestly know which packages other Debian derivatives
rebuild? As a rule, they are far less communicative about their practices
than Ubuntu.
How does the behavior of other Debian derivatives matter?
As a rule, those other
Matt Zimmerman [EMAIL PROTECTED] writes:
If that were true, you wouldn't be having this conversation with me. It is
costing me an unreasonable amount of time to deal with this trivial issue,
and I've spent a disproportionate amount of it going in circles with you.
I'm quickly losing interest
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't think you can speak to what tools we do or do not have. The fact
is, we import most Debian source packages unmodified, and do not have any
such tool for modifying them.
It's really a very short perl script, or a simple modification in C to
the
Mike Bird [EMAIL PROTECTED] writes:
On Tue, 2006-01-17 at 17:29, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't agree. This isn't even the case within Debian. Binary-only NMUs
don't modify the source package, even though the binaries are recompiled
David Nusinow [EMAIL PROTECTED] writes:
On Tue, Jan 17, 2006 at 04:58:40PM -0800, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
If that were true, you wouldn't be having this conversation with me. It is
costing me an unreasonable amount of time to deal
Matthew Garrett [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No other Debian derivative, as far as I'm aware, says that it
cooperates fully with Debian.
Other than, say, the DCC Alliance?
I wasn't aware of them until just now. :)
Interestingly, the DCC Alliance
Matthew Garrett [EMAIL PROTECTED] writes:
Interestingly, the DCC Alliance says that it wants to become part of
Debian.
Do you have information on their plans with respect to the issues
discussed in this thread?
The DCCA distribution is a mixture of packages from Sarge plus some
Matthew Garrett [EMAIL PROTECTED] writes:
Have they modified these packages?
Some of them, yes. Mostly the backports.
What happens to the maintainer field in these cases?
Certainly, if they are modifying the packages, I would think the same
there here applies as in the case of Ubuntu: they
Reinhard Tartler [EMAIL PROTECTED] writes:
Oh. There might be a misunderstanding: No binary package is taken from
debian, only source packages. This means that EVERY package is being
rebuilt in ubuntu on buildds, including arch: all packages. The output
of apt-cache shows the field 'Origin'
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Jan 17, 2006 at 04:54:36PM -0800, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
Besides which, do you honestly know which packages other Debian derivatives
rebuild? As a rule, they are far less communicative about
Paul Johnson [EMAIL PROTECTED] writes:
On Tuesday 17 January 2006 16:54, Matt Zimmerman wrote:
You have not ever shown a serious interest in what Debian would like.
This is, again, insulting, and nonsensical in the face of the repeated
dialogues I have initiated and participated in with
Raphael Hertzog [EMAIL PROTECTED] writes:
I'm in line with David. Thomas, if you care about the topic, you must be
interested in convincing the one who can make a change on Ubuntu's policy.
And the person in question is Matt. If you scare your only interlocutor
with Ubuntu, then you can be
Matt Zimmerman [EMAIL PROTECTED] writes:
On Tue, Jan 17, 2006 at 05:29:40PM -0800, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't agree. This isn't even the case within Debian. Binary-only NMUs
don't modify the source package, even though the binaries
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't think you can speak to what tools we do or do not have. The fact
is, we import most Debian source packages unmodified, and do
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 11:21:32AM +0100, Thomas Hood wrote:
Steve Langasek wrote:
Given that python-minimal is Essential: yes in Ubuntu, the *only*
use for this package in Debian (given that there would be no
packages in the wild that depend on it
Matt Zimmerman [EMAIL PROTECTED] writes:
You can't stop that; you can't say here's the package, but nobody
should use it.
Fortunately, no one attempted to do that. What we did do was discuss our
plan with Python upstream and ensure that our treatment of the package
satisfied their
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 10:18:22AM -0800, Thomas Bushnell BSG wrote:
Reinhard Tartler [EMAIL PROTECTED] writes:
Oh. There might be a misunderstanding: No binary package is taken from
debian, only source packages. This means that EVERY package
Wouter Verhelst [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I don't agree. This isn't even the case within Debian. Binary-only NMUs
don't modify the source package, even though the binaries are
Matt Zimmerman [EMAIL PROTECTED] writes:
Don't you run wanna-build, buildd and sbuild? It is easy enough to
change the maintainer field with that.
Not in the source package, which is what was being discussed in that
context.
Huh? Actually, you'll find, they do!
Please show me
Matt Zimmerman [EMAIL PROTECTED] writes:
I believe there are still packages which break when bin-NMU'd (e.g.,
Depends: = ${Source-Version}), and there are parts of our infrastructure
which do not support them (Ubuntu doesn't do bin-NMUs).
That's correct. These are bugs, and should be
Ian Murdock [EMAIL PROTECTED] writes:
Fact is, the potential for confusion here never even occurred to
me when we started doing this at Progeny. Quite the contrary to what
Matthew suggests, it seems to me that changing the Maintainer
field is a perfectly reasonable thing to do now that I'm
Steve Langasek [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 06:47:22PM -0800, Thomas Bushnell BSG wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
I believe there are still packages which break when bin-NMU'd (e.g.,
Depends: = ${Source-Version}), and there are parts of our
Brian Nelson [EMAIL PROTECTED] writes:
I completely agree, and hereby question whether the secretary is capable
of being impartial in this case given his personal interests[1] in this
issue.
You may question it, but it doesn't affect the case.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Peter Samuelson [EMAIL PROTECTED] writes:
Do you really think users who fail to notice an Origin tag from
apt-cache, and believe they're above using reportbug, will notice an
-ubuntuN suffix in the version number? I don't. I think you are
arguing on abstract philosophical grounds rather
Matt Zimmerman [EMAIL PROTECTED] writes:
Why is it now important to you that the version numbers be changed,
though? This is only an issue when mixing packages between different
derivatives, which already breaks in other subtle ways, so I'm not very
much inclined to try to un-break it in
Matt Zimmerman [EMAIL PROTECTED] writes:
On Thu, Jan 19, 2006 at 06:38:55PM -0500, David Nusinow wrote:
On Thu, Jan 19, 2006 at 03:18:48PM -0800, Matt Zimmerman wrote:
On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote:
That said, I don't really understand why it's Ok for Ubuntu
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Jan 18, 2006 at 06:47:22PM -0800, Thomas Bushnell BSG wrote:
In any case, I want to note what has just happened here. You received
a clear, easily implemented, request about what would be a wonderful
contribution, and which is (from the Debian
Goswin von Brederlow [EMAIL PROTECTED] writes:
The problem also isn't our machines but some mirror in
low-diskspace-land.
The amount of disk it takes to carry a complete Debian copy is simply
going to be increasing. We have to tradeoff dropping a mirror or two
against the costs of weakening
Matt Zimmerman [EMAIL PROTECTED] writes:
On Thu, Jan 19, 2006 at 08:42:57PM -0800, Thomas Bushnell BSG wrote:
Programs that want to use python can assume that python-minimal is
there (since it's Essential), and since python-minimal is never
installed without python also installed, they can
1 - 100 of 1583 matches
Mail list logo
