Adam McKenna <[EMAIL PROTECTED]> writes:
> On Wed, Feb 22, 2006 at 05:55:01PM -0800, Thomas Bushnell BSG wrote:
>> Adam McKenna <[EMAIL PROTECTED]> writes:
>>
>> > As far as the second statement being the reason that most of us want
>> > ndiswrapper i
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote:
>> Help me out then. You seemed to suggest that not putting ndiswrapper
>> in main would be to "ignore rules that are very clearly laid out in
>> the SC
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Fri, Feb 24, 2006 at 09:56:46AM -0800, Thomas Bushnell BSG wrote:
>> I think this is clearly incorrect. The DFSG and the SC do not say
>> anything about the requirements for main that I can see.
>>
>> And it is the
Michelle Konzack <[EMAIL PROTECTED]> writes:
> The first one load a BLOB/Firmware into a Hardware which runs
> ON the Hardware and not in the OS.
The OS *all* runs "ON the Hardware".
But Debian's determination is about what we distribute. We don't
distribute non-free things as part of Debian ma
Michelle Konzack <[EMAIL PROTECTED]> writes:
> If someone use only "main" she/he will never install ndiswraper
> and will not code a free version. Let ndiswraper stay in "main"
> will animate developers to code stuff.
My understanding is that it is currently in main, right?
How many people hav
Adam McKenna <[EMAIL PROTECTED]> writes:
> Taking it out of main moves us in the wrong direction if our goal is to
> give our users a *usable* operating system, as opposed to some kind of
> 'proof of concept' OS that some people here seem to want to create, but
> that the majority of our users wil
Michelle Konzack <[EMAIL PROTECTED]> writes:
> What dou you think about the idea, that because non-free drivers and
> firmwares are droped from "main" we write wrapers and loaders which
> GET the drivrs and firmwares from the manufacturer provided DriverCD's.
This is a very suboptimal solution.
Adam McKenna <[EMAIL PROTECTED]> writes:
> As I said earlier, it prevents us from integrating ndiswrapper-supported
> devices into the installer so that users can enable their wireless devices
> during install.
I'm afraid I don't see how this works out.
Why can't you integrate such things into
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote:
>> It seems to me that there is no reason ndiswrapper can't be available
>> to the installer whether it's in main or contrib.
>
> AFAIK, it would
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Feb 27, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> Better we spend our time actually supporting the hardware with free
>> software.
> There is almost none. At most you can choose if you want to get your
> p
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote:
>> On Feb 27, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>>
>> > Better we spend our time actually supporting the hardware with free
>> &g
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote:
>> Ok, then we could put selected packages from contrib on the first CD,
>> provided they are DFSG-free, without causing any problems. Since
>> ndiswrapper
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Feb 27, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
>> If it were put in contrib (by accident, say), how would this cause a
>> problem, assuming that the installer problem was fixed? What specific
>> problems
Michael Poole <[EMAIL PROTECTED]> writes:
> It has been argued in this thread that if ndiswrapper were put in
> main, it would mean that contrib has no point at all. One could
> equally well argue that if ndiswrapper were put in contrib, main would
> have no point at all.
I'm afraid that's not a
Adam McKenna <[EMAIL PROTECTED]> writes:
> The question is not what problems it would cause. The problems are side
> effects. It should stay in main because it is free software that is able to
> be used by at least some subset of our users, without any non-free software.
Ok, this seems to be a
Michael Poole <[EMAIL PROTECTED]> writes:
> Under the default configuration the last time I installed Debian, the
> contrib section is not used; arguing that some future technical change
> might change that behavior leaves the issue open until that change is
> actually made.
As I have said, we
Adam McKenna <[EMAIL PROTECTED]> writes:
>> What is the subset of our users which would find ndiswrapper useful,
>> without the use of free software? I have heard some say that there
>> are no free drivers around for ndiswrapper to wrap. If that's true,
>> then wouldn't that make the subset in q
Stephen Gran <[EMAIL PROTECTED]> writes:
> ndiswrapper is a piece of free software. It does not need non-free tools
> to build, and it will execute as a standalone app without any drivers.
> The fact that most people use it to enable non-free drivers to work is
> largely irrelevant - most people
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Adam McKenna <[EMAIL PROTECTED]> writes:
>>
>> > On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote:
>> >> It seems to me that t
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Stephen Gran <[EMAIL PROTECTED]> writes:
>>
>> > ndiswrapper is a piece of free software. It does not need non-free
>> > tools to build, and it
Stephen Gran <[EMAIL PROTECTED]> writes:
> Well parroted. Since I can see you don't understand the difference
> between main and contrib, I will point you to it. Please see 2.2.1 and
> 2.2.2 in policy. If you diff the first set of bullet points that lay
> out criteria for main and contrib, you'
Michael Poole <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG writes:
>
>> I do not see anywhere in the SC or the DFSG reference to the "main"
>> vs. "contrib" distinction. Perhaps I have missed it; can you please
>> point me to it?
>
>
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote:
>> Let's see, maybe you didn't read the paragraph where I said:
>
> I did.
>
>> Is this CIPE? Or is that some other case?
>
> No, it'
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote:
>> Let's see, maybe you didn't read the paragraph where I said:
>
> I did.
>
>> Is this CIPE? Or is that some other case?
>
> No, it'
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote:
>> The question is not whether there is such a dependency declared; the
>> question is whether the software is useful without the use of non-free
>> software
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote:
>> The tech-ctte is there to address technical disputes.
>
> This isn't a technical dispute, it's an ideological one. The technical
> details very c
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote:
>> This lists several signs that a package requires another package, but
>> it is not presented as an exhaustive list. If you use a broad
>> definition of "require", it is reasonable to exclu
I have uploaded gnucash 1.9.1 to the experimental archive today. This
is the long-awaited GNOME-2 version of gnucash.
Users of gnucash who are willing to use this experimental software are
desired. It is not a good idea for every casual user to use it (or I
would have put it in unstable), but t
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote:
>> I guess I think the right test is: "Is this package useful in a system
>> with only free software on it?" Useful is a pragmatic question; if
>
Stephen Gran <[EMAIL PROTECTED]> writes:
> Additionally, the use of the phrase "useful in a system with only free
> software on it" is not something I can find in either 2.2.1 or 2.2.2
> (where the difference between main and contrib is spelled out) or
> anywhere in our foundation documents. Can
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 04:25:01PM -0800, Thomas Bushnell BSG wrote:
>> So I'm still at a loss; the only use of ndiswrapper, on a
>> free-software-only system, seems to be CIPE. Is that correct, or is
>> there some other
Stephen Gran <[EMAIL PROTECTED]> writes:
>> In any case, the real point here is the following statement from
>> 2.2.2, which says that contrib is for "wrapper packages or other sorts
>> of free accessories for non-free programs."
>
> Since ndiswrapper's main purpose is to create a kernel API to al
Adam McKenna <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote:
>> But I don't know; everyone seems to be dancing around the actual
>> question: are there any free drivers for which ndiswrapper is useful?
>> CIPE has
I recently uploaded gnucash 1.9.1 to Debian experimental, but this
doesn't seem to have affected buildd.debian.org. Is this normal?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Brian M. Carlson" <[EMAIL PROTECTED]> writes:
> On Mon, 2006-02-27 at 22:59 -0800, Thomas Bushnell BSG wrote:
>> I recently uploaded gnucash 1.9.1 to Debian experimental, but this
>> doesn't seem to have affected buildd.debian.org. Is this normal?
>
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>>
>> The reason this interests me is that this seems to be the key
>> question; it seems to me that if something is *now* not useful for
>> free-software-only syst
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote:
>> Or, perhaps it's not true that there are no free drivers for it. The
>> claim was also made that there was a single free driver out there for
>>
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> It's been answered a zillion times already, you just didn't accept the
> answer as valid. That's okay, but re-asking it again and again isn't
> going to give you a different answer.
My question was not answered. Is ndiswrapper useful on a
free-softwa
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> There are a few ways to interpret the word "wrapper". Ndiswrapper could
> certainly be seen as a "wrapper" of sorts, but not in the way that
> policy means. A "wrapper", as used in policy, is a script or small
> executable that will set up the environm
Michael Poole <[EMAIL PROTECTED]> writes:
> Looking at the first packages alphabetically in (main/)admin, one
> could ask the same question of a great many packages. The aboot*
> packages assume you have DEC/HP's SRM firmware on your machine.
> acorn-fdisk assumes that you have the Acorn RISC OS.
David Goodenough <[EMAIL PROTECTED]> writes:
> Did you include the SQL bits of gnucach?
The package I have uploaded does not support SQL. My intention is to
turn that on (I am uncertain yet whether it is worth making it a
separate package as it used to be) once 1.9.x has had a time to
settle.
I
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> * First, there is no guarantee that the experimental buildd network will
> build your package. We do a best effort to successfully build as many
> packages as possible, but it is not possible to guarantee that every
> package will be built on all
The latest gnome (2.12.2 according to Desktop>About GNOME) has, like
all previous "up"grades, disabled my preference for emacs-style
editing in forms, etc. It used to be in the Keyboard Preferences
dialog, but as I have become accustomed to seeing, the latest version
has removed more features, in
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> In any case, since the latest gnome has also disabled the help system
> (or rather, the most up-to-date manual is the accessibility guide for
> 2.8 and the user's guide for 2.6), where has the feature moved to this
> week
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>>
>> > In any case, since the latest gnome has also disabled the help system
>> > (or rather, th
Stephen Gran <[EMAIL PROTECTED]> writes:
> Feel free. I don't use gnome and don't really care. I just couldn't
> help being amused by a complaint about lack of documentation, under the
> circumstances.
Yeah, even if irrelevant to the circumstances.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTE
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Wed, Mar 08, 2006 at 11:15:46PM +0100, Pjotr Kourzanov wrote:
>> Steve Langasek wrote:
>> >Well, you shouldn't pass --host *except* when cross-compiling; the
>> >autotools-dev package shows how to do this. But at least --build is always
>> >a sane t
Russ Allbery <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
>> I'm one of the people who actually helped design the GNU Makefile and
>> configure standards, and --host does not "signal that you're
>> cross-compil
"Damyan Ivanov" <[EMAIL PROTECTED]> writes:
> Do you prefer to get bugreports via BTS or should these be forwarded
> directly upstream?
BTS is always good. It's fine if you also report them upstream; if
you submit them to the upstream bugzilla, please mention the correct
link in a "forwarded-to"
Norbert Preining <[EMAIL PROTECTED]> writes:
> Ok, there are no invariant sections, but there is (a short) front and
> back cover text.
>
> How do we proceed with these documents?
The resolution which passed excludes documentation with front cover
texts. Read it.
--
To UNSUBSCRIBE, email to [
Karsten Merker <[EMAIL PROTECTED]> writes:
> On Fri, Mar 18, 2005 at 06:58:50PM -0800, Thomas Bushnell BSG wrote:
> > Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes:
> >
> > > A much faster solution would be to use distcc or scratchbox for
[EMAIL PROTECTED] (Marco d'Itri) writes:
> That on some servers I'd like to mirror both archives, and I'd rather
> not waste a few GB on duplicated files.
So don't duplicate them and use fancier mirroring software.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
[EMAIL PROTECTED] (Paul Hampson) writes:
> That'll work. _All_ distcc sends to the crosscompiler is preprocessed c
> code to be compiled into object code. So the source-code building widget
> is compiled remotely, run locally, and the results are sent to compile
> remotely.
Oh, I see now. I was
David Schmitt <[EMAIL PROTECTED]> writes:
> Do you really want to know how many libraries in NEW currently are
> waiting for a binary with a new soname?
>
> One:
>
> liboil0.3 0.3.0-1
> source i386 unstable
> 2 months David Schleef #284486
>
> liboil 0.3.1-1
> source i386 unstable
> 2 d
Ben Collins <[EMAIL PROTECTED]> writes:
> Why does everyone have a sudden interest in the sparc buildds? It has
> always had one buildd until auric was no longer needed for ftp-master.
> Things were fine back then, and still fine now. No one complained then,
> why is everyone complaining now that
Ben Collins <[EMAIL PROTECTED]> writes:
> I think they are designed too stringently. Guidelines should describe the
> level of stability an arch is required to meet, and let the implementation
> be whatever is needed, on a per arch basis, to meet those requirements.
I think a reasonable requireme
Joerg Jaspert <[EMAIL PROTECTED]> writes:
> On 10234 March 1977, Thomas Bushnell wrote:
>
> > It appears that the following are all in NEW because they involve
> > such upgrades:
> > clanlib0.7
>
> At least this one looks like a hijack, not coordinated with the
> maintainer of clanlib. Atm I
Matthias Urlichs <[EMAIL PROTECTED]> writes:
> We can't. AFAIK: One or two rsync commands, and *that's*it*.
>
> Any required fanciness need to be done on the master server.
But that's your choice.
--I want to do this thing which you tell me not to do, and it hurts
when I do it.
--So stop d
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> I don't think the possibility of something like that being abused is as
> strange as you seem to imply. As proof of that statement, I faintly
> remember someone doing a gratuitous source upload just to provoke the
> buildds...
Of course, there was no
Matthias Urlichs <[EMAIL PROTECTED]> writes:
> The choice is to either restrict the required client-side fanciness to
> what most of our mirrors are willing to accept, or go without mirrors
> (OK, OK ... fewer mirrors anyway), which is something I don't think we'd
> want.
The whole point of SCC
Joel Aelwyn <[EMAIL PROTECTED]> writes:
> Either someone
> cares enough to write (or adapt) the management tools and it gets included,
> or they don't and it doesn't because nobody in their right mind would
> deploy it in any widespread fashion.
But the latter is already true, and irrelevant.
-
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Tue, Mar 22, 2005 at 12:28:36AM +, Roger Leigh wrote:
>
> > One suggestion: if any Ubuntu patches were CC'd to the Debian
> > maintainer, or filed in the BTS, they would get applied quicker. I've
> > now put your gimp-print changes back into my
Joerg Friedrich <[EMAIL PROTECTED]> writes:
> 1. The number of packages
>Debian never stopped growing, and there are packages which are
>unmaintained but they are still in the archive.
>Hey, if noone is willing to maintain a package, wait a grace period
>(30 days) and remove it fr
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Mon, Mar 21, 2005 at 06:43:45PM -0800, Thomas Bushnell BSG wrote:
>
> > Matt Zimmerman <[EMAIL PROTECTED]> writes:
> > > Many Debian maintainers would consider this unwelcome noise. In cases
> > >
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> The only distinction here is between merely publishing the patches on our
> website, and pushing the patch to the Debian maintainer immediately. We
> publish all of our patches relative to Debian on a regular basis, and make
> an honest effort to sort
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> The only distinction here is between merely publishing the patches on our
> website, and pushing the patch to the Debian maintainer immediately. We
> publish all of our patches relative to Debian on a regular basis, and make
> an honest effort to sort
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Mon, Mar 21, 2005 at 11:31:01PM -0500, Andres Salomon wrote:
>
> > These seem like excellent fodder for a FAQ/wiki, if there isn't one
> > already (a quick scan around Ubuntu's official and wiki FAQs didn't turn
> > up anything). Perhaps "How Ubuntu
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Mar 21, 2005 at 08:38:11AM -0800, Thomas Bushnell BSG wrote:
> > Matthias Urlichs <[EMAIL PROTECTED]> writes:
>
> > > The choice is to either restrict the required client-side fanciness to
> > > what
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Please don't rehash old arguments. Nobody has argued that we should put
> non-free packages into main, but we don't agree on what is free and what
> isn't for all types of packages.
Actually, nobody from the "more lenient" side has given a description
"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:
> Now, all this can be avoided very simply by a line in the init.d/ script
> for the daemon, checking that /proc is mounted. Since it will be mounted
> on normal systems but typically not when using a chroot shell, it serves
> as a flag to enable the d
"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:
> > There is nothing wrong with mounting /proc in a chroot; you should not
> > assume that chroots all lack /proc.
>
> Yes, I know, and I'm not. But it would be nice if one could prevent the
> packages from starting the daemons by simply choosing not
"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:
> > But you might need /proc.
>
> Well, I am starting to see that this might not be a good way to solve the
> problem but, still, if you need it, just mount it, and be aware that some
> daemons may come up and down on the server if you install or upgr
"Jorge L. deLyra" <[EMAIL PROTECTED]> writes:
> OK, I read you. Your message gave me the impression that something like it
> was already in place. That meaning doesn't have to be "this is a chroot",
> but just "don't start daemons", for whatever reasons there may be for that
> in any particular c
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Thu, Mar 24, 2005 at 05:37:02PM +, Henning Makholm wrote:
> > Scripsit Hamish Moffatt <[EMAIL PROTECTED]>
> >
> > > Please don't rehash old arguments. Nobody has argued that we should put
> > > non-free packages into main, but we don't agree on
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> Additionally, other kernels (such as the FreeBSD kernel) that do have
> a /proc do not have it functionally overloaded like the Linux one.
That's an excellent point. While it's likely that a /proc filesystem
will be written for the Hurd, it's very un
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 26, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > Actually, while there was lots of discussion, there wasn't actually a
> > proposal explaining what the reduced level of freedom would be and why
>
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 26, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > Actually, while there was lots of discussion, there wasn't actually a
> > proposal explaining what the reduced level of freedom would be and why
> >
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Mar 26, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > You kept saying nothing more than "we don't care about modifying them
> > because nobody will ever want to", which is, well, simply false.
&
Henning Makholm <[EMAIL PROTECTED]> writes:
> The only one who was aware that the outcome would change the release
> manager's position wrt. freedom bugs in sarge seems to have been the
> release manager himself. But that does not change the fact that it was
> common knowledge that the amendment w
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Frankly I can't spot the flaw in this approach. In general we want to
> distribute all useful bitstreams (programs, documentation and firmware)
> in Debian. However we are forced to disqualify the ones that don't have
> adequate freedoms. It's a subtra
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > And nothing there explains why firmware should have less freedom,
> > except for the claim that without this we won't be able to distribute
> > the drivers (and you say how important those drivers are).
>
> Maybe. But why won't you refute the argumen
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Sat, Mar 26, 2005 at 11:44:17PM -0800, Thomas Bushnell BSG wrote:
> > One reason for the DFSG's modifiability and source requirements is to
> > preserve our ability to fix things. I see no reason why we shouldn't
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Sure there is. Your motherboard FLASH can almost certainly be
> reprogrammed in the field, as can the FLASH in your video card, hard
> disk, and broadband modem. Probably not your monitor, admittedly.
> Why is it OK for those vendors not to provide you
[EMAIL PROTECTED] (Marco d'Itri) writes:
> > We should tell users: we are unable to support this hardware, because
> > we don't have the source. Among other things, we are unable to fix
> > security bugs in it.
> We are unable to fix security bugs in hardware with non-modifiable
> firmware and mo
[EMAIL PROTECTED] (Marco d'Itri) writes:
> (I already asked you to please stop Cc'ing me on every reply, what else
> do I need to do?)
Fix Debian's gnus. :)
> On Mar 27, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > > We are unable to fix sec
Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG
>
> | Huh? I'm not saying I pretend it isn't there. Do I want to modify
> | the source code? No, because there's nothing I could do with it if I
> | could.
>
> Sure there is, lik
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Thu, Mar 31, 2005 at 12:50:46AM -0800, Thomas Bushnell BSG wrote:
>> What I meant is that if the firmware is truly burned into the chup,
>> then I couldn't change it even if I had the source code. It was wrong
>&g
Matthew Garrett <[EMAIL PROTECTED]> writes:
>> Regardless, the point is what we distribute, not what is on my
>> computer.
>
> Why? How does it benefit Debian if our users have to obtain firmware
> from somewhere else to make their hardware work? How does it benefit
> freedom if we imply that ha
Matthew Garrett <[EMAIL PROTECTED]> writes:
> When people actually get around to a decent "Free firmware" campaign,
> then I think we'll have a stronger argument for not distributing
> firmware. At the moment, the non-freeness of firmware isn't something
> that seems to bother most people (even if
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> /etc/issue is meant for the sysadmin to edit. It is free form
> text. /etc/lsb-release is not.
All conffiles are there for the sysadmin to edit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL P
Matthew Garrett <[EMAIL PROTECTED]> writes:
> 1) Distribute the non-free firmware. Our users are happy.
> 2) Don't distribute the non-free firmware. Our users either download the
> non-free firmware from elsewhere (bad) or replace their hardware with
> parts that have the non-free firmware in flas
Hamish Moffatt <[EMAIL PROTECTED]> writes:
>> > Why? How does it benefit Debian if our users have to obtain firmware
>> > from somewhere else to make their hardware work? How does it benefit
>> > freedom if we imply that hardware with on-chip firmware is preferable?
>>
>> The DFSG says that's the
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Thu, Mar 31, 2005 at 11:09:21AM -0800, Thomas Bushnell BSG wrote:
>> Hamish Moffatt <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, Mar 31, 2005 at 12:50:46AM -0800, Thomas Bushnell BSG wrote:
>> >> What
Eduard Bloch <[EMAIL PROTECTED]> writes:
> That is bullshit/lies/cheating (pick one). It should be worded:
>
> "We are not willing to support his hardware just because we (at least
> some of us) decided to demonstrate how can we can strike against the
> non-freeness of the hardware development ass
Eduard Bloch <[EMAIL PROTECTED]> writes:
> As said, burn all hardware in your house. Now. Please. Then you have
> definitely defeated the evil non-freeness.
As I have said, I don't think non-free software is evil. I just think
it is not part of the Debian main archive.
--
To UNSUBSCRIBE, emai
Andreas Barth <[EMAIL PROTECTED]> writes:
> With these changes done, we are now on the home stretch for the sarge
> release. We are now only waiting on the arm buildds to recover and
> catch up to a reasonable extent, and on one last glibc upload -- and
> then sarge is FREEZING. This is, therefo
Matthew Garrett <[EMAIL PROTECTED]> writes:
> The choice is not between free firmware and non-free firmware. The
> choice is between firmware on disk and firmware on chip. That's the
> reality of the situation. I'd prefer us to adopt policies based on what
> currently exists, rather than on what m
Matthew Garrett <[EMAIL PROTECTED]> writes:
>> I'm ok with (1), provided we do it in the non-free archive.
>
> This does present certain logistical problems for producing installers.
A free kernel can't support that hardware. It's a shame, but it's
true. If we want an alternative installer with
Wouter van Heyst <[EMAIL PROTECTED]> writes:
> The awkwad situation would be that d-i is part of Debian, and non-free
> isn't, so anything in non-free can not be part of the installer?
> But having a (non-free) firmware section with components of that in the
> installer is ok?
If it's done right,
Andres Salomon <[EMAIL PROTECTED]> writes:
> It's also funny that people want debian to release so bad, and yet fight
> the release team at every announcement. I don't see a problem with
> wanting to know as much about transitions and migrations in advance as
> possible. I'm sure there will be a
401 - 500 of 1229 matches
Mail list logo
