Martin Michlmayr - Debian Project Leader <[EMAIL PROTECTED]> writes:
> One problem, as you say above, is that random people building packages
> are more likely to break things because they don't know about
> architecture specific problems.
I have not said anything about "random people", but rat
Ingo Juergensmann <[EMAIL PROTECTED]> writes:
> Either you trust me as a person or you trust some kind of software snippet,
> aka gpg key.
I don't know who you are. The snippet tells me who you are.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Conta
Stephen Frost <[EMAIL PROTECTED]> writes:
> Well, that's not *necessairly* true. If the buildd maintainer is also
> part of DSA/ftpmasters (as seems to often be the case, and might even be
> required by some unwritten law) then it'd be possible for them to
> disable the account doing the uploadin
David Schmitt <[EMAIL PROTECTED]> writes:
> Additionally, this hints at hidden problems of this architecture which - in
> the worst case - might lead to Debians sudden inability to support a
> really-stable release on this architecture. Regardless of the outcome of the
> post-Vancouver fallout,
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> Moving wanna-build to a mirror will mean that new source packages have
> to be in the archive for at least one mirror pulse before they get
> built. The m68k port has been working like that for a very long time
> (Since wanna-build's inception until a
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005-03-16 09:59]:
> > If the information in the Developers' Reference is no longer
> > correct, then fix it
>
> Can you please give a specific section so we know w
To be in SCC, under the proposal we're all discussing, an arch must
have build 50% of the archive, not counting arch-specific packages.
The Debian Hurd project has another category that should be excluded
because they are kernel-specific. (The current list on the web page
is update, makedev, ld.
One of the conditions for SCC is "fully functioning Unix, including
DNS and firewall support." What specifically is intended by "firewall
support"?
Those who felt this necessary, can you please describe which specific
features you believe are necessary, and why?
Thomas
--
To UNSUBSCRIBE, e
Matthias Urlichs <[EMAIL PROTECTED]> writes:
> Hi, Thomas Bushnell BSG wrote:
>
> > The Developer's Reference contains the procedures for binary NMUs.
>
> The BinNMU procedure covers the "a binary was built incorrectly and I can
> fix it without touchi
John Hasler <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG writes:
> > The Debian Hurd project has another category that should be excluded
> > because they are kernel-specific. (The current list on the web page is
> > update, makedev, ld.so, modconf, modutils,
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > One of the conditions for SCC is "fully functioning Unix, including
> > DNS and firewall support." What specifically is intended by "firewall
&g
Adrian Bunk <[EMAIL PROTECTED]> writes:
> It seems what makes Thomas suspicous is that of all current ports of
> Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is
> GNU/Hurd - this requirement is therefore either void for all current
> Debian ports or it was meant specifica
Ben Collins <[EMAIL PROTECTED]> writes:
> On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote:
> > In article <[EMAIL PROTECTED]> you write:
> > >I have an e3500 to replace both auric and vore (and the raid), but I
> > >haven't gotten an ok from James to do so yet.
> >
> > That would cu
Ben Collins <[EMAIL PROTECTED]> writes:
> The requirement sucks, lets leave it at that. If the machine dies, I can
> have two to replace it within a day or two.
>
> The point being, there's no reason to have two seperate machines when one
> can do the job. As long as it keeps up, then there shoul
Ben Collins <[EMAIL PROTECTED]> writes:
> Ok, I can guarantee that it never dies. The hardrives are raid 5
> configuration, and the power supplies are redundant, and if any of the
> three cpu/mem boards goes bad, I can just remove it and let the other two
> (4x cpu's and 4gigs ram) run. Then there
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> If you really want this fixed, I suggest finding someone who is well versed
> in both network security issues and Internet protocol fundamentals (not
> just TCP or even just IP, but all the other lovely beasties out there) and
> convincing them it's worth
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> * SCC systems have buildds.
>
> * Buildds must be network accessible.
>
> * The first rule of securing a machine exposed to the wilds is "Deny by
> default, allow by need".
Exactly which firewalling are the existing buildds doing? (I'm asking
for inf
Ben Collins <[EMAIL PROTECTED]> writes:
> Stop chasing red herrings, and just get back to work. Sparc has always
> been and always will be a maintained architecture.
Actually, work right now consists of answering paniced emails from my
students worried about their test on Friday, and waiting for
Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > getting things back. The point of the N+1 rule, as I understand it,
> > is to give a different kind of redundancy, so that we don't have to
> > wait a day or two.
>
> How many current debian services are
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> For buildds, since I don't run one as either local or DSA admin, I couldn't
> tell you offhand. I know what I'd *expect* them to be doing, as general
> guidelines, which closely resembles what I do on servers I deploy facing
> the net, but I don't know wha
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> Fine, if you want to get pedantic, the following is a bare minimum of
> capabilities I would expect from any network processing on a 'real'
> (non-toy) network stack, where 'network stack' means everything between
> hardware driver and delivery of data to
Bastian Blank <[EMAIL PROTECTED]> writes:
> It is simply a condition of ENOTIME. The buildd is setup, activate them
> needs 10 minutes, adding a entries to the ACL needs less. Setting up a
> w-b needs 1h, doing the work by hand needs much more time.
But that should not stop you from attacking the
Will Newton <[EMAIL PROTECTED]> writes:
> On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote:
>
> > ... and probably not for (that is, not unless you tell me otherwise):
> > > HPGL
> > > HTML
> > > HTTPS
>
> Traditionally I think these would use "an". Even if you pronounce "h" as
> "haich"
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> (This might be a topic without a possible conclusion!)
> Funny, but although I'd say "an HTML file" or "an HTTPS url" or
> similar, I'd say "a history achievement".
Ah, in "a history achievement", you accent the first syllable of
"history", which pr
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> If you have all of the filtering rule support, then why is this even an
> issue? Write the user-space tool and you should be golden; you've got a
> useable firewalling implementation.
>
> What's the problem?
Who said there was a problem? I was asking ex
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Thu, Mar 17, 2005 at 09:04:14AM -0800, Thomas Bushnell BSG wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> writes:
>
> > > (This might be a topic without a possible conclusion!)
> > > Funny, but although I
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > However, we are not expecting the DSA people to keep the system
> > secure; SCC non-released arches don't need to provide developer
> > machines.
&g
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > The Debian Hurd project has another category that should be excluded
> > because they are kernel-specific. (The current list on the web page
> >
Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:
> A much faster solution would be to use distcc or scratchbox for
> crosscompiling.
Debian packages cannot be reliably built with a cross-compiler,
because they very frequently need to execute the compiled binaries as
well as just compile them.
Gunnar Wolf <[EMAIL PROTECTED]> writes:
> I agree that any Debian architecture needs to provide basic networking
> facilities, but I don't think firewalling is a real requirement. Yes,
> of course, we expect users to actually _run_ this architecture, and
> they will probably be connected to the ne
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> > There would definitely be duplication of arch:all between ftp.debian.org
> > and ports.debian.org (let's call it ports), as well as duplication of the
> > source.
> As a mirror operator, I think
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Nov 13, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> I'm sorry, I was under the impression that every package in Debian was
>> software. Are you confusing software and computer programs?
> No, I j
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Nov 13, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> Are you saying that Debian has too much documentation? What is the
>> non-computer-program which we have "too much" of?
> No, I am saying t
[EMAIL PROTECTED] (Marco d'Itri) writes:
>> Personally, I'd like to read the papers. It's a shame that Debian
>> can't distribute them to me.
> Debian does not want, it's quite a different issue.
Debian does not want what? To distribute them? Hogwash. I'd be
happy to upload them.
--
To U
Henning Makholm <[EMAIL PROTECTED]> writes:
> Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]>
>
>> It seems to me that the papers at a Debian conference are almost all
>> related to programs in Debian.
>
> You expect no contributions about release procedu
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 se
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 un
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 reasona
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". Troubl
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 othe
Anthony Towns 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 validity.
Don't they g
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
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].
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 i
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
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 obv
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Wed, 7 Dec 2005 23:46:07 +1000, Anthony Towns
> 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 them, and i
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
interes
Anthony Towns 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 on next.
That tells
Anthony Towns writes:
> On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns writes:
>> > That's non-sensical. Everything the buildds do is logged pretty much
>> > immediately onto http://buildd.debian.org/, which also provides
Anthony Towns 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 addresses.
Thomas
Anthony Towns writes:
> On Fri, Dec 09, 2005 at 07:25:14PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns writes:
>> > The major task of buildd maintenance (aiui) is handlings logs though,
>> > and that's certainly what was being complained about earlier.
Anthony Towns 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?
Thomas
--
To UN
Anthony Towns 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 over maintenance
Anthony Towns 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 you so surely
Anthony Towns writes:
> On Fri, Dec 09, 2005 at 09:44:59PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns writes:
>> >> Upstream is working on #335981 and #336371. In fact, scm has *never*
>> >> supported s390;
>> >scm |5d9-4.1 |
Anthony Towns 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 _RC_ bugs at the mo
Anthony Towns 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 does not incorrect
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
Anthony Towns writes:
> On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns writes:
>> > (a) seeing if the FTBFS can be fixed immediately, and finding it can't
>> > (b) documenting (this is the transparent bit, so pay attent
Anthony Towns 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 asked.
Now, can we ex
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. Ju
"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 *g
Anthony Towns 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.
>
> If your pa
"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
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 t
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 uns
Anthony Towns 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 another two so far in
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
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 reje
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 t
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
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
>>
Anthony Towns 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 indicate that to apt-
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 befo
Anthony Towns 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 difficulties in coping.
Anthony Towns 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 trust, which we otherwis
Anthony Towns writes:
> On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote:
>> Anthony Towns 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
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
Anthony Towns 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 their system's secu
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
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 reaso
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
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 follo
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 Ubu
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 discovere
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.
>> >
>> >
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 pr
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
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,
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.
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 se
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 maintai
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 irrel
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
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,
>> n
201 - 300 of 1229 matches
Mail list logo
