Re: forwarding bugs to other packages
On Thu, Oct 21, 2004 at 01:28:41PM +1000, Brian May wrote: > >>>>> "Joel" == Joel Baker <[EMAIL PROTECTED]> writes: > > Joel> It would also presumably allow you to add a filter such as > Joel> "don't display any bug with a dependancy on any other > Joel> still-open bug"; thus allowing maintainers to have things > Joel> "automagically" show up again once the bug they're waiting > Joel> on has been resolved. > > If you do this, different types of dependancies (or relationships) > might be desirable. eg: Possibly; depends on how hard it is to do, really, for the benefit. > bug x is bug y -- declaration that both bugs are the same, once y is > fixed x needs to be rechecked but is most likely > fixed. > > bug x depends bug y -- y must be fixed before work on x can > continue. Closing y doesn't mean x is fixed. > > bug x suggests bug y -- y might be a possible solution to this > bug. Other solutions/workarounds may also be > possible. Closing y means x is probably fixed > but needs testing. > > If more thought was put into this, I am sure we could come up with > something better. Well, that seems like a start, anyway. Really, I'd like some input from someone more familiar with the BTS code before going off into the wild blue yonder. It's possible this has been proposed and discarded before, for good reason, after all... or not. -- Joel Baker <[EMAIL PROTECTED]>,''`. : :' : `. `' `-
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote: > Wesley W. Terpstra wrote: > > True enough, but as processors get faster, so does bandwidth. > > I expect that ultimately, it will always need to be as fast as possible. > > Possibly; however, I think bandwidth grows far slower than CPU speed and > overall system power. I do understand your concern, though. Others have taken this up, but suffice to say: I wouldn't be so sure, unless you have concrete numbers. The main limiting factors on pushing bits these days are the price of lines (fiber is dropping that drastically, for various reasons, at least for long-haul) and the price of hardware that can push the bits at a high enough speed. I can't quote you numbers offhand, but having worked for 10+ years as a network engineer (up to and including senior engineer for an ISP covering 4 states), I can tell you what the budget looked like and why. > > Put the normal gcc version rsgt in main where the i386 deb has: > > Recommends: rsgt-icc > > You cannot put a Recommends from main to non-main; the strongest > relationship you can declare is Suggests. > > > rsgt-icc sits in contrib, completely built by icc (not just some .o s) > > > > Conflicts: rsgt > > Provides: rsgt > > Replaces: rsgt > > Right. > > > If an i386 user (with contrib sourced) runs 'apt-get install rsgt' > > will that make apt install rsgt-icc? That's what I hope to accomplish. > > No, I don't believe it will. That's why when packages change names, it > is common to still produce a binary package with the old name, which > does nothing except depend on the new package. That doesn't help you in > this case, of course. I think all you can do is add the Suggests: > rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other, > and provide a brief explanation in the README.Debian of both packages. Or have rsgt-icc and rsgt-dfsg, and have a package rsgt with: Depends: rsgt-dfsg | rsgt-icc Since the dependancy can be met only with items available from main, this is allowed (at least, as established in prior discussions), and is far more obvious to most people, I think, than a Suggests on the same package that one also has a Replaces/Provides/Conflicts. (In particular, 'Conflicts' and 'Suggests' together is likely to cause a great deal of brainache to the package install tools...) On a sidenote, the ability to "tune into" a stream of (potentially multicast) UDP packets at an arbitrary point, collect enough that you have >= the size of the file, and know that you can recover the file is something with *serious* potential from the network world point of view. My one question, as an operator, is whether that sequence of packets has to be sequential (it sounds like it doesn't, especially with the 20% packet loss problem description). If not, something like this could have *very* far-reaching impacts; if one turned on checksumming (available for UDP packets natively, or one could do it in the protocol) to avoid bitrot, this opens up a huge path to potentially simplifying a large set of problems (and no, they're more or less nothing like the ones par can solve, as for reasons discussed earlier by the author). -- Joel Baker <[EMAIL PROTECTED]>,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:26:23AM +1000, Brian May wrote: > >>>>> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > Bernd> On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: > >> I could just close the bug against my package, but this means other > >> people will encounter the same problem and report the bug against my > >> package again (as it isn't always obvious that it isn't the fault of > >> my package). > > Bernd> So you do not want to reassign them to the correct package? > Bernd> I dont think thats a good idea (even when i can understand > Bernd> where are you coming from). > > Like I said in my previous post, there are times when having 2 > separate bug reports is a good idea. > > e.g. you might think a reported bug in your package is due to a bug in > a library, so you reassign the bug report to the library. > > The library maintainer decides it isn't a bug in the library, and > prematurely closes the bug report. Or maybe the library maintainer > finds a bug, and fixes it, but it was an unrelated bug. > > You never get the indication that the bug report has been closed, and > the bug submitter gets totally confused and either doesn't follow up > (perhaps assuming the problem was fixed), or follows up to the wrong > person (as the bug is still assigned to the library). As such you > don't get a chance to followup and make sure the bug, initially > reported against your package, really gets fixed. > > Alternatively, when you reassign the bug to the library, the library > maintainer gets fed up because he already has 10+ bug reports on the > same issue. It strikes me that this problem is actually similar to a couple of others, and all of them could be reasonably resolved by a new concept in the BTS - bug dependancies. All it really says is "Some part of this bug depends on some part of bug #XX" - maybe you think the segfault is actually from a library and so you have no intention of trying to fix it until the library bug is fixed (at which point, you might well change your Depends entry versioning for the library, etc). Or maybe there's a feature request you're happy to add, but need to have another package support first (say, maybe you're adding alternatives to a variety of things, and they all need to update to provide it at roughly the same time, with versioned conflicts, to be happy). It would also presumably allow you to add a filter such as "don't display any bug with a dependancy on any other still-open bug"; thus allowing maintainers to have things "automagically" show up again once the bug they're waiting on has been resolved. Of course, I make no claim that the BTS folks won't want to rip my spleen out for bringing this up, but it does seem like it could be used to resolve a couple of different types of problem. (It also allows yet another way to avoid BTS tennis matches; if the maintainer of the other package doesn't agree that it's the same thing, put in a depends and wait for them to resolve whatever the bona-fide bug in their package is, rather than arguing about it.) -- Joel Baker <[EMAIL PROTECTED]>,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 08:50:48PM +, Henning Makholm wrote: > Scripsit Joel Baker <[EMAIL PROTECTED]> > > > The 'slander', if such it is (and I, obviously, don't consider it such) > > is against the named set of churches, and those that follow their doctrinal > > decrees > > Claiming that Christians are against civil liberties is slander in my > book. You named, among other, a subset of Christians that I belong to, > and claimed that our "doctrinal decrees" are against civil rights. > I hold this to be untrue, and unless you can back up your claims, I am > going to think of you as a liar. No, I claimed that the doctrinal decrees included condemnations of specific behavior which are turned into laws by a voting block that puts into power politicians who make laws based on those decrees, among other things. The end result of that process is one in which I am denied a specific civil right. > > But, like I said. I'm willing to back it up, in private. > > If you're not willing to back up your accusations in public, you > shouldn't make them in public. I already have, just not in this forum. Go read the other sources I listed. But if you want more context in which to read, I'll offer you two words: "Civil union" (I won't use "Marriage", because I find the mention of it in law to be one of the primary examples of religion intruding upon the secular law). And no, it's not same-sex unions that are at issue (as I said elsewhere). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpK6HUMUaVcO.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
[ Re-adding Cc to debian-bsd, since it's a serious naming proposal ] On Thu, Dec 18, 2003 at 03:12:05PM -0500, Jim Penny wrote: > On Thu, 18 Dec 2003 13:42:23 -0500 > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > Actually, I think daemons first showed up in the _Fiend Folio_, which > > means we have the British to thank for this confusion. ;-) > > > > What about Maxwell's daemon? This is usually thought to be the > computer origin of the term. 19th Century. > http://ei.cs.vt.edu/~history/Daemon.html Debian Faraday, Feynman, Fermi, ... Debian Newton, Nobel, ... Debian Ohm, Oort, Oppenheimer, ... Ladies and gentlemen (and the rest of y'all, too) - I submit that this might well be a winner. For nearly every letter in the alphabet, we have multiple possibilities, a great many of whom will be casually recognizeable to any geek audience, and quite a few of whom are dead and unlikely to object. (Oh, and for those playing along, there are two other interesting letters to check...) Debian Hale, Halley, ... (jeez. Hurd folks will have so many good choices!) Debian Landau, Lawrence, Leibniz, Lorentz, ... (oh, man - Linux gets Lovelace!) Debian Mach, of course, must be reserved for a FreeBSD-on-Mach port :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpVvekXXZ7pw.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 09:48:31AM -0500, Jaldhar H. Vyas wrote:
> On Thu, 18 Dec 2003, Russell Coker wrote:
>
> > On Thu, 18 Dec 2003 15:15, Joel Baker <[EMAIL PROTECTED]> wrote:
> > > The Anglican church is, in fact, the most likely among anyone except
> > > the UUs to (eventually) decide that it's OK, for the same reasons
> > > that they have (now) decided that it's OK to have gay clergy and
> > > formal recognition of committment ceremonies (they won't call it
> > > marriage, or treat it as
> >
> > What are the UUs?
> >
> > One Anglican minister I knew told me of a couple who had been living
> > together ("living in sin" as some people will say) for several years.
> > They approached him about arranging a wedding ceremony, and he
> > suggested that they need not bother as having established commitment
> > through living together for so long was good enough.
> >
>
> What would Henry VIII do?
Ck | N > K,S
And, from my upbringing, "Wherever you find three or four Episcopalians,
you'll find a fifth." (To those under the dominion of the Metric system, I
apologize; this probably won't seem very funny...)
--
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/NetBSD(i386) porter : :' :
`. `'
`-
pgpUt26d9tWQn.pgp
Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 05:21:23AM +, Henning Makholm wrote: > Scripsit Joel Baker <[EMAIL PROTECTED]> > > On Thu, Dec 18, 2003 at 03:05:46PM +1100, Russell Coker wrote: > > > On Thu, 18 Dec 2003 14:39, Joel Baker <[EMAIL PROTECTED]> wrote: > > > > > Imagining it? I suppose it's possible that I've hallucinated the > > > > stated positions of the Catholic, Luthern, Episopalian, Baptist, and > > > > Mormon authorities (the latter not technically being considered a sect > > > > So which civil rights are you referring to? > > > Details in a private reply > > So you're spewing slander across the broad spectrum of all or almost > all Christians and refusing to back up your allegations in public? > Yes, that will work well, methinks. Anyone who wishes to: 1) Email me privately and ask 2) Read my livejournal (hint: it's obviously named, and should show up trivally with Google) 3) Recall comments made on #debian-devel in IRC 4) Read comments made in other posts to Debian lists in the past or 5) Do other basic Googling will be able to figure out exactly what topic I'm talking about. It isn't that I refuse to discuss it in public; it's that I'm tired of discussing it in this thread, on this mailing list. The 'slander', if such it is (and I, obviously, don't consider it such) is against the named set of churches, and those that follow their doctrinal decrees (which may be, but almost certainly isn't, the same set as "their followers"; most people disagree with at least one doctrine of their chosen church, in my unscientific, empirical observation). But, like I said. I'm willing to back it up, in private. I just don't particularly care to keep debating it on this list, at the moment, particularly given how far off-topic we've come. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgprMcf3j43X9.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 12:52:00PM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Joel Baker) wrote on 17.12.03 in <[EMAIL PROTECTED]>: > > > Since you have no idea *what* civil rights I'm claiming are denied, your > > claim that I'm just imagining this denial is... well, I'll just let it > > stand on it's own, for people to evaluate it's backing. > > If I were a betting man, I'd bet I can guess what exactly it is - what the > Anglicans are currently in not-quite-civil-war about. Not quite, but it is a related issue somewhat further along the spectrum. One which, by it's nature, probably can't be addressed at all until the current fracas is settled (in a manner I'd consider favorable). It may be that, at some point in the future, the doctrinal statements change, especially that of the Anglicans; they seem one of the more likely. But, to date, it hasn't. > Of course, don't expect Nunya to ever get it. No comment. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpBHiOYpRFkx.pgp Description: PGP signature
Re: GNU within the name (Was: Changes in formal naming for NetBSD porting effort(s))
On Thu, Dec 18, 2003 at 12:06:56PM +, [EMAIL PROTECTED] wrote: > On Thu, Dec 18, 2003 at 12:56:15PM +0100, Julian Mehnle wrote: > > [EMAIL PROTECTED] wrote: > > > If we ever get a replacement libc that would really work as > > > replacement... on such system GNU claims would become much weaker. > > > Not that there was a serious chance of that happening - drop-in > > > replacement of glibc on Linux would be a lot of work and so far none > > > of the alternative libc projects had tried to pull that off. > > > > Why would anyone want to replace GLIBC in the first place? To get rid > > of "GNU" in "GNU/Linux"? > > glibc has its problems and alternative libc implementations do exist > (mostly for embedded use), but AFAIK none of them tries to become a > full-blown thing. > > As for the reasons why somebody would do such replacement... Beats me > - ask the guy who'd brought that up. IMO it's very unlikely, to put it > mildly. The impression (and, frankly, not an entirely clear one) I have gotton from RMS's various comments on the naming, especially in regards to NetBSD, boil down to the following (modulo probably screwing up the capitalization, which I can never remember the rules for, and I do apologize ahead of time): "GNU represents the Gnu system, running with a native (Hurd) kernel" "GNU/Linux is the Gnu system, using Linux as a kernel" What isn't entirely clear to me, here, is just how much composes "the Gnu system". It seems fairly clear to me that Robert Millan's work (which is Debian's normal core userland, GNU-based, plus GNU libc) is more or less identical to Debian's normal situation, but with a NetBSD kernel instead of Linux. Therefore, I'm fairly certain it could be called "GNU/NetBSD" (or, to make the NetBSD folks happier, "GNU/KNetBSD") and be precisely as accurate as "GNU/Linux". My porting work, however, uses the native NetBSD libc (and libm, and more or less everything coming from that particular part of the source tree). It still uses a primarily GNU-based userland (GNU coreutils instead of NetBSD cat, ls, etc; GNU compiler; GNU tar instead of NetBSD tar or pax; etc). To date, we had used "GNU/NetBSD" simply because it wasn't considered to be worth having the argument over, and we were still using quite a lot of GNU stuff, so figured it wasn't unreasonable to give them due credit (and that if RMS objected, saying it wasn't "the Gnu system", well, we'd be quite happy to drop the "GNU/" bit, of course...) None of this really applies to changing the Linux ports away from glibc, of course. But such a topic doesn't really belong on debian-bsd, anyway. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgp2thz5cJyxF.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 11:30:57PM +1100, Russell Coker wrote:
> On Thu, 18 Dec 2003 15:15, Joel Baker <[EMAIL PROTECTED]> wrote:
> > The Anglican church is, in fact, the most likely among anyone except the
> > UUs to (eventually) decide that it's OK, for the same reasons that they
> > have (now) decided that it's OK to have gay clergy and formal recognition
> > of committment ceremonies (they won't call it marriage, or treat it as
>
> What are the UUs?
Universal Unitarians. Sort of a cross between Christianity Lite and Pagan
Lite; a very "feel good" religion, for the most part.
> One Anglican minister I knew told me of a couple who had been living together
> ("living in sin" as some people will say) for several years. They approached
> him about arranging a wedding ceremony, and he suggested that they need not
> bother as having established commitment through living together for so long
> was good enough.
>
> Of course lots of vicars won't share that opinion. But in urban areas it's
> pretty common to shop around for a vicar who's opinions agree with yours
> anyway.
Well, yes. Like I said, many individual persons don't have any problem with
what I do, particularly not once they see the relationship for any length
of time. It's the collective that has issued policy statements condemning
it, and *that* tends to influence a lot of people's assumptions.
In other words, it's very much like someone saying "Black people are all
stupid and evil. Present company excepted, of course". (Note that I'm not
trying to claim the breadth or depth of bias that was, and often still is,
directed against that particular group; it's just an example that most
people will be able to put into context.)
--
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/NetBSD(i386) porter : :' :
`. `'
`-
pgphcwJHC8GoO.pgp
Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 03:05:46PM +1100, Russell Coker wrote: > On Thu, 18 Dec 2003 14:39, Joel Baker <[EMAIL PROTECTED]> wrote: > > Imagining it? I suppose it's possible that I've hallucinated the > > stated positions of the Catholic, Luthern, Episopalian, Baptist, and > > Mormon authorities (the latter not technically being considered a sect > [...] > > Since you have no idea *what* civil rights I'm claiming are denied, your > > claim that I'm just imagining this denial is... well, I'll just let it > > stand on it's own, for people to evaluate it's backing. > > So which civil rights are you referring to? > > The Anglican church seems to be doing reasonably well in terms of civil > rights recently (I think that they already have gay priests, and gay > marriage is being debated). Quite a number of Anglican ministers and > members of the congregation have defected to the Catholic church because > of this (and they apparently are not missed at all). > > I haven't been following the matter closely, I haven't been an Anglican > (or any type of Christian) for some time. Details in a private reply (and I'll send them to those who ask - privately; we're already so far off topic we're losing sight of dry land). The Anglican church is, in fact, the most likely among anyone except the UUs to (eventually) decide that it's OK, for the same reasons that they have (now) decided that it's OK to have gay clergy and formal recognition of committment ceremonies (they won't call it marriage, or treat it as such, but they WILL recognize an oath of enduring commitment sworn before God, under their doctrines - or at least, that is the summation of the ceremony issue that I was given by a member of said clergy and long-time friend, about a month ago, after the ordainment of the Bishop that caused the latest not-quite-schism). My personal experience is, in fact, that most members of the Anglican communion that I have contact with are, at worst (for me), somewhat discomfitted by a clash between doctrine and principle. They are the same people who voted to allow the recent changes. Which is one reason why I take issue with organized religion far more often than with people who happen to be members of it, but don't have personal problems with my actions - they happen to be the most likely to vote (in secular elections) against the implied vote that the doctrinal statement would expect. Or, to steal a quote, "A *person* is smart. *People* are dumb, stupid, panicky animals and you know it." -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpdMydc6X9DA.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 07:25:11PM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 07:56:41PM -0700, Joel Baker wrote: > > For the record, however, if you consider saying that the lifestyle or > > beliefs of someone you don't agree with are sufficient to condemn them to > > an eternity of suffering as hate speech (and I generally do), I'm on the > > catching end of such a statement from every person who supports, directly > > or indirectly, any sect of Christianity which I am aware of, all of whom > > advocate divine justice, and most of which also advocate the continued > > denial of civil rights as well. ^^^ > > > "Straw man" means imagining a problem and then attacking it, which is > preciesly what you are doing here. Imagining it? I suppose it's possible that I've hallucinated the stated positions of the Catholic, Luthern, Episopalian, Baptist, and Mormon authorities (the latter not technically being considered a sect of Christianity under most circumstances, but drawing from the same traditions). Somehow, though, I find this unlikely. I haven't bothered to look closely at the smaller and more fundamentalist sects. The Unitarians might have a different position; they seem the most likely. But they don't have enough voting members to succeed against the above. Since you have no idea *what* civil rights I'm claiming are denied, your claim that I'm just imagining this denial is... well, I'll just let it stand on it's own, for people to evaluate it's backing. > You all are so blatantly just stating your opinions as objective fact, > so it's pretty hopeless. I've tried to appeal to your sense of "fair > treatment" to all humans, which is a sentiment common to all decent > people. Fair treatment is exactly what I'm claiming is being denied me, by the large religious voting block formed by adherents of the above-listed religions, which form a significantly more than majority share of the population of the United States, and the state of Colorado, today, when they vote to support politicians who adhere to the position statements of those institutions and their followers. > I don't need to attack you: you're attitudes will turn off a sufficient > percentage of people on their own. I cannot respond to this in any fashion that is anything except pointless invective. While it would relieve some tension for me, it wouldn't really serve any long-term purpose. So, instead, I'll remove the source of tension. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpxelvR913qN.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 05:16:18PM -0800, Nunya wrote: > > I wasn't thinking of you, but let's take a quote of yours and see which > of these statements is most applicable: > > http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01512.html: > "(religious fanatics - the one group that seems > more incapable of mastering spelling and grammar than the speakers of > 'Leet)" > > Is this about a tenet of the Christian faith? No Correct. > Is it a statement about organized religion or mind control? No Semi-correct. It is a statement about a sub-set of organized religion (to wit, the fanatical sub-set). But, technically, correct. > Is It a statement about a Christian's belief? No Correct. > That only leaves one alternative. Since you're fond of URLs: http://www.nizkor.org/features/fallacies/straw-man.html (I believe that's even the website that keeps appearing in this thread) I never claimed that the four statements I listed covered all statements made. To do so would, in fact, be a ludicrous statement. The statement above is not *any* of the four statements in my previous email; it is a fifth statement (among even more than that, but I can't be bothered to make a precise count; I simply know that it is no less than six, because Ican think of at least one additional statement that has been made). Therefore, it does *not* leave only one alternative. It leaves at least two, one of them being the exact statement made (granted, the statement was made in a context of humor based on informal empirical observation, rather than a rigorous scientific study, but since you have cited no such study to refute it, and it's my damn mailbox, I stand by my right to summarize it as I see it). > Face it. You're practicing hate speech. You're not better than what > you hate. As someone else already said, Godwin. It may, or may not, be a true statement that I have authored or spoken a statement that would qualify; in fact, given the number of things I have said or typed over the years, many of them ill-advised, I probably HAVE do so in at least one incident at some point, or something that could reasonably be taken as such. However, the statement in question is not, and in asserting that it is, you're attempting to argue from a point of emotion rather than logic. For the record, however, if you consider saying that the lifestyle or beliefs of someone you don't agree with are sufficient to condemn them to an eternity of suffering as hate speech (and I generally do), I'm on the catching end of such a statement from every person who supports, directly or indirectly, any sect of Christianity which I am aware of, all of whom advocate divine justice, and most of which also advocate the continued denial of civil rights as well. It's certainly easy to *feel* like folks might just hate your beliefs, and often you for having them, when they're willing to go that far. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpW9weTJjL3f.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 04:21:40PM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 02:02:03PM -0600, Chad Walstrom wrote: > > And way out from Right Field... > > http://www.nizkor.org/features/fallacies/appeal-to-ridicule.html > > go back and count the # of "christians are stupid" statements > substitute any racial or ethnic group for christians > see how the statements sound in your ears then There are very important distinctions between the following statements: "Christians are stupid." "Tenets of the Christian faith offend me." "I consider a belief in to be foolish/silly/stupid/whatever." "Organized religion is meaningful only as a method of controlling people gullible enough to fall for it." [ ObDisclaimer: If you want to know which, if any, of the above are ] [ actually an opinion I hold, ask me in *private* email. ] One of these things is not like the others... one of these things is not the same. While the topicality is questionable (actually, it's not; it's pretty much completely off-topic), making assertions about behavior that happens to be a requirement for membership in a given group is not the same as making assertions about that group (for example, it applies equally to entities who are *not* part of that group, but exhibit the same behavior). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpKOgpUatMr9.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 01:22:07PM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 02:04:03PM -0700, Joel Baker wrote: > > > the fact that "the original guys said it's a daemon, explicitly not a > > > Christian demon" and here's you're saying "yes it is." :-) > > > > Er, no. I'm not. I'm saying that Christian demons are derived from Greek > > daemons; that isn't the same statement as them being the same thing. > > > It's a subtle point, granted. > > [Picking nits here] > > Picking "demon" names to describe "daemons" only seems to be a good > choice if they are closely related. Either it's a poorly descriptive > name or you *do* believe they are the same. It's a poorly descriptive name, because (if you look back at the origional post), there *are* no names for proper daemons. Demons are the next closest thing, and do have names. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgp1Y0Eq2gbfa.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 02:54:28PM -0500, Stephen Depooter wrote: > On Wed, 2003-12-17 at 12:26, Chad Walstrom wrote: > > On Wed, Dec 17, 2003 at 04:42:28PM +0100, Sven Luther wrote: > > > Well, just for the record, i personnally would prefer we don't use > > > demon name for keyword if possible. > > > > Forgive me for the gratuitous Harry Potter reference, but "fear of a > > name increases fear for the thing itself." ;-p > > > Of course an Ursula LeGuin reference would be that knowing an > object's/person's real name allows you to control the object/person. This is, in fact, shared to some degree in Rowling's work. Note how few people know Voldemort's real name - and how much power that seems to grant them, in dealing with him. Or maybe it's just that they remember him being an adolescent prat, like everyone else, and don't see him as all that different. :) Voldemort! Voldemort! Voldemort! See, nothing hap... > sigh... I really do need to read the rest of the Wizard of Earthsea > series. Yes, you do. Don't forget the latest compilation of short stories. It gives a huge amount of (very valuble) context to the history behind some major plot points in the main series. Like why Roke has the strictures it does about the gender of students, and what they're allowed to do. Oh, and it wraps up some loose ends, too. Like the Master Summoner. And no, those aren't spoilers. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpEcuEMWUlkM.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 10:21:24AM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 10:41:12AM -0700, Joel Baker wrote: > > > > "The Christian concept of a demon is a corruption (as it were) of the Greek > > concept of daemon" > > Basically, no arguments with what you said, except I find inconsistent > the fact that "the original guys said it's a daemon, explicitly not a > Christian demon" and here's you're saying "yes it is." :-) Er, no. I'm not. I'm saying that Christian demons are derived from Greek daemons; that isn't the same statement as them being the same thing. I also said that I consider it polite to respect the general BSD wish to *not* be associated with demons, as opposed to daemons. It's a subtle point, granted. It's also why I'm willing to grant as much leeway as I am to folks who feel uncomfortable about using demon names - as long as we have reasonable alternatives. Which I think we do, at this point. Debian Nuggen, Debian Nienna, Debian Nori... hey, I like that last one, if it gets me sushi... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgp3JaY584eqH.pgp Description: PGP signature
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 11:26:10AM -0600, Chad Walstrom wrote: > On Wed, Dec 17, 2003 at 04:42:28PM +0100, Sven Luther wrote: > > Well, just for the record, i personnally would prefer we don't use > > demon name for keyword if possible. > > Forgive me for the gratuitous Harry Potter reference, but "fear of a > name increases fear for the thing itself." ;-p > > IOW, lighten up, people. Otherwise, we'll be referring to Debian > GNU/That Which Shall Not Be Named... Hey, we already covered Lovecraftian names... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpFjnRw0Nhdt.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 03:13:03PM -0500, Nathan Hawkins wrote: > > If we're really worried about this, we can always use the names of the > Dwarves in the Hobbit. Most (all?) of those names are from Icelandic > sags, IIRC. So is Gandalf. All of them. I suppose they even have enough of the right letters to do the first-letter trick, at least once per. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpvV7fizhNiu.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 08:53:18AM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 09:31:17AM -0700, Joel Baker wrote: > > > > Somehow, I don't think Branden will mind being told his dislike of > > "parochial religious fundamentalists" is showing. I suspect he'd be proud > > of it. But you'll see for yourself, soon enough. > > I don't believe in magical beings. I *do* believe some humans > intentionally set out to hurt other humans. Branden's beliefs and > sneering disdain for some of his fellow humans is quite clear. (Note: > your response was measured and even). That, I'm afraid, is between you and him. I certainly disagree with him on some topics, and I certainly think there are many times when he could be more tactful if he wished to be, but I'm unwilling to say that he necessarily *should* be - though there are times (not really including right now, mostly) that I can say his choices have had consequences I had to deal with, and that I might wish he'd choose differently. :) > Please explain to me the relevance of these names without the specific > intent of discomforting people. The *intent* is clear. If you can > explain for, historical, literary, philosophical reasons, I will > enthusiastically support those names. If it's just because "let's piss > off the Christians", then I say, pick something else. The thought goes something like this: "Well, the mascot of ALL the BSD derivatives is a daemon, in various forms" (and, I will note, they are quite adament about it *not* being a demon, which is why the form is *always* a cartoony/stylized form) "A daemon is a greek concept for a being which bridges the mortal and the divine" (this is the semi-official reason for calling them daemons, in Unix) "Greek daemons do not appear to have individual names" "The Christian concept of a demon is a corruption (as it were) of the Greek concept of daemon" "There is an extensive catalog of Christian demon names to pick from" Note that while I don't (deeply) care about offending people with a strong religious belief, since I *personally* find most of those beliefs quite offensive in return, I *do* consider it polite to consider not using the demonic names entirely because the BSD folks have a long and avowed wish to *not* be associated with such, for purely practical reasons that affect them as much as (and probably more than) they affect us. > Actually I think you *should* pick those names. I'd love to see the > resulting carnage :-) Eh. My inbox would tell you it just isn't that interesting. Most of the religious screeds I get aren't all that coherent, or even entertaining forms of incoherent ranting. Half the time I have trouble telling that they're written in English (religious fanatics - the one group that seems more incapable of mastering spelling and grammar than the speakers of 'Leet).. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpamCXkvgqBB.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 08:17:03AM -0800, Nunya wrote: > On Wed, Dec 17, 2003 at 10:31:53AM -0500, Branden Robinson wrote: > > On Tue, Dec 16, 2003 at 05:23:39PM -0800, Nunya wrote: > > > On Tue, Dec 16, 2003 at 04:12:56PM -0800, Russ Allbery wrote: > > > > Because Christians are the people who primarily take offense at this > > > > sort > > > > of thing in the context that we were discussing in this portion of the > > > > thread. > > > > > > That's another opinion expressed as a generalization. I think you > > > better quit while you're ahead. > > > > It seemed inductively valid, but easy enough to disprove. Anyone care > > to provide a counter-example? Do any non-Christians wish to express > > personal discomfort or offense with the names I proposed? > > Muslims and Jews also believe in demons. > Witches believe in demons. > African nature-religionists also believe in demons. Are you one of these, and complaining? You fail to say. Most of the Wicca practitioners I know (and those that I've lived with and been involved with) don't particularly believe in demons, per se; they do believe in spirits, and some of those spirits are not what one would necessarily call benevolent. Satanists certainly believe in demons, but they believe in the Christian mythology of them, and thus, are in the same group (and are, of course, unlikely to disapprove, though they might advocate a specific favorite...) The context of "African nature-religionists" is too broad to discuss in detail, but most of the various forms of Animism do have the concept of malign spirits. How they deal with them, and their views of them in general, seem to vary widely. > Face it dude, you're hatred and unfairness towards one specific group of > people is shining through. I don't think this project is so enlightened > after all. Somehow, I don't think Branden will mind being told his dislike of "parochial religious fundamentalists" is showing. I suspect he'd be proud of it. But you'll see for yourself, soon enough. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpBJlCs5oiCn.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 11:10:24AM -0500, Branden Robinson wrote: > [I am not subscribed to debian-bsd.] > > On Mon, Dec 15, 2003 at 08:15:04AM -0700, Joel Baker wrote: > > Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather > > like the notion of using the Valar - they're fictional, and Tolkien's work > > isn't yet out from under copyright, but they *are* reasonably well-known > > (Okay, not as well as Pratchett, but better than Christian demonology), > > and if we're liable to get in trouble over using just the names, we should > > probably strongly reconsider our use of Toy Story character names for > > tagging distributions... > > > > Suppose it's time to dig out my reference books and see if I can come up > > with a suitable set of names out of that mythos. > > > > Besides, using Tolkien names is a long geek tradition. > > You seem to have already noted this, but I should re-emphasize that > since the Tolkien novels are still under copyright, then legally the > names from them are just as much risky choices as names from Pratchett > are. Indeed, noted. > From a practical standpoint, they may be worse. If Pratchett is aware > of Ogg Vorbis, then he presumably tolerates that usage. The Tolkien > estate is already known to have threatened people for using names (not > even proper names!) from the works of Tolkien, when they threatened TSR > with a lawsuit in the 1970s over the use of words like "ent", "hobbit" > and "balrog" in early editions of the _Dungeons and Dragons_ game. > Finally, the recent movie productions and consequent blitz of > commercialization has probably got the Tolkien estate in a mood to > squash anything that looks even vaguely like "unlicensed usage", even if > you have to squint and cock your head just right to see it. Hmmm. I know that there was a lot of nasty infighting around TSR and the early D&D games - going in *all* directions. Of course, that lawsuit would appear to have much more to do with the *concepts* of 'ent', 'hobbit', 'balrog', and the like, than the mere names. Since concepts are potentially copyrightable, and names aren't, it may not really be the same situation. As for the latter; if they were going to do it, I'd have expected to see it well before now. The first movie has been out for two years now, and the marketing blitz was going on well before that. And they don't appear to have gone after the huge number of folks using the names out there already. I suppose this one may simply have to be a point of disagreement, though, since I certainly can't claim to have researched everything the estate has done in court over the past 10 years or so. The other thing to keep in mind, about the origional lawsuit, is that my (hazy) recollection of it was that it involved a desire for licensing, and thus, royalties, for profiting from the concepts, and the fact that they formed an immediate association with a fantasy world. Apart from Nethack, Debian really isn't in the same field of endeavour, isn't making a profit, and isn't using the concepts, only the names. To me, that's enough to cast a significant doubt on whether their past actions are indicative of any desire to file lawsuits in our situation. > Remember, outside the Free Software community, copyright is used only as > a destructive weapon, not a tool for promoting cooperation and harmony. All too true. > I therefore think using names from Tolkien is imprudent, *even if* we're > on a good legal footing. Then we're back to "ancient names", of which the only ones even remotely associated are objected to by at least some of the principal participants. Or asphalt, which the Amish don't like, but then, they'll probably never see Debian in the first place... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgprsAVcmELY4.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 10:54:15AM -0500, Branden Robinson wrote: > [I am not subscribed to debian-bsd.] > > On Sun, Dec 14, 2003 at 06:00:21PM -0700, Joel Baker wrote: > > Even so, I'm amenable to anyone who can come up with names which are less > > loaded to random fundamentalists, if possible; of course, most of the > > sources on daemons say that they are, as a rule, without names in the > > origional Greek usage. > > So? The Greeks were heretical pagans and some of them were even > (gasp!) atheists. *snicker* My sister is a neo-Classisist (with, oddly enough, a degree in Classics - one of the few things less useful when job hunting than an English degree). I'm quite familiar with the variety of religious beliefs in the culture. I was mostly pointing out (after having looked) that it may not be possible to find *daemon* names, which would be slightly more apropos (to the geek in me, anyway) than demon names. Very slightly. But slightly. :) > It's impossible to not offend fundamentalists. Once you have done so > there is no reconciliation and no compromise. You either subordinate > yourself to their will or you are condemned as immoral. > > I honestly don't think it's worth the time to try and placate them. Nor do I. I mean, consider the fact that my personal email is [EMAIL PROTECTED], and I use it quite extensively (just check the list archives) - this is not exactly something used by someone big on placating fundies. On the flip side, I *don't* use that address, as a general rule, for things like: * Submitting resumes * Contracting work under the house consulting company * Things where I'm speaking as a Debian Developer * Work-related tasks In my perception, there is a difference between "placation" and "tact"; one of the primary points being the amount of effort that goes into it. Placating requires one to make changes that cost you something appreciable; tact is simply choice one of a number of otherwise equal options such that it has a reasonable chance of being less offensive to the target audience. We have DDs who are, clearly, offended - even if I consider that to be a rather silly thing, given my own beliefs. And if we didn't have another option, I'd probably say "tough noogies". But since we *have* had a couple of other options come up, which have yet to generate any statements of offense from anyone who's bothered to put it where I could read it, and those options work just as well in both a practical and a geeky sense, I have no problem with choosing one of them out of tact. As may have become clear, my favorite bid so far is for Tolkien names, since the only opinions on d-l that have been cogently argued, or backed up with citations, indicate that using the *names* isn't going to get us in trouble - and because they're already in quite widespread use in the same basic context we intend to use them for. And Tolkien's estate appears to have had many opportunities to raise objections, and hasn't ever done so, to the best of my knowlege. > > I think the point about the author's potential issue with them (whether or > > not it's legal, it has many of the same potential problems) may well be > > enough reason to avoid that one, sadly. Amusing as I find it. > > > > I suppose we could always pull names from Lovecraft; I think the names from > > his work have long since lost any protection they might have had. Debian > > Nylarthotep, anyone? > > > > Okay, maybe not. > > Heh, well, I'm pretty sure the names of Lovecraftian gods would be just > as objectionable to fundies; secondly, some of those names are too > damned hard to pronounce :); and third, I think Arkham House (publisher) > continues to *act* like the works of Lovecraft are under copyright, and > no one yet has had the balls to try an "unauthorized" edition on the > principle that they have passed into the public domain. It wasn't a terribly serious suggestion, you'll note. :) The third point is unfortunate, but mostly for reasons unrelated to this discussion (other than a proven propensity for ignoring the law in favor of lawsuits, which does make it a distinctly less prefferable candidate). > Still, at least a challenge to our usage of Lovecraftian names would be > rickety on two planks instead of just one, as in the case of Pratchett. True. I think Tolkien's work is still covered under the ever-expanding Disney extensions, but then, as I pointed out and d-l backed up, we're using Disney character names for an even more significant naming scheme - releases. If we're really worried about being sued over such, I'd be far more worried about Disney doing it... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpGilWod7pcx.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Tue, Dec 16, 2003 at 09:59:46AM +, Will Newton wrote:
> On Tuesday 16 Dec 2003 01:44, Joel Baker wrote:
>
> > Appropriate? As much as any of the Valar would be; he's certainly on the
> > list. But since we know of at least 4 active ports, one name isn't going to
> > be enough...
>
> I would hope whatever name chosen is pronounceable, spellable, reasonably
> short and preferably not accented (i.e. ASCII). Obviously the first two are
> subjective (there are at least two ways of pronouncing Debian).
Point #1: Since there are fairly well established pronounciation rules
for Tolkien's languages, and we know which language each name is
from, this shouldn't be a problem.
Point #2: Well, they're all spellable. Though it's easier if they're also
short, granted. See point #3.
Point #3: The only concrete, proposed name (so far) is 6 characters long.
Given that that's shorter than 'GNU/Linux' by 3 characters, I'd say it
should suffice...
Point #4: For at least the one proposed name ('Nienna'), it is, in fact,
representable (properly) in US/ASCII. Even the rest are all representable
in a clearly identifiable degenerate form (that is, no worse than many
Europeans already have to endure) in US/ASCII, and are completely
representable using ISO-8859-1 (or, of course, UTF-8, which is my personal
preference).
--
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/NetBSD(i386) porter : :' :
`. `'
`-
pgp0JHzCJoByI.pgp
Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Tue, Dec 16, 2003 at 12:20:00PM +0100, Mathieu Roy wrote: > Cameron Patrick <[EMAIL PROTECTED]> said: > > > On Tue, Dec 16, 2003 at 09:59:46AM +, Will Newton wrote: > > > > | (there are at least two ways of pronouncing Debian). > > > > ... only one of which is correct :-) > > Really? What makes a pronounciation incorrect? The pronounciation of > the project initiator, the context, etc... ? I'd have to say that the person who made up the term gets to decide how it should be pronounced. Shades of the Linux pronounciation flamewars... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpkY95A6QA6R.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 05:51:47PM -0800, Russ Allbery wrote: > > For a different, somewhat postmodern take on angels and demons, see the > roleplaying game _In Nomine_, published by Steve Jackson Games, which can > be played as pure good angels vs. evil demons, with complete moral > ambiguity, with demons as heroic rebels against the repression of heaven, > or anything else inbetween. Or read Stephen Brust's _To Reign in Hell_, which posits an alternative explanation of the creation of the world, the nature and causes of the conflict between the angels under Yahweh and those under Satan, and the origin of humankind. Or, in short, it posits what the 'real story' might be, one the assumption that the Bible was written only by one side, and is thus biased. It does make the assumption that "made in God's image" is a more specifically accurate description than the general view of it among Christians. It isn't precisely sympathetic to the fallen, but it ascribes the flaw of of overwhelming pride to both sides... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpxcagvFdZfj.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 10:40:11PM +, Roger Leigh wrote: > Joel Baker <[EMAIL PROTECTED]> writes: > > > On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote: > >> Branden's second proposal of using something from Pratchett did have a > >> nice ring to it, and then there's always the valar. > > > > Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather > > like the notion of using the Valar - they're fictional, and Tolkien's work > > isn't yet out from under copyright, but they *are* reasonably well-known > > (Okay, not as well as Pratchett, but better than Christian demonology), > > and if we're liable to get in trouble over using just the names, we should > > probably strongly reconsider our use of Toy Story character names for > > tagging distributions... > > > > Suppose it's time to dig out my reference books and see if I can come up > > with a suitable set of names out of that mythos. > > > > Besides, using Tolkien names is a long geek tradition. > > Would "Debian Aulë" be appropriate? > > "Of the fabric of Earth had Aulë thought, to whom Ilúvatar had given > skill and knowledge scare less than to Melkor; but the delight and > pride of Aulë is in the deed of making, and in the thing made, and > neither in posession nor in his own mastery; wherefore he gives and > hoards not, and is free from care, passing ever on to some new work." > > Ainulindalë, J. R. R. Tolkien, /The Silmarillion/. Appropriate? As much as any of the Valar would be; he's certainly on the list. But since we know of at least 4 active ports, one name isn't going to be enough... > There are also important Elves, such as Fëanor that might also qualify. See my followup, elsewhere in the thread. > However, there may well be copyright issues. "Slink", "Woody", > "Potato" and "Bo" etc. aren't exactly unique, but you would be hard > pushed to find another book with "Manwë", "Oromë", etc. in it. Given that we say, on the webpages, that they're Toy Story characters, that isn't much of a defense. We're equally in trouble, except that Disney is far more lawsuit-happy than Tolkien's estate has ever shown itself to be. That, and let's face it - given the number of machines in the world with hostnames based on LotR, if the *name* - all we're using - is really copyrightable (and the only opinion expressed so far on debian-legal has asserted that it doesn't appear to be, as opposed to a *character*), there are a whole lot of people who're going to be in trouble. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpwDqTSMwOX1.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 03:09:07PM -0500, Nathan Hawkins wrote: > On Mon, Dec 15, 2003 at 12:19:10PM -0700, Joel Baker wrote: > > > > Having cheated and grabbed an online resource for it from Google, the > > following possibilities show up (my apologies for the lack of accents; > > I can't easily input UTF-8 on this terminal): > > You mean you had to look this up? ;-) I said I was a geek; I didn't say I had a good memory. :) > > FreeBSD: > > No primary Vala names begin with 'F', but many alternate names do, as do > > a great many other names of honor in the Tolkien mythos > > There's no particular reason to stay with 'F'. We're already changing > the name beyond recognition. 'V' would be close enough, the phonetic > difference is small. True. I was mostly trying to stay along the lines of the origional proposal, but I doubt that too many folks will object very heavily to whatever the FreeBSD ports choose, since the primary mapping will be on a webpage somewhere (like, the BSD ports page, I'd expect, at least once the webpages are building again) anyway. > > NetBSD: > > Namo (Vala of destiny, prophecy, and the Halls of the Dead) > > Nessa (Valie of the woods) > > Nieliqui (daughter of Orome; see OpenBSD) > > Nienna (Valie of pity and lament; Gandalf/Mithrandir was one of her > > students) > > > > OpenBSD: > > Omar (Vala of music) > > Orome (Vala of the hunt, teacher of elves) > > Last I heard there was no longer an OpenBSD port. True; it was more for the sake of completeness. > > This is by no means a complete list; it includes none of the Maiar, nor any > > of the names of characters elevated from less powerful races. Personally, > > while I can't speak for the FreeBSD or OpenBSD folks, I'd cast a vote for > > Nienna, for the NetBSD port using kernel+libc; the name is one of the > > better known ones, and is a far cry from anything remotely 'evil'. > > > > It also leaves at least 3 other 'N' names available for the port currently > > known as Debian GNU/KNetBSD. > > This is a solution I can live with. Just to clarify something, am I > correct in understanding that we're only being asked to change the > official name of the system, not what uname says or config.guess says? Correct, at least as far as I understand it. Certainly those fields are a reflection of a technical statement roughly equivalent to "We use the NetBSD kernel", which is a factual statement that wouldn't infringe on any trademarks. I expect that they would expect them to be distinct, of course (though the topic has never directly come up), but we already have that (being a fundamental necessity). It has been mentioned in the threads I pointed them at, so I expect that if they care at all, we'll know about it by the end of the week. But the *only* request they made was in regards to the official naming of the port - not even the 'architecture' name. Though it might be vaguely entertaining to have 'nienna-i386' someday. But I'll leave that for a later debate. > Would TNF be ok with describing the system as "Debian GNU/Nienna, based > on the NetBSD(tm) kernel?" People will still need to know that the > system is based on NetBSD. Except that that wouldn't be the correct statement, yes, every indication is that it is fine to make factual statements such as this (the correct statement would be "Debian Nienna, based on the NetBSD kernel and libc, and a GNU userland"). This has the side effect of removing "GNU" from the name, just as "NetBSD" is removed from it (and presumably, someday "Linux" may well be removed; until then, of course, it would still be "Debian GNU/Linux"). Which isn't a direct goal in any sense, but does allow us to also avoid the same question of trademark issues with anyone else. > If we use different names for the libc vs glibc ports, we should > probably set the names for dpkg and apt to match. (i.e. netbsd-i386 -> > nienna-i386.) As I noted above, this may not be unreasonable, but I'd like some feedback from the general populance, the dpkg/apt maintainers, the ftpmasters, and the leadership about whether this should be expected to eventually subsume all port naming at some future point when it's reasonably convenient, before we start asking for that. Even if the answer is "no", we should spend some time figuring out just how far the name should extend, in order to not completely confuse everyone. (Disclaimer of ulterior motive: if it does subsume Linux naming, it would mean that we'd have -i386 as the arch, and 'i386' would just be a legacy pointer to it - something I'd like to see someday anyway :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpT2CxhzkvMN.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 08:15:04AM -0700, Joel Baker wrote: > On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote: > > > Of course, I don't really think we should merit religious nonsense with > > the honour of giving name to the products of Debian labour anyway... > > And if we do, let's choose one of the religions noone believes in... > > Branden's second proposal of using something from Pratchett did have a > > nice ring to it, and then there's always the valar. > > Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather > like the notion of using the Valar - they're fictional, and Tolkien's work > isn't yet out from under copyright, but they *are* reasonably well-known > (Okay, not as well as Pratchett, but better than Christian demonology), > and if we're liable to get in trouble over using just the names, we should > probably strongly reconsider our use of Toy Story character names for > tagging distributions... > > Suppose it's time to dig out my reference books and see if I can come up > with a suitable set of names out of that mythos. > > Besides, using Tolkien names is a long geek tradition. Having cheated and grabbed an online resource for it from Google, the following possibilities show up (my apologies for the lack of accents; I can't easily input UTF-8 on this terminal): FreeBSD: No primary Vala names begin with 'F', but many alternate names do, as do a great many other names of honor in the Tolkien mythos NetBSD: Namo (Vala of destiny, prophecy, and the Halls of the Dead) Nessa (Valie of the woods) Nieliqui (daughter of Orome; see OpenBSD) Nienna (Valie of pity and lament; Gandalf/Mithrandir was one of her students) OpenBSD: Omar (Vala of music) Orome (Vala of the hunt, teacher of elves) This is by no means a complete list; it includes none of the Maiar, nor any of the names of characters elevated from less powerful races. Personally, while I can't speak for the FreeBSD or OpenBSD folks, I'd cast a vote for Nienna, for the NetBSD port using kernel+libc; the name is one of the better known ones, and is a far cry from anything remotely 'evil'. It also leaves at least 3 other 'N' names available for the port currently known as Debian GNU/KNetBSD. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgp2Vo5kv9oX4.pgp Description: PGP signature
Re: experimental codename
On Mon, Dec 15, 2003 at 01:38:37PM +0100, Christoph Berg wrote: > Re: Neil McGovern in <[EMAIL PROTECTED]> > > I like it too :) > > Thanks :) > > > Prehaps it could be used as a codename for the new unstable when Sarge > > is released as stable? > > That's not the way it works; "Sid" is not "Sarge+1" but the never-to-be- > released development version. Think of it as "version infinity". "And Beyond!" Sorry, it had to be said. I'll go back in my hole now. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpm6og0gfCWW.pgp Description: PGP signature
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 08:57:45AM +0100, Marc Haber wrote: > On Sun, 14 Dec 2003 20:02:54 -0700, Joel Baker <[EMAIL PROTECTED]> > wrote: > >Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much > >more invasive than a dist-upgrade, every six months. This has largely to do > >with the fact that most upgrades are very smooth, and don't require, say, a > >complete reinstall. > > Oddly enough, nobody at me ex-orkplace (having about 20 FreeBSD boxes > in productive use) dared to touch any of the BSD boxes. We had > productive Servers running FreeBSD 2.x, and I believe that this hasn't > changed. This isn't my experience, or that of any of the other FreeBSD admins I (yes, know I do admin some FreeBSD boxes, for various reasons, even though n't my it ispreferred platform in any sense). > >In this regard, Debian actually resembles the *BSDs much more closely than > >most other Linux distributions (and that isn't a bad thing). > > NACK. Debian is much easier to upgrade since we keep older versions > around. Updating older FreeBSD base systems should work fine, but > compiling new ports is a nightmare if you can't step up one release at > a time. The only thing you can safely do is to build new systems and > slowly migrate. Debian is much better in that regard. Mmmm. I rarely have problems with such, but I suppose I also don't, as a rule, allow my systems to get terribly out of date. Though I have my doubts as to how 'safe' trying to upgrade from Debian 1.0 (which I don't recall the codename for, and I'm too lazy to go look it up) to Sarge would work well, even with release-by-release upgrades. Stipulated, it would be far more likely to work, because one can (at least, in theory) find the entirety of the old releases, rather than just the core. However, my point stands: most Linux releases - at least, those not based on Debian's core - *don't support upgrading over a major version change*. The BSDs do, and Debian does; thus, saying that Debian does so better puts it on the far side of the BSDs from, say, RedHat. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpCN0aWDtYW7.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
As an aside, the questions that were sent to Mr. Mewburn have been forwarded to the rest of TNF's Board, and scheduled for discussion on their next conference call (in a couple of days). His personal reaction to the thought of renaming the ports to 'codenames' was quite positive; in his (personal) opinion, it would resolve pretty much the entire question. We'll know in a few days whether the rest of the Board agrees with that view, but for now, I would take it as a positive sign that this direction is very likely to result in everyone (well, okay, as much of 'everyone' as we can manage) being happy. And now... On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote: > On Sun, Dec 14, 2003 at 08:47:28PM -0500, Jaldhar H. Vyas wrote: > > On Sun, 14 Dec 2003, Nathan Hawkins wrote: > > > > > Your proposal would change that. I oppose it, and I would oppose it just > > > the same if you wanted to call them Loki, Kali or Hitler. (To pick a few > > > at random.) Using names of evil, real or imagined, is not something > > > that would be helpful to Debian. That kind of publicity we don't need. > > > > Nathan, > > > > I understand what you are trying to say but just fyi, there is nothing > > remotely evil about the Goddess Kali in Hinduism. > > Loki isn't that evil either; he's just the god of mischief, hence more > of a prankster than anything else. Anyway, the comparision of mythical > creatures with the frontal figure of one of the biggest mass murders of > all time is beyond absurd... Debian Hitler, Debian Stalin, Debian Saddam (and, of course, Debian Bush, Debian Clinton, Debian Blair, Debian Kohl... what, you thought I was naming something other than political figures? :) > Of course, I don't really think we should merit religious nonsense with > the honour of giving name to the products of Debian labour anyway... > And if we do, let's choose one of the religions noone believes in... > Branden's second proposal of using something from Pratchett did have a > nice ring to it, and then there's always the valar. Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather like the notion of using the Valar - they're fictional, and Tolkien's work isn't yet out from under copyright, but they *are* reasonably well-known (Okay, not as well as Pratchett, but better than Christian demonology), and if we're liable to get in trouble over using just the names, we should probably strongly reconsider our use of Toy Story character names for tagging distributions... Suppose it's time to dig out my reference books and see if I can come up with a suitable set of names out of that mythos. Besides, using Tolkien names is a long geek tradition. > Hmm, come to think of it, money is what most people worship nowadays, so > maybe Debian GNU/Pesetas, Debian GNU/Zloty, and Debian GNU/Yen?! All > hail capitalism! This would be quite fitting right now, since most of > the western world is celebrating capitalism's supremacy next week (of > course, some celebrate it religiously for historical reasons, but they > seem to be a minority nowadays...) Amusing, but I don't think so. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpViLVUGLDbT.pgp Description: PGP signature
Re: Proposed change to debian release system
On Mon, Dec 15, 2003 at 10:49:20AM +0800, Isaac To wrote: > >>>>> "Henning" == Henning Makholm <[EMAIL PROTECTED]> writes: > > Henning> I stand corrected, apparently. (But I have yet to imagine which > Henning> arguments would be used against doing a release if we happen to > Henning> find testing in a freezeable state 6 months after sarge > Henning> releases). > > Perhaps because you'd be either forcing busy sys-admins to dist-upgrade > every 6 months, or forcing maintainers to keep security updates for two > stable versions? Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much more invasive than a dist-upgrade, every six months. This has largely to do with the fact that most upgrades are very smooth, and don't require, say, a complete reinstall. In this regard, Debian actually resembles the *BSDs much more closely than most other Linux distributions (and that isn't a bad thing). Oh, and as for security? They're already supporting 'oldstable' for, oh... about 6 months, or more. So tell me again why this is supposed to be a bad idea? (One that may take some practice to achieve, sure, and not one I expect us to hit next release, though I'd be happy to get it below the steadily expanding history of Debian - and the current RM's goals appear to be a strong step in that direction). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpPjs5928mzD.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 01:41:50AM +0100, Christoph Berg wrote: > Re: Branden Robinson in <[EMAIL PROTECTED]> > > > > Debian FreeBSD -> Debian Forneus (BSD) > > > > Debian NetBSD -> Debian Naberius (BSD) > > > > Debian OpenBSD -> Debian Orobos (BSD) > > > [...] > > > Your proposal would change that. I oppose it, and I would oppose it just > > > the same if you wanted to call them Loki, Kali or Hitler. (To pick a few > > > at random.) Using names of evil, real or imagined, is not something > > > that would be helpful to Debian. That kind of publicity we don't need. > > > > I doubt you'd have known they were names from Christian demonology if I > > hadn't told you. I didn't propse that we use better known names like > > "Lucifer" or "Satan". Even names like "Belial", "Asmodeus", and > > "Mephistopheles" are unfamiliar to uneducated Christians (which is most > > of them, at least in the U.S.). > > I consider myself educated, and I've never heard of any demons in school > where we had 13 years of religious (catholic) education. I can > definitely say that I'm not offended, and I doubt that anyone I know > would be. I've spent quite a while making an (extremely casual) study of such, and I suspect the only reason that I recognized them was because, quite frankly, I've spent a fairly large (if not intense) amount of time researching the topic as a whole. Even so, I'm amenable to anyone who can come up with names which are less loaded to random fundamentalists, if possible; of course, most of the sources on daemons say that they are, as a rule, without names in the origional Greek usage. > I like Branden's proposition very much. (Other than the proposed > Pratchett names.) I think the point about the author's potential issue with them (whether or not it's legal, it has many of the same potential problems) may well be enough reason to avoid that one, sadly. Amusing as I find it. I suppose we could always pull names from Lovecraft; I think the names from his work have long since lost any protection they might have had. Debian Nylarthotep, anyone? Okay, maybe not. > > In any event, for any name that doesn't raise trademark issues (and > > thus potentially jeopardize the entire project), I'd say > > the choice remains up to those who are actually doing the work -- and > > that would be the Debian *BSD porters. > > Indeed. One speaker of whom has issues with some of it, another of whom is... me. We'll sort it out at some point here. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpzyV8w7kH7K.pgp Description: PGP signature
Re: Complaint
On Mon, Dec 15, 2003 at 01:07:15AM +0100, Wouter Verhelst wrote: > On Sun, Dec 14, 2003 at 11:19:47AM -0700, Joel Baker wrote: > > On Sun, Dec 14, 2003 at 05:55:30PM +0100, Ingo Juergensmann wrote: > > > > > > Try to coordinate? When there would have been a try to cooperate by > > > him, I wouldn´t complain... but I do complain. > > > > Unless you are the local administrator of one of the build daemons, I > > doubt you'd have seen any of his attempts at coordination. > > He is, and hasn't seen any such attempt. Nor have I, being the DD > responsible for the buildd he's the local admin of. > > (Not that I agree with Ingo that there's reason for complaints -at > least, not yet- but that's a different matter entirely) Then the portion of the paragraph which you decided not to quote would apply. I suggest you go read it again. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpijJgqHQSXY.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Sun, Dec 14, 2003 at 08:21:30PM +0100, Roland Mas wrote: > > I'll suggest Offler (or Om), Foorgol (I don't like Fate) and, um, > some other god coming out of Terry Pratchett's Discworld novels, > preferably whose name starts with an N. > > Or something like that. One should never name the Lady. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpNSPX7goX4M.pgp Description: PGP signature
Re: Complaint
On Sun, Dec 14, 2003 at 05:55:30PM +0100, Ingo Juergensmann wrote: > On Sun, Dec 14, 2003 at 09:05:39AM -0700, Joel Baker wrote: > > > Remember, these machines are, behind the archives, perhaps the most > > implicity trusted machines in the entire project. Compromise the archives, > > and you can silently sprinkle trojans throughout any package on any port. > > Compromise a buildd, and you can silently sprinkle trojans throughout any > > newly compiled package on one port. > > Well, compromise the machine of some DDs and you have the same. Compromising > machines opens are serious security issue regardless for what the machine is > used. Yes. But debian-admin is not responsible for those machines; therefore, they are irrelevant to the discussion of "why hasn't debian-admin fixed ". That, and most developer machines tende to have a half dozen packages, at most, rather than 9000... > > On the other hand, blowing away a machine without losing the *valuble* data > > on it, then manually checking that data before it goes onto anything new, > > along with a complete reinstall, can be a pretty non-trivial task, and one > > that often requires console access - which, in itself, may be a non-trivial > > task for a number of these machines. > > You don´t need to tell me that. I´m doing my work mainly remotely, sometimes > with hundreds or thousands of km between the machine and me, including > kernel updates and remote installations. Then, if you'll pardon me, you appear to be being deliberately obtuse. > > Why should it be easier to get the machines Ryan works with regularly > > running again? Probably because he knows how to arrange any required > > access, where there might be data that needs to be copied/inspected, what > > that data might be, and what it SHOULD look like, along with probably > > having installed the machines in question at least once, and thus being > > familiar with any quirks they may have. Oh, and he can probably GET to > > them, which may well be physically impossible for him with others. > > No, I doubt that Ryan travelled to Germany to get the buildds up again. Probably not. Maybe he just happened to know where all the data was, pulled it off, and got ahold of the remote admin who happened to have the time to spare, right then. Or maybe it's an evil conspiracy. No, you're right, it must be; there's no other *possible* explanation... > > Thus, he probably has little choice, in some cases, but to depend on others > > to deal with some of hte work, and try to coordinate with them (some of > > Try to coordinate? When there would have been a try to cooperate by him, I > wouldn´t complain... but I do complain. Unless you are the local administrator of one of the build daemons, I doubt you'd have seen any of his attempts at coordination. Even if you are, it's quite possible that he simply hasn't gotton that far down the list yet. (Though I'd consider it a more significant failure, given that he presumably should be sending some form of "let me know when you can be available if we need it" emails). > > whom may be as much as 10 hours offset from him, which I can tell you > > from experience coordinating things between the US and the "Far East", > > is no small handicap). And, as has been pointed out to you, it has been > > *one* business day since the 12th, assuming that message went out at the > > beginning of the 12th and not the end. > > And as pointed out by me, It´s more than 1 business day. Okay. So it's 3. That's still ludicrously good to have ANYTHING like the amount of progress we've seen, given Debian's history. And, frankly, if you've ever had to try to recover a compromised remote box which had stuff on it that you couldn't just wipe out, I would expect you to have some understanding of how good it is to manage to get as many buildds done as quickly as has happened. In other words, the only two explanations I can see are either that you have no real concept of what you're discussing, or that you're being deliberately obtuse about the lot of it. Debian may have a lot of issues at times. I'd be one of the last to deny it. But given what a good job HAS been done, this time, continuing to complain while it's ongoing is likely to get you dumped into the bucket of "some people will complain if it takes 10 minutes, instead of 5, when it should take 5 days". You certainly haven't convinced me this complaint deserves to be put anywhere else, yet. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpW1sL5HHbJ9.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Sun, Dec 14, 2003 at 12:02:44PM -0500, Nathan Hawkins wrote: > On Sat, Dec 13, 2003 at 04:27:27PM -0500, Branden Robinson wrote: > > > > Well, no offense, but that's ugly as hell, and is going to square the > > > > amount of confusion people experience when trying to decode our OS > > > > names. > > > > > > Agreed, unfortunately - it is, and I suspect it may well. Suggestions for > > > better naming welcome, of course (or even a direction to go in). > > > > We might use names from Christian demonology (since the BSD mascot > > is the cute and devilish "daemon"), with the first letter shared by the > > demon's name and the corresponding BSD flavor. > > > > Thus: > > > > Debian FreeBSD -> Debian Forneus (BSD) > > Debian NetBSD -> Debian Naberius (BSD) > > Debian OpenBSD -> Debian Orobos (BSD) > > > > I got these names from the Wikipedia > http://en2.wikipedia.org/wiki/List_of_specific_demons_and_types_of_demons>. > > > > Moreover, none of these names are currently registered with the USPTO, > > so we'd be set in that department. > > I'm not opposed to anything else you've said. I do believe these > particular names are a bad idea, however. One of the reasons the BSD > mascot is considered "cute" is that it has no real connection with > demons, in name, or otherwise. Which to people of several religions are > _not_ cute. > > Your proposal would change that. I oppose it, and I would oppose it just > the same if you wanted to call them Loki, Kali or Hitler. (To pick a few > at random.) Using names of evil, real or imagined, is not something > that would be helpful to Debian. That kind of publicity we don't need. Feel free to propose alternatives from, say, the origional mythology which spawned the concept of daemons as beings which were not inherently good or evil, then. This is a serious invitation; I'll be looking through the various sources we have here for interesting ones. But so far, Branden's proposal is the only one with any concrete names that avoids questions of trademark. If folks are going to object, based on the names in question, that's fine, but they should be willing to offer alternatives. Of course, my personal email is one of the more obvious targets for fanatics or fundamentalists to send hate-mail to, and (assuming I don't just miss them in spam), I can think of about 2, maybe 3, such emails in the past year. So maybe I'm just not quite so worried about it as some folks. Even so, I don't (and I sort of doubt Brandon does) have any real attachment to the names proposed, if someone can come up with alternatives in the same basic concept, but which are less liable to offend anyone. Unfortunately, my experience with the topic tends to indicate that the same folks who care are very likely to consider there mere *concept* of a 'daemon' to be anathema, evil, foul, unclean, and all sorts of other descriptives. (And we all know that penguins are just flat-out unnatural; I mean, c'mon. A bird that *swims*?) ObHumor: Yes, that was a joke. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpg06YORSHiV.pgp Description: PGP signature
Re: Complaint
On Sun, Dec 14, 2003 at 03:58:21PM +0100, Ingo Juergensmann wrote: > > Looking at the graphs ti seems obvious that the way how to get buildds > running again is known for about 5 days now. > And 5 days are not enough time to inform other archs or give them access as > well? > Why should it be easier to get the buildds on mips(sel) and powerpc running > than to tell others how to do the same? Please give explanation. > AFAIK the source of buildd is the same for all archs. So, I can´t see any > difference in setting up the buildd for other archs than setting it up for > the above mentioned archs. > And when the source should be different now, why haven´t the other archs be > informed to build a new buildd from CVS? I would hazard a (fairly strong) guess that the source code involved in running the buildds has not changed appreciably. That isn't what has to be done, to restore a buildd to a trustable status. Remember, these machines are, behind the archives, perhaps the most implicity trusted machines in the entire project. Compromise the archives, and you can silently sprinkle trojans throughout any package on any port. Compromise a buildd, and you can silently sprinkle trojans throughout any newly compiled package on one port. Clearing out and restarting the buildd itself probably takes a nearly negligible amount of time - at least, that's been my experience, when experimenting with the entire buildd/wanna-build setup, for the NetBSD porting work, to figure out which things were actually required, and which were just nice. On the other hand, blowing away a machine without losing the *valuble* data on it, then manually checking that data before it goes onto anything new, along with a complete reinstall, can be a pretty non-trivial task, and one that often requires console access - which, in itself, may be a non-trivial task for a number of these machines. Why should it be easier to get the machines Ryan works with regularly running again? Probably because he knows how to arrange any required access, where there might be data that needs to be copied/inspected, what that data might be, and what it SHOULD look like, along with probably having installed the machines in question at least once, and thus being familiar with any quirks they may have. Oh, and he can probably GET to them, which may well be physically impossible for him with others. Thus, he probably has little choice, in some cases, but to depend on others to deal with some of hte work, and try to coordinate with them (some of whom may be as much as 10 hours offset from him, which I can tell you from experience coordinating things between the US and the "Far East", is no small handicap). And, as has been pointed out to you, it has been *one* business day since the 12th, assuming that message went out at the beginning of the 12th and not the end. Three weeks is a long time to go without a reply. Three days is not. Even outside of Debian, which I will cheerfully admit has (and often rail about having) some communication issues, three days just isn't a crisis. Particularly not when dealing with things that *paid professionals* can, at times, take a week or more doing, when being paid 8 hours a day. Let's save it for the really egregious times. So far, the entire recovery has been suprisingly *well* communicated, compared to a lot of points in Debian's history. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/TBD**BSD(i386) porter : :' : `. `' `- pgp3AkxaxDKsb.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
[ If you're being impatient about resolving this, please see the bottom ] [ of the email for an imporant bit of information... ] [ snip ] On Sat, Dec 13, 2003 at 04:27:27PM -0500, Branden Robinson wrote: > > On Fri, Dec 12, 2003 at 10:29:05AM -0700, Joel Baker wrote: > > > On Fri, Dec 12, 2003 at 11:54:09AM -0500, Branden Robinson wrote: > > > What makes a suitable name? Please be specific. If you don't know, I > > > think you should request this information from the NetBSD Foundation. > > > > As far as I can tell, anything which does not use the bare word 'NetBSD' > > as part of it's name, but I certainly can request clarification from Mr. > > Mewburn and The NetBSD Foundation about that. > > As I understand it, TNF's view of what dilutes a trademark is > considerably narrower than that of U.S. courts. It may be wise to > obtain a trademark license explicitly authorizing this usage. I have sent Mr. Mewburn an email requesting both a clarification of what The NetBSD Foundation would consider acceptable, in a name, and the rationale behind it, and questioning the possibly of looking into some form of trademark agreement, particularly one which would allow us to use something that might otherwise violate the trademark, but still be a sufficiently distinct name for TNF to be content. However, see below. > > I think that is largely a reflection of "nobody had any disagreement on > > the principle, or a better suggestion for the formal port name", combined > > with the fact that it triggered reviewing some of the haphazard naming > > conventions with a critical eye, and making sure that they were reasonable > > and rational. > > > > The thread is, indeed, split into two interleaved parts, and the > > non-technical part is almost empty. > > I don't have a problem with the technical issues being grappled with. > In fact, I'm glad they are. But the fact that the technical part got a > good amount of attention doesn't mean the non-technical aspect has been > adequately grappled with. And it was on non-technical grounds that Mr. > Newburn made his request -- "trademark dilution" is not a technical > concept, but a legal one. Indeed; I did not mean to imply that it should have been sufficient, only summarize what folks would find in the thread if they read it - which is to say, no objections to renaming, and no real discussion of trademark issues at all. (Notably, the fact that we had no real discussion is part of why I posted it to -devel, rather than just sending it to the project officials as a notification/request.) > BSD is also still a trademark, but I was unable to find any information > about its licensing, or even whether it is still actively defended. Hmmm. A good point, though one might reasonable wonder if 'NetBSD' would not, itself, infringe on this if it were being actively enforced. My impression is that it is not being actively enforced, but I make no claim to having done an exhaustive search, or spoken to the current trademark holders. > > > > 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1]. > > > > > > Well, no offense, but that's ugly as hell, and is going to square the > > > amount of confusion people experience when trying to decode our OS > > > names. > > > > Agreed, unfortunately - it is, and I suspect it may well. Suggestions for > > better naming welcome, of course (or even a direction to go in). > > We might use names from Christian demonology (since the BSD mascot > is the cute and devilish "daemon"), with the first letter shared by the > demon's name and the corresponding BSD flavor. > > Thus: > > Debian FreeBSD -> Debian Forneus (BSD) > Debian NetBSD -> Debian Naberius (BSD) > Debian OpenBSD -> Debian Orobos (BSD) > > I got these names from the Wikipedia http://en2.wikipedia.org/wiki/List_of_specific_demons_and_types_of_demons>. > > Moreover, none of these names are currently registered with the USPTO, > so we'd be set in that department. This may well be a solution to many problems in one go; it also happens to be one I like, but then, I've used that same reference for picking hostnames on the in-house consulting company's network. So I may be biased. More on this below. > > I believe (note: personal view) that the core is a perceived difference > > between the bare word 'NetBSD', which has, prior to this port, implied a > > kernel, libc, *and* userland of a specific form, and a variant of that > > name which is recognizeable, but distinctive enough to not cause confusion
Re: Changes in formal naming for NetBSD porting effort(s)
On Fri, Dec 12, 2003 at 07:24:29PM +0100, David Weinehall wrote: > I removed a lot of CC's, since this comment isn't relevant to the rest > of the discussion, really... > > On Thu, Dec 11, 2003 at 04:39:47PM -0700, Joel Baker wrote: > [snip] > > I explained that "Debian GNU/KNetBSD" was actually a separate effort, > > primarily by Robert Millan, to port Debian to a system consisting of > > NetBSD's kernel (thus, 'KNetBSD') and a ported GNU libc, while the other > > effort was aimed at a NetBSD kernel and native NetBSD libc. I did, however, > > say that I (at least) would be happy to try to find a name they found > > equally suitable, for the same reasons, rather than continue to use the > > current one. > > Are you saying that we're going to have both a Debian GNU/KNetBSD > distribution, which, since it uses glibc presumably would be able to > use the same binaries as the GNU/Linux architecture for _most_ packages > (please correct me if I'm wrong) _and_ a distribution based on NetBSD's > libc, which would required close to every damn binary to have separate > packages. Thus, given NetBSD's multiplatform support, almost doubling > the size of the Debian archives?! > > Madness lies that way. > > Yes, choice is good, but sometimes, just sometimes too much choice will > make you choke... Mostly, I'm saying that the debian-bsd ports list is much like the classical herd of cats, and the debate over which kernel, core libraries, and userland to use has gone on for... well, pretty much as long as the list has existed, as far as I can tell from the archives. The specific efforts talked about are those with "code on the ground", that is, those which actually have a package archive of some fashion, visible progress in getting things to a useable state, and enduring effort applied to them. The expectation, as far as I can tell, is that we'll be expected to resolve this in some sane and rational fashion before the ftpmasters let us anywhere near the archive. Right now, both NetBSD ports use the 'netbsd-i386' name, which works solely because nobody attempting to use this tries to pull from more than one of the APT archives. It also doesn't bar the possibility of ending up with a port which, for example, has a 'core' libc from NetBSD, but has a copy of GNU libc which some applications link against for specific things. Porting the GNU libc is a topic better addressed elsewhere (and has been, fairly recently). In other words: yes, it's a bit mad. We're trying fairly hard not to inflict that madness on anyone we don't have to, and expect that it will settle out at some point. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgpea8IHtzg1U.pgp Description: PGP signature
Re: Changes in formal naming for NetBSD porting effort(s)
[ Adding -legal to the Cc; it may become inappropriate for -devel, at ] [ some point, in which case folks should remove the -devel Cc. The -bsd ] [ Cc should probably remain no matter what, as this could potentially ] [ affect any of the BSD ports.] On Fri, Dec 12, 2003 at 11:54:09AM -0500, Branden Robinson wrote: > [I am not subscribed to debian-bsd.] > > On Thu, Dec 11, 2003 at 04:39:47PM -0700, Joel Baker wrote: > > On December 2nd, I was contacted by Luke Mewburn, on behalf of The NetBSD > > Foundation, asking about the "transition" to calling the NetBSD port > > "Debian GNU/KNetBSD", and expressing their appreciation for this change, > > as it reflects (in their opinion) a more accurate statement about what the > > system is, and avoids any potential dilution of the NetBSD trademark. > > Uh-huh. > > I'll go check, but is all of this discussion archived on debian-bsd? > > [minutes pass] > > I checked, and I don't see the *specific* grounds for the request > explicated anywhere. I guess it depends on precisely what you mean by specific grounds, in this case. If you mean 'specific accusations of dilution of trademark', then I don't believe there have been any. > > I did, however, say that I (at least) would be happy to try to find a > > name they found equally suitable, for the same reasons, rather than > > continue to use the current one. > > What makes a suitable name? Please be specific. If you don't know, I > think you should request this information from the NetBSD Foundation. As far as I can tell, anything which does not use the bare word 'NetBSD' as part of it's name, but I certainly can request clarification from Mr. Mewburn and The NetBSD Foundation about that. > > On December 3rd, Mr. Mewburn confirmed that The NetBSD Foundation would > > prefer to see the name changed, and I brought the issue up on the > > debian-bsd mailing list for discussion. > [...] > > Okay, yeah, I'm caught up on that part. The thread seemed to be mostly > concerned with technical issues, which is a completely legitimate > concern, but I think the discussion to date, if comprehensively > reflected on the -bsd list has almost completely neglected discussion of > the central thrust of the request you received. I think that is largely a reflection of "nobody had any disagreement on the principle, or a better suggestion for the formal port name", combined with the fact that it triggered reviewing some of the haphazard naming conventions with a critical eye, and making sure that they were reasonable and rational. The thread is, indeed, split into two interleaved parts, and the non-technical part is almost empty. > > 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1]. > > Well, no offense, but that's ugly as hell, and is going to square the > amount of confusion people experience when trying to decode our OS > names. Agreed, unfortunately - it is, and I suspect it may well. Suggestions for better naming welcome, of course (or even a direction to go in). > > If anyone objects, or wishes to see further requirements met, please let > > me know, and I'll do what I can to resolve the situation. > I don't understand the nature of your request. They're cool with > "Debian GNU/KLNetBSD" but not "Debian GNU/NetBSD"? Why, exactly? I believe (note: personal view) that the core is a perceived difference between the bare word 'NetBSD', which has, prior to this port, implied a kernel, libc, *and* userland of a specific form, and a variant of that name which is recognizeable, but distinctive enough to not cause confusion between their "product" and what we intend to produce. > And how does trademark enter into this, exactly? In both cases, the > mark is still being used. Yet they're cool with the former and not the > latter? As I understand the law[1], the mark is no more or less "used" > or "diluted" in either case. I do not have anything remotely like the background to discuss this meaningfully - frankly, I wasn't particularly aware that there might be any substantive issue with the assertion. See below for more. > Debian either needs a trademark license from the NetBSD Foundation for > use of the "NetBSD" mark, or it does not. If we do, then our hands are > tied and we might as well ask them to tell us what they want it called, > and what the terms of use are. Since the Debian Project doesn't legally > exist, this will probably have to go through SPI. If we don't need a > trademark license, then I don't understand why they've grounded
Changes in formal naming for NetBSD porting effort(s)
[ CCing Debian Project Leader and Secretary, to ensure that they have the ] [ chance to speak to the topic, even if they don't see it on the mailing ] [ lists. ] On December 2nd, I was contacted by Luke Mewburn, on behalf of The NetBSD Foundation, asking about the "transition" to calling the NetBSD port "Debian GNU/KNetBSD", and expressing their appreciation for this change, as it reflects (in their opinion) a more accurate statement about what the system is, and avoids any potential dilution of the NetBSD trademark. I explained that "Debian GNU/KNetBSD" was actually a separate effort, primarily by Robert Millan, to port Debian to a system consisting of NetBSD's kernel (thus, 'KNetBSD') and a ported GNU libc, while the other effort was aimed at a NetBSD kernel and native NetBSD libc. I did, however, say that I (at least) would be happy to try to find a name they found equally suitable, for the same reasons, rather than continue to use the current one. On December 3rd, Mr. Mewburn confirmed that The NetBSD Foundation would prefer to see the name changed, and I brought the issue up on the debian-bsd mailing list for discussion. After a good discussion that covered a variety of topics that went beyond the port name, but covered important related issues, I made the following proposal, which has received no objections for one week (Mr. Millan did make one request regarding the design of patches, which is not in conflict with the proposal): - For the porting effort formerly known as "Debian GNU/NetBSD" or "Debian GNU NetBSD/i386", the following four identifiers will be used: 1) 'uname -s' will be 'NetBSD' (this is unchanged). 2) 'uname -v' will have the name 'Debian' in it at an appropriate place, so that it is possible to determine a full set of system information solely from uname. (This is somewhat flexible due to possible changes in the NetBSD implementation of the concept of 'vendor'). 3) The GNU config triple will have '-netbsd-gnu' as it's third part. (This is unchanged - and don't blame me for a 4-part triplet. I didn't start it, merely maintained consistancy with -linux-gnu). 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1]. - [1] i386 target, Kernel+Libc of NetBSD, GNU userland, Debian distribution I'm not entirely certain what else, if anything, is required to make these changes (except updating the web pages, which will obviously have to wait until the normal method of doing so has been restored), since the origional decision on the port name was relatively informal. If anyone objects, or wishes to see further requirements met, please let me know, and I'll do what I can to resolve the situation. Please note that all of my discussions with The NetBSD Foundation, and it's representatives, have been both cordial and productive, to date, and that I feel their request is born largely of having seen an example which they preferred, rather than any antipathy towards the Debian project as a whole, or the various BSD porting efforts under it. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/KLNetBSD(i386) porter : :' : `. `' `- pgprBbq6Dy2mk.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Dec 03, 2003 at 07:17:57AM +1100, Brian May wrote: > On Tue, Dec 02, 2003 at 01:46:02PM +, Mark Howard wrote: > > On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote: > > > A release critical bug in one package could be caused by a non-release > > > critical bug in another package. > > > > How? > > If the bug is caused by a problem in another package then it should be > > reassigned (and more importantly fixed). The bug is still RC, even if it > > only affects dependent packages > > Wouter already answered the "The bug is still RC part". > > However, one point he didn't mention is that if the bug is reassigned in > to the other, people will continue to be affected by the bug against the > package, look up bug reports, not find anything, and resubmit a new bug > report. > > If you keep at least one grave bug report open against the broken > package, then it lets its users know that this is a known problem, and > they can be redirected towards the real bug report against the real > package. For those playing along at home, I suspect this would look a lot like: clone XX severity -1 important retitle -1 Causes massive failures on package foo assign -1 bar (The key trick is the cloning; it keeps the bugs tied in a way that makes the relationship clear, keeps the discussion history available, and still allows the bugs to be seen accurately, in the places they should be, and at severities that are accurate). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpiVYa89Vfaf.pgp Description: PGP signature
Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote: > On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote: > > I'm in two minds whether or not to ask this, but I've been wondering > > about the naming scheme for linux packages - kernel-*. Why not > > linux-kernel-* or linux-* ? If alternative kernels in debian become > > more popular, is there a potential for confusion in the future? > > Surely these won't all show up in the same Packages file...if you're > running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the > Linux and Hurd kernels even be in the list? *-kernel-image-* is a binary image, and should, of course, have an appropriate architecture (or tagging, if we ever move to that). However, *-kernel-source-*, *-kernel-headers-*, and *-kernel-doc-* (off the top of my head) are all Arch: all, or at least potentially so, since they're non-binary data that could (arguably) be useful across the board (even on other kernels, since cross-compiling a kernel is often a supported concept, even if userland is far nastier as a rule). Certainly 'netbsd-kernel-source-*' will be Arch: all, even if the package one uses to build them (the equivalent of kernel-package, also a candidate for renaming if it comes to pass) is arch-specific. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpabHx6Zuzrl.pgp Description: PGP signature
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Thu, Oct 16, 2003 at 08:48:03PM -0300, Otavio Salvador wrote: > Peter Makholm <[EMAIL PROTECTED]> writes: > > And you still havn't told us what you didn't understand when James > > wrote: 'If depending on emacs bothers you, make it a suggests.' They > > *don't* have to have emacs installed! > > The way of James contact the developpers. He should be more cordial > and try explain that things not only reject a package and make > conditions to accept this. > > I understand the cause and how James solve the problem but the thread > was more to try take attention on the way of things occour in > Debian. We should try be more cordial each other. I'm hardly the sort likely to be first in line to defend Mr. Troup's policies about various things - a causal search of the list archives should make that abundantly clear - but I fail to see how he wasn't being quite civil, polite, and reasonable about it. For that matter, he and I have differed over things in some of my packages; however, he does, in my experience, actually try to explain what the issue is, and offer alternatives if there appear to be any. Listing specific things that must be done before the package will be accepted can, in some cases, sound much less polite - and more like an ultimatum. Listing the reasons for the rejection, and a brief explanation of why they're relevant, should really suffice to give you the opportunity to say "I don't agree, here's why:" in an equally polite manner. He's been known to change his mind, when presented with suitable evidence or persuasive argument, but his job as ftpmaster is, in large part, to do exactly what he did - reject package uploads that appear to have significant problems, which can include poor packaging decisions. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpZVMT5Rjc1G.pgp Description: PGP signature
Re: [debian-devel] Re: which policy checker?
On Tue, Oct 14, 2003 at 06:31:01PM -0700, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> you write: > >Try reading upgrading-checklist.txt. > > Where do I get a copy of this document? A summery of what to check > for when updating a package would be very useful. (I've just agreed > to take over a few more packages, two which havn't been updated since > woody.) Install debian-policy from unstable (conveniently possible even on current-stable, at least, and probably just about anything...) and check out /usr/share/doc/debian-policy/upgrading-checklist.txt.gz; all sorts of spiffy goodness. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpbvynS5VIxm.pgp Description: PGP signature
Re: recent spam to this list
On Tue, Oct 14, 2003 at 04:40:15PM -0500, Manoj Srivastava wrote: > On Tue, 14 Oct 2003 10:21:23 -0500, John Hasler <[EMAIL PROTECTED]> said: > > > I understand all that, which is why I found statements such as those > > in > >> [EMAIL PROTECTED]> confusing. The fact is I can add SPF > > records for any IP numbers I want to domains I control. Thus if I > > want to be able to send mail from the library or the university > > claiming to be from my domain I just need to add the appropriate > > records to my domain. The library and university have nothing to > > say in the matter. > > > Consider this use case: I travel a lot, and stay in hotels > with network connections. Unfortunately, these nigtly billed domains > have very poor mail gateways; I've been burned before. I now connect > directly and deliver mail from the MTA on my laptop. > > I do not know, a priori, what the IP address is likely to be, > and getting DNS changed for datasync.com would take days, not hours, > by which time I would no longer be at the IP. > > I do not have co-located servers; and my normal machine may > not be accessible from outside to tunnel to. Just like the postcards > I mail from the Hotel, the return address on my email points to a > valid mbox. > > Would there be any way to implement tihs use case with > everyone using SPF, and telling spamassassin to deep six failures? > > manoj Given that set of constraints? No. However, as I said before, the same arguments have been used to defend open relays - and they are equally valid, or invalid, depending on whether you consider the massive abuse versus the few cases in which it is useful. Both are, in fact, fairly readily solved by the same basic method (unless port 25 is blocked outbound, which stops all chances of being able to send email out directly, as well) - relay to a smarthost that accepts SMTP AUTH. If your ISP won't do it, and your home box can't do it, perhaps it's time to consider a business investment in maintaining a mailbox with an ISP who does allow it - there are plenty to choose from. In other words: I do not accept the argument that you should be able to shift costs from you (the person wanting to do what is a fairly uncommon and non-standard configuration) to me (the person who has to go through a lot of spam to allow you to do so). In my world, my time is worth more than your money - and it's my world that decides whether *I* use SPF, domain verification, block dial-up addresses (which will also shoot you in the foot), or filter all mail from your know addresses. Or none of the above. If, and only if, much of the rest of the world makes the same value judgement, then you might have issues sending email to them - because they have said, on a policy level, that getting your email (through that configuration) is *not as important* to them as *not* getting the spam. So far, that policy seems to be a fairly popular one, if we go by the fairly directly analagous situation of "who uses Open Relay lists as part of their filtering" - though *most* of them that I've seen just use it as an SA rule, rather than rejecting it outright. A $19.95/mo dialup account hasn't bought you all that much of the Internet for some years now; this is simply one more door that appears likely to be closed. If you don't like that, there are perfectly workable ways to buy the ability to do what you do want, for a very reasonable price, some of which are unlikely to ever be blocked by any local ISP you may connect through. TANSTAAFL; the Commons has long since been paved over. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp3PMrpEwHAb.pgp Description: PGP signature
Re: recent spam to this list
On Mon, Oct 13, 2003 at 06:51:01PM -0500, John Hasler wrote: > Joel Baker writes: > > I'm going to gloss over the utter mistake of your first statement > > I am on a dialup with a "dynamic" IP number: I am allowed to borrow a > number from my ISP at need. There is no IP number over which I have any > administrative control. Thus I have no IP in that I would be unable to > implement any system that required control of "my" IP number. This is not a problem with Dynamic DNS updates. Many places do hosting of DNS domains (only; no web or mail, etc) for absurdly cheap rates ($5/mo in some cases), and allow either DDNS or an automateable webpage to do updates with. > > 4) Normal end-users relaying through their home ISP, organization, or > > business (The Road Warrior) > > My ISP does not permit this. It is the only one available to me. Your ISP probably doesn't permit outbound connections from dialups to port 25 (gee, can't imagine why that might be the case...); it is amazingly rare to find an ISP that actively blocks VPN, IPSEC, *and* SSH traffic, and is still in business, however. Both for bypassing ISP filters, and for security reasons, relaying this way is fairly standard for the Road Warrior sorts (in no small part because it also protects the bare passwords that are still mostly used in POP3/IMAP servers in most situations; yes, I know about IMAP over SSL, but that doesn't do well when you need to coordinate remote salesdroids with local management, and they all use Outlook's calendar stuff to handle it). > > Classes 3 appears to be your situation; both this, and class 4, are > > removed entirely from the question of SPF/RMX/etc, because they relay > > through their ISP's smarthost (and thus, that smarthost is what will be > > checked for being allowed to send to a remote site). > > I cannot relay through my ISP's smarthost from outside his system. Not at all uncommon, though it might be worth trying to convince them to allow you to do *authenticated* relay from outside. Oddly enough, preventing random IPs from relaying is because... spam comes through. > > You smarthost your email to a server configured to handle turkey.com > > email, which is presumably listed in the policy, and *it* sends the email > > on to the remote site (which then sees it coming from that server, not > > you, and will accept it as coming from an approved server). > > That is how I thought SPF worked. This would be fine with me. However, > statements made earlier in this thread seemed to me to imply that the > cooperation of the administrators of domains from which mail would be > originating would be required. This would be useless to me: I doubt I > could get the cooperation of even my ISP, let alone some hospital or > library. *Mail* has an return path that includes domain names (normally). SMTP *sessions* have a source IP. All of the protocols I saw obviously listed on the ASRG page (including at least RMX, SPF, and Vixie's proposal) use the *claimed* domain (which can be anything), and the *actual* source IP (which cannot be forged without having access to the routing hardware in between the machines, at which point you can do damned near anything you want), to decide whether it's kosher. The library's domain is irrelevant, in this case, since you're not claiming a return address in the library's domain. As a real world counterpart: if I sign up for a thousand 'free catalogs', using the address of my next door neighbor and arch nemesis Fred, he will, in fact, probably be deluged under a mountain of advertisements for lawn aeration shoes and crystal healing methods. I can do this from thousands of miles away, in fact; maybe Fred moved to Texas, and this is my long delayed revenge. Now, Fred can ask the post office to stop sending them through (and in fact, they'll probably notice it in the first place) - ISPs do similar things in a lot of cases, today, for their customers. The problem is that rather than being a rare incident of juvenile humor or mild spite, it's a business with a fairly serious amount of money involved. Now, imagine if the folks giving out catalogs had access to a "no mail" database in which Fred could (if he wanted to register at all), say that any attempt to request catalogs that didn't come postmarked by his local post office should be ignored. I can still mailbomb George, who hasn't signed up on the list; there may be ways to send my mail from Fred's local post office (note that the analogy stretches a bit thin on this point), but I can no longer send email from Nome, Alaska claiming to be Fred in Texas wanting catalogs. There are established ways of dealing with folks who are on the road all the time and legitimately might be anywhere in
Re: recent spam to this list
On Mon, Oct 13, 2003 at 04:26:35PM -0500, John Hasler wrote: > Joel Baker writes: > > I'm sorry, but your individual desire to be able to send mail from > > anywhere on the planet, claiming to be anyone on the planet... > > What makes you think I want to claim to be "anyone on the planet"? > I have a valid domain and I want replies and bounces to go to it. If you're doing what these proposals are meant to block - that is, sending email from a random IP on the internet without cryptographic authentication data at the protocol level - then you can claim to be "[EMAIL PROTECTED]" just as easily as you can claim to be your legitimate email. Opening up the ability to do it for legitimate uses opens up the ability to use it for illegitimate ones, as well - and this has a proven (and high) cost. > > If adding .1 to your SA score for lacking a repudiation protocol, and 3 > > (or 5, or whatever) for claiming to be from a domain that denies that it > > origionates mail to the rest of the world from your IP... > > I have no IP. Outgoing mail from home goes via my ISP's smarthost. > Incoming mail goes to his POP server. I'm going to gloss over the utter mistake of your first statement (unless you happen to connect to your mail server over SNA, IPX, or some stranger option), and point out that the second statement automatically removes you - entirely - from the issue at hand. If you're sending your email to your ISP's smarthost, then *it*, not *you*, are what talks to the remote mailserver - and, as such, it's IP (not yours) is what will be checked. So, unless your ISP pulls a boneheaded misconfiguration, either there will be no published policy (that is, anyone can send), or the policy will list that smarthost as authorized. > > If lacking a domain-authorized relay point comes to eventually have the > > same statistics, you'd better bet that you'll have the same sorts of > > penalties in spamfilters. > > What do you mean by "a domain-authorized relay point"? It was my > understanding that the idea behind SPF was that I would list in the DNS for > my domain the IPs that were authorized to send mail claiming to be from my > domain. That would be fine with me, but I evidently misunderstood. Understand that there are five normal situations that cover pretty much all non-pathological sources of email on the Internet today: 1) Private mailserver run by a business, co-op, or highly technical single user (enterprise servers). 2) ISP mailservers (just what they sound like) 3) Normal end-users relaying through their connection ISP (Joe Dialup) 4) Normal end-users relaying through their home ISP, organization, or business (The Road Warrior) 5) Normal end-users delivering directly. Class #1 is generally a "business" account of some sort; it costs more than $19.95/mo, and is expected to be able to send and receive email directly, as a rule. Also, as a rule, they can control their own DNS (either by running a server, or by having update control from whomever they pay to do hosting for their domain). Class #2 is fairly obvious, though the line between "normal business" and "ISP" can blur somewhat if your business has an IT department serving tens of thousands of users. They almost certain run their own DNS servers, and can afford someone compentant to run them. These two classes have a strong business case for needing to send their own email rather than let an ISP handle it for them; they frequently have access through more than one ISP, and can easily (and legitimately) generate hundreds of thousands of emails an hour, which would put an excessive load on the mailservers of an ISP for one customer, if so. Classes 3 appears to be your situation; both this, and class 4, are removed entirely from the question of SPF/RMX/etc, because they relay through their ISP's smarthost (and thus, that smarthost is what will be checked for being allowed to send to a remote site). Class 5 are the people who regularly used to use open relays (instead of smarthosting), and who now want to be able to send emails directly (without having to smarthost). They are the only ones such proposals hamper in any significant way. Your understand above is correct - note that you would list your *ISP's* mailservers (probably the same smarthost you send to as their customer, but possibly others; they would be able to tell you which ones) for your domain, since that's where mail is expected to come from. In fact, if you have something spiffy like Dynamic DNS updates arranged, you can even send directly from your current IP, by updating the DNS to say "This dynamic IP I got is authorized to send email for my domain". What you *won't* be able to do, if the proposals are widely adopted, is to send email claiming to be from &qu
Re: recent spam to this list
On Mon, Oct 13, 2003 at 08:06:33PM +0200, Julian Mehnle wrote: > John Hasler wrote: > > Julian Mehnle writes: > > > No, but this again is one of these broken "e-mail vs. real world" > > > analogies. You can't receive mail through such a letter box, but a > > > sender address is inherently meant to be a valid address through which > > > you can be contacted (among other criteria). > > > > I can no more be contacted via the machine in that library than I can via > > the letterbox. I go in there, spend five minutes sending an email and > > leave, expecting any replies or bounces to go to my real address. If my > > message is bounced to that box or a reply sent there it will vanish > > without a trace. > > Then it's up to the library to decide whether to offer this feature > (envelope-from forgery, or call it envelope-from pretendery) or protect > its domain from unauthorized use in envelope-froms. Of course the latter > option implies restrictions for users like you, but the library is not at > all required to implement these restrictions for its domain. > > I still don't understant why so many people object against the cited > proposals... The implementation on the sending side (i.e. the DNS > configuration) is entirely optional. Probably because systems which expect it and don't see it will do something such as give the message a positive SpamAssassin score. Of course, if you're going to do something that happens to look like what a lot of spammers do, you should probably expect that, just like it's not wise (anymore) to put a lot of !s in your subject, or to use a known open relay, even if you have absolute permission to use it for legitimate email... Really, this just isn't that difficult a concept, even if it doesn't map directly to real world mail. Your identity, as given in various places, is multi-part; both a user part, *and* a domain part. The owners of the domain part are free to set any policy they wish (including "we don't care"), regarding the behavior of people who wish to claim association with them (perhaps the cloest analogy would be fufilling any requirements for using, say, the official Debian name). In fact, the debian.org domain is a very good example. The policies say that you shouldn't use it for a variety of purposes; they could (though I don't think they *should*) also say "due to problems with forged email claiming to be from Debian, all Debian-official email must relay through the following servers: ". For Debian, which has little interest in running relay servers, highly technical users, and a relatively small problem with spam claiming to be from the domain, in general, it isn't worth the annoyance to the users (IMO). For a University, who are very liability-shy, who mostly have users using a single system, and who already run significant outbound relays for most of their users... it may be much more of a win. It's just (another) tool for enforcing policy, like everything in layers 1-7; it can help make certain policies practical, but it cannot decide when or where to make those policies the case. If you don't like the policy someone implements with it, you can complain to them - maybe they'll listen, maybe not. For a lot of us who've been dealing with the load on mailservers for years, I'm sorry, but your individual desire to be able to send mail from anywhere on the planet, claiming to be anyone on the planet, does not (in my policy decisions) outweight my desire to get fewer spams every day. If adding .1 to your SA score for lacking a repudiation protocol, and 3 (or 5, or whatever) for claiming to be from a domain that denies that it origionates mail to the rest of the world from your IP, is enough to help me sort through my mailbox - so be it. If it isn't, I won't use it, and you have nothing to worry about. However, arguments about 'it will make my life harder' apply just as well to things like open relays, and they are the heart of a large number of anti-spam lists, since there is a very high correlation between having it open, and origionating large amounts of spam. Nearly 100%, in fact. If lacking a domain-authorized relay point comes to eventually have the same statistics, you'd better bet that you'll have the same sorts of penalties in spamfilters. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpMt0YodGu7F.pgp Description: PGP signature
Re: specifying which IP addresses can send mail for a domain
On Fri, Oct 10, 2003 at 03:09:54PM +1000, Russell Coker wrote: > Joel, can you please provide information on the experimental method for > specifying which IP addresses may be used to send mail from a particular > domain? The one I personally like best, at the moment, is Paul Vixie's proposal (draft-vixie-repudiating-mail-from); however, as has been pointed out, most of the active, or remotely reasonable, proposals have come under the aegis of the IETF ASRG working group, and probably belong there. None of them currently have (nor are they likely to have in the immediate future) enough weight to be terribly useful; the main benefit of the ASRG process is that we will (almost certainly) end up with one protocol blessed with full RFC status, which is a fairly major advantage in terms of convincing mail software writers and DNS maintainers to actually implement it in a widespread enough fashion that it will have noticeable impact. I favor Vixie's proposal primarily because it's simple, elegant, and it requires neither new DNS RR types, nor excessive handling of things which are documented as poor DNS practice, such as widecards. Anything requiring DNS upgrades will take at least five years, if not longer, before it is deployed in sufficient density to be meaningful - many folks still run BIND 4 based resolvers. And the merits of avoiding the use of poor DNS practices should be, well, obvious. Using one special hostname that is unlikely to be used for anything else on an operational network isn't such a high price, by comparison, and it can be implemented entirely at the application level using well-established query pathways (even resolvers that break things like wildcards are unlikely to break MX+priority information). However, as I said, I'm betting that none of them will gain much steam until the ASRG renders a decision. So we'll just have to see what comes out of it. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpRfisd2ervc.pgp Description: PGP signature
Re: testing packages at build
On Thu, Oct 09, 2003 at 02:15:03PM +0200, Bill Allombert wrote: > My first goal is to persuade developers that running tests is > worthwhile. For the implentation I have mainly 3 questions: > > 1) Do porters and autobuilders admins want to be able to skip the tests ? As a porter: No. Dear god, no. I regularly submit bugs asking folks to turn ON the testing already present in the package, so that we can catch problems with it more readily. As an admin of a box that isn't a buildd, but looks much like one: it spends far more time dealing with build environment setup/teardown, most of the time, than it ever does running tests. Most testsuites are small, fast, and add maybe a tenth again, if that, to the build time (GCC is probably the most notable exception, but I still make sure it always runs it's checks when doing a formal build - it's worth it). > 2) Do we need a more featureful test machinery that just running test > in the debian/rules build ? Having a 'test' target would be handy, if for no other reason than being clear on exactly where and when testing should take place (and, really, being able to NOT test if one is, for some reason, averse to it - say, doing multiple rebuilds that aren't intended for packaging/release. > 3) Do we want to allow for autorecovery ? If gcc -O2 leads to a broken > binary, why not set up debian/rules to automatically retry with gcc > -O0 ? On this, I have to vote 'no'. If switching from -O2 to -O0 fixes a problem, that is almost indisputable a bug (usually in the toolchain), and there should be human intervention if for no other reason than ensuring the toolchain packages get the bug filed against them so that we can improve them. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpyyfo3JXWll.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Wed, Oct 08, 2003 at 01:54:13PM +0200, Björn Stenberg wrote: > Does anyone have a policy-compliant version comparator in Perl that I can > reuse? I'm slightly confused as to the exact meaning of 5.6.11. This means > some version compares (such as xaw3dg's 1.5+E-1 vs 1.5-25) currently return > wrong result in my script. Presumably you mean other than `dpkg --compare-versions`? -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp1ppn8XTIOH.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Oct 06, 2003 at 05:54:09PM -0500, Steve Langasek wrote: > On Mon, Oct 06, 2003 at 10:32:20PM +0200, martin f krafft wrote: > > also sprach Daniel Jacobowitz <[EMAIL PROTECTED]> [2003.10.06.2220 +0200]: > > > I beg your pardon? Why do you believe that the _stable > > > distribution security FAQ_ is relevant to this argument? > > > Because it is the only thing I could find that reflects Debian's > > take on security fixes: feature backports are to be avoided. > > That's because it's the position of the *Security Team*, and is > certainly not binding on other developers who are making changes to > packages in *unstable*. It still encapsulates an excellent way of avoiding messes like this, and maintains the principle of least suprise for users. Finding out that your Debian kernel source is mostly vanilla, with security fixes, is one thing. Finding that it's vanilla, plus security fixes, plus whichever kitchen sinks (sorry, but IPSec can't be anything BUT a kitchen sink patch) the maintainer likes, but not ones s/he doesn't like, is quite another. However, Herbert clearly doesn't find this a convincing line of argument on it's own merits, so it's probably time to just kill this off. If someone cares enough to do it this way, package it and upload it (and if ftpmaster denies it, then we have something to talk about). If nobody cares enough, then - well, nobody cares enough. Makes it pretty simple. I'd still *rather* have it done more sanely, and intend to do so for the NetBSD kernel sources, but short of the Technical Committee (who might quite possibly decide it's fine), there doesn't seem to be much to be done at this point except correct the situation by way of providing a better answer. (I am, however, reminded that it's probably a good idea to go codify some things in the proposed mini-policy for NetBSD kernels...) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp0GlaaATxTZ.pgp Description: PGP signature
Re: Looking for a co-maintainer for adduser
On Mon, Oct 06, 2003 at 03:14:24PM -0500, Gunnar Wolf wrote: > John Belmonte dijo [Sun, Oct 05, 2003 at 10:20:59AM -0400]: > > Lua is a modern high-level language. Its 15K stand-alone interpreter > > depends on only two libraries which total less than 200K. The > > functionality of its standard libraries are limited by ANSI C, but there > > are are third party libraries for talking to the OS, such as a POSIX > > library. > > > > Someone less averse to prefix notation than I might make the same > > argument about scsh. It's larger and has more dependencies, but on the > > other hand has full library support for system programming. > > > > Why not consider tiny languages? > > Because of how powerful is Perl? Because of the amount of things that > depend on Perl that currently exist and would be a waste of time to > rewrite? Because Perl might be the best tool for many cases? There are > many possible answers... Actually, TTBOMK, it's more or less a historic choice. Which is to say, at the time the decision was made, Perl was one of the only tools which COULD do all of the things needed for setting up a base system, in a single language which could (reasonably) easily express this (bash shell does not easily express it, even if it *can* express it, generally). If the decision were being made today, we might see arguments over Perl, Lua, Python, and probably others - valid ones, in fact. However, now isn't then, and once the decision has been made, it becomes a much harder thing to move away from it (for good reason) - since it involves rewriting everything, with the attendant bugs, problems, unrest, and insanity that comes with. (I like Perl; it's my slap-it-together language of choice. Conversely, I also regularly work on a system where core pieces are written in python, because that's the religion of the person who set it up. If you want to see my actual opinion, go read the 'Perl vs Python' bit in Unix Power Tools, 3rd edition - written by the same person, and reviewed in-house to ensure a fair hearing to Perl :) Actually, I'd almost prefer Python for doing Debian base work - not because Perl is bad at it, per se, but because so many people have bad Perl habits, and this propagates into the scripts. Python makes it (slightly) harder to write truly gross code, and since Debian maintainer scripts really shouldn't be doing the stupid tricks that prevents you from doing *anyway*, I'd be willing to take that loss. But it just isn't worth it to try to convert everything (at least, not until Perl 6 forces us to consider rewriting it all, anyway...) Though getting Python to have an easier Build-Depend chain would be nice for porters, if we ever do support it as an option for maintainer scripts. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgppklYb4P64n.pgp Description: PGP signature
Re: your mail
On Mon, Oct 06, 2003 at 02:28:25PM +0200, [EMAIL PROTECTED] wrote: > Hello, > > I'm working with Linux pthreads, from the glibc 2.2.3. ^^ That's your explanation. Or, more precisely: this is a known issue with Linux Threads, and one of the main reasons the new threading setup is so much nicer (little things like, oh, actually following the POSIX spec on such things). > The problem occurs when I try to shut down my aplication controlled >by receiving signal SIGTERM. The root thread receives the signal and >makes a pthread_cancel() to all threads and waits with pthread_join() for >cancellation. But a thread waiting on pthread_cond_timedwait() doesn`t >cancel and so pthread_join() doesn`t return. Further discussion probably isn't on-topic for debian-devel, however, unless you're talking about building a Debian package... -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpjSBwA9ZO3Q.pgp Description: PGP signature
Re: New glibc with NPTL in experimental
On Sun, Oct 05, 2003 at 09:49:17AM +1000, Brian May wrote: > On Fri, Oct 03, 2003 at 11:21:21PM -0400, Daniel Jacobowitz wrote: > > I've just placed a new glibc package for experimental in incoming. > > libc6-i686 is new, so it may be a few days before it shows up in the > > archive. These packages should be considered _extremely experimental_, as > > neither the NPTL libraries (requires 2.6.0; I don't think it will behave > > right if you have 2.6.0 on an i386; that's on the TODO list to fall back to > > LinuxThreads) nor the i686 optimized libraries (requires 2.4.18; will > > misbehave on non-cmov processors) have been well tested. Do not build and > > upload packages against them. Some intelligence, please :) > > I gather NPTL is (yet-another) threading library in 2.6.0? > > Do programs need to be modified / recompiled in anyway? > > What are the benifits of one over the other? New POSIX Threads Library, or somesuch. As for benefits... try "real POSIX threading", "doesn't choke and die on large numbers of threads", and "brings Linux remotely close to most of the rest of the world in terms of threading"... Now to get NetBSD to release 2.0 :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpCgUvB1o4mm.pgp Description: PGP signature
Re: kernel-source == Linux or Hurd or ???
On Wed, Sep 24, 2003 at 01:56:09PM -0500, Ryan Underwood wrote: > > Hi, > > On Mon, Sep 22, 2003 at 08:03:18PM +0200, martin f krafft wrote: > > > > This is a good point. Debian makes an effort to be kernel > > independent, so why does the kernel-source install Linux? > > > > I think we should rename to linux-kernel-source, linux-kernel-image > > and so on... > > I very much agree with this sentiment. However, what about system-level > utilities and essential packages? How does a Debian *BSD system differ from > a Debian GNU system (or for that matter, a Debian GNU/*BSD system), and > how should the dependencies between "bare-metal" packages and the kernel > (whether it be linux-kernel-source, freebsd-kernel-source, etc) be > constructed? The differences depend a lot on whether you view them as "what package is it in and how is it provided" (significant) or "what the user sees" (as minor as we can manage). > Maybe this is silly, but perhaps the "arch" portion of the apt sources > could also be fine-tuned to include the kernel type. (I guess similar > to the unique machine strings from config.sub and friends). A > linux-gnu-i386 distribution, a freebsd-gnu-i386, freebsd-bsd-i386, > et. al. While this would certainly approach a goal of greater > universality and kernel/machine independence of the distribution, would > that gain be worth the effort? Well, the 'arch' for the NetBSD/i386 is 'netbsd-i386'. Like I said before, while I'd love to see linux- prefixes to the current architectures, and an unprefixed arch be supported only as a legacy issue, I don't anticipate it happening any time soon. > Perhaps once the Debian/*BSD have stabilized and reach a greater level > of usability, we can ask these questions again later... Join us over on debian-bsd@lists.debian.org; we're discussing many of them now (or, rather, as we run across bits of them that need discussion). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpJ6hUkf0CWV.pgp Description: PGP signature
Re: kernel-source == Linux or Hurd or ???
On Mon, Sep 22, 2003 at 08:03:18PM +0200, martin f krafft wrote: > also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2003.09.22.1213 +0200]: > > So your complain reduces in my eyes to an incomplete label. > > I personally think not having the term "linux" in it more of an > > issue than having "-debian" in it... > > This is a good point. Debian makes an effort to be kernel > independent, so why does the kernel-source install Linux? > > I think we should rename to linux-kernel-source, linux-kernel-image > and so on... A battle for another day (or year). All I can say is that the only person I know of who is packaging the NetBSD kernel source (that is to say, 'me') is using netbsd-kernel-source- (-current for CVS HEAD), in much the same vein as the current kernel-source- packages. To date, there are no kernel patches specific to Debian's NetBSD port (and doing them is a bit of a touchy matter, given the dependance of some utilities on precise kernel structures; I should probably update the mini-policy to account for this, at some point). I do look forward to the day when "not having a prefix/suffice means Linux only for legacy support reasons", but I don't expect it to happen anytime soon. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpn3hmJaiKhd.pgp Description: PGP signature
Re: NMUs applying sleeping wishlist bugs about translation
On Wed, Aug 27, 2003 at 07:37:12PM -0400, Stephen Frost wrote: > * Joel Baker ([EMAIL PROTECTED]) wrote: > > This argument would carry more weight with me if it were possible to either > > A) test the upload *completely* before making it (IE, catch all possible > > FTBFS bugs or other quirks that happen when dealing with the build daemons, > > many of which even a sane chroot build can't catch), or B) to back out an > > upload and say "Well, damn. It has an FTBFS bug that I can't fix; I should > > file a bug on *that*, and back out to the last known good copy". > > Or file the FTBFS bug and if the maintainer isn't going to do anything > and no one is willing to actually maintain it then have it orphaned to > QA and/or removed. And that's the point. Some folks are asserting that the NMUer is responsible not only for filing the bug (as anyone who notices it should generally be expected to do), but for *fixing* it. Right then, since now there is a broken situation in unstable (in that usually at least one arch now has *no* binaries for it). Whether or not the NMU actually caused it, or merely exposed it. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpR6IE8XbibO.pgp Description: PGP signature
Re: NMUs applying sleeping wishlist bugs about translation
On Wed, Aug 27, 2003 at 02:05:15PM -0500, Manoj Srivastava wrote: > On Wed, 27 Aug 2003 11:46:41 -0500, Steve Langasek <[EMAIL PROTECTED]> said: > > > Holding NMUers accountable for the quality of their uploads: yes. > > Quite. If your upload caused the situation to deteriorate, > whether you deliberately caused the change that made it so or it was > inadvertent, you are responsible. This argument would carry more weight with me if it were possible to either A) test the upload *completely* before making it (IE, catch all possible FTBFS bugs or other quirks that happen when dealing with the build daemons, many of which even a sane chroot build can't catch), or B) to back out an upload and say "Well, damn. It has an FTBFS bug that I can't fix; I should file a bug on *that*, and back out to the last known good copy". Of course, the "last known good" copy is known to have an FTBFS bug, but *that* can't be the NMUer's fault, since it existed (simply undetected) prior to the NMU. And really, do we want it going into testing, and then stable, with an FTBFS bug that might have been caught otherwise, but isn't because folks are afraid to NMU stuff lest they get bitten by, say, a C compiler semantics change that may involve restructuring fairly important parts of the program to fix? Until one of these two things is possible, I find it likely to make a lot of folks who might otherwise consider NMUing (and do a perfectly good job) unwilling to do it, because they'd then be held responsible for the fact that the package was broken *apart* from anything they did to break it. If they're going to have all the pain of a maintainership on the package from then on, why shouldn't they just hijack it in the first place? I know that if I'm going to be held responsible for everything on the package from the last maintainer upload to the next (possibly non-existant) one, I'm sure as heck more likely to restructure it a manner which lets me handle it efficiently and without undue pain. And that generally means hijacking it (or adopting it, but NMUing an orphaned package is sort of silly; you REALLY should just adopt it if you care, since otherwise it's just going to get dropped). Of course, that means I'll handle about an order of magnitude fewer RC bugs, but we didn't want to release Sarge anytime soon, did we? Saying "well, they shouldn't NMU" is a risk, in my view, for the simple reason that can be observed by doing a wc -l on the claims files on master. If they aren't going to, it's very evident that nobody else is, either, and so the NMUs just won't happen at all. And perhaps that's fine and we should just remove the packages - but if that's the case, why are we bothering to have BSPs every weekend, and a 0-day NMU test? -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgps19BPchjEX.pgp Description: PGP signature
Re: Patch needs Sponsor - 20 bugs left - sorted by mtime
On Wed, Aug 27, 2003 at 12:32:59PM +0200, Goswin von Brederlow wrote: > > TITLE #195527:mysql++: FTBFS with g++-3.3: Missing include > Severity: serious > Package: mysql++ > Age: 87 days > Last changed: 15 days Please be more careful about these reports; this bug has been claimed for some time (I've been waiting on getting someone from the mips folks to get in touch about testing it on that platform, for the *other* RC bug, before uploading the fix). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpcWNs7oavq8.pgp Description: PGP signature
Re: Bits from the RM
On Thu, Aug 21, 2003 at 11:39:35AM +0200, Marc Haber wrote: > > I am only realistic. When in history did a non-trivial software > product meet its release schedule? > > I am surely hoping for the best, but I seriously do expect sarge to be > released in early 2004. Which is a pretty good track record if we > actually reach that. Well, FreeBSD hits their 6-month release targets more often than they miss them (yes, they do miss them sometimes, generally not by very far). True, they've had practice at it; I don't expect the first attempt to be pretty. I do expect that we could manage to match them, if it becomes a consistant release goal to set a date and then hit it. :) Even 'early 2004' is, frankly, not nearly enough time to ensure something as large as KDE goes from 'stable' upstream release (assuming *they* make a Dec 8th release) to 'bugs shaken out, stable enough to not need to turn around and do an r1 release a few weeks later because it blows up on user machines', for values of 'early 2004' that I would find most likely (to wit, right *after* the holidays, since slipping too much would put us into releasing during them; though the Debian Christmas Release would be mildly entertaining :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpE56YX0Cv4q.pgp Description: PGP signature
Re: Bits from the RM
Hi, I'm Troy McClure - you may remeber me from such threads as "How do we get Debian to have a useful release timeframe", and... *er, wait*. Okay, that sillyness aside... On Wed, Aug 20, 2003 at 08:51:16AM -0400, Theodore Ts'o wrote: > > Better to have a hard freeze schedule, and then try to turn out new > stable releases every 6-9 months. Then folks won't be so desperate to > shove new things in and screw up the release. The problem, though, is > the first such attempt take release schedules seriously and > agressively (a) a really hardass RM, and (b) a certain amount of faith > by the developers that we really can get our act together about short, > regular, predictable releases. Much, much better. I'd love to see it manage to hit every six months (and even I agree that more often that that probably isn't feasible; most of the major projects I know of that do scheduled releases don't have cycles < 6 months, and generally don't have too many users screaming about out-of-date software). The first time is going to be a lot of unfamiliar, a lot of hectic, and frankly, probably a lot of things that we don't get quite as right as we could with experience - since, of course, part of the need is to gain that experience. I'm glad to see, however, that an RM has decided that targeting an actual date, with an actual and concrete timeline (to compare against and know if we're slipping too far), and clear mileposts along the way, is a meaningful way to attempt a release. You already have (b) from this quarter - and my profound hope that we can, in fact, pull this off. Because it would resolve about 80% of the complaints I've ever heard from folks about Debian (another 19% being the install setup, which is also being remedied, and 1% being it's focus on Linux, which is a separate question entirely - and no, I do not forsee trying to get netbsd-i386 into sarge. If we manage to achieve a six-month turnaround, quite possibly not even into sarge+1; NetBSD hasn't announced a release target for 2.0 yet). Off to hunt some RC bugs, now... (yeah, yeah, I should have been doing this all along, but frankly, porting work took priority when there was no release goal :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpmFdFGuvjMV.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, Aug 19, 2003 at 09:16:03AM +0100, Andrew Suffield wrote: > On Mon, Aug 18, 2003 at 10:38:10PM -0600, Joel Baker wrote: > > > > If they get hit by a bus, reassigned by their job to Outer Mongolia, or > > just plain get bored with doing it, we lose that benefit entirely, as > > things stand today. I'm proposing that the function appears to be producing > > clear benefits, and that we should, in fact, adjust our expectations so > > that we retain those benefits in a more direct fashion. > > No, you are proposing something else entirely: that we require > somebody like this to upload the binary-indep components before the > packages enter testing. Just like the current system, which requires that uploads be made for all architectures that previously appeared, yes. Funny that. > > No, in fact, it doesn't. Which is the crux of the question. > > Argument by repeated assertion. Back at you. Which would imply that the entire issue can be resolved by demonstrating which of the two assertions is, in fact, correct. > > Are you attempting to suggest that the buildd arrangement uploads broken > > packages more often than maintainers do? > > Probably about as frequently. Okay; we're clear on that assertion, then. > > No, you can't. Or rather, you can swap it, and the wording is equally > > parseable - but no longer accurate. See above. > > And again. Which reduces to the same question. Fine. > > > Note that it is much _more_ important for a maintainer workstation > > > (where all the actually important stuff happens) to be working than it > > > is for a buildd (which is largely automated, and thusly can be easily > > > duplicated, replaced, or re-done). > > > > Where a failed workstation means someone else can build it, upload it, > > do an NMU; hell, you could even use the Debian machine farm (unless > > the workstation is your only access at all, which is quite a different > > question). > > Oh hey, just the same as a failed buildd, then. > > Except that one of these things is easy, and one is not. Agreed, but probably not in the way that you think. I'm going to assert that keeping things sane on a few dozen machines (the buildds) is easier than keeping them sane on 1000+ (assuming each developer has at least one machine to develop on; I have 3, myself). I suspect that's not the assertion you're trying to make, but it comes down, again, to a question of which assertion is *correct*. > > If you're going to assert that the buildds are breaking packages, please > > provide some backing to the assertion; showing that maintainers break > > packages is a trivial excercise in reading the BTS. > > So is showing that buildds break packages. Although a number of those > issues don't go through the BTS. They're probably about as reliable as > some random maintainer workstation - which makes sense, why should > they be any better? Because they have folks who spend a lot of time trying to ensure that they *are* better, for one; for another, the design of the buildd setup guarantees that, barring a very significant bug, it *will* catch one of the primary forms of maintainer error, which was the origional point - that fewer packages would be broken *because of* going through a buildd than would be caught as broken by going through a buildd. But let us take one concrete example: webmin. Which, as the bug filed and the conversation on the list should indicate, would probably have been caught by the proposed change. Feel free to document at least one case of a situation where a buildd would have caused an otherwise-proper upload to become a bad upload, by replacing the maintainer's binary-indep results with those from the buildd. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpOLt8j905pR.pgp Description: PGP signature
Re: About NM and Next Release
On Fri, Aug 08, 2003 at 05:59:52PM +0100, Andrew Suffield wrote: > On Fri, Aug 08, 2003 at 10:32:07AM -0600, Joel Baker wrote: > > > > * want to contribute something to a project they respect > > > > * want to help out Debian users > > > > * want to help promote the goals of Debian > > > > > > These are bad reasons. > > > > They are also the only reasons anyone would want to contribute to Debian, > > rather than to, say, NetBSD. Or any other open-source OS you might care > > to name. "Because it's there" may be a reason to code, but it produces no > > motivation whatsoever to contribute to Debian when there are MUCH easier > > places to contribute to. > > Start with the things about Debian which are distinctly different from > other projects. You should be able to find some things which you want > to do which depend on these things. If not... well, why *are* you here? In my case, it's the political infrastructure and charter. The Social Contract, the DFSG, the Constitution. That means, I guess, "want to contribute something to a project they respect" - at least, for why I contribute *to Debian*, rather than another project. Why I contribute at all is covered below. > > > I don't think you're going to get it, either. It's basically the same > > > question as "Why do people write free software?", and if you come up > > > with "altruism", "politics", or "respect" then you're barking up the > > > wrong tree. > > > > Funny. I thought the FSF was, at least origionally, more or less entirely > > about self-interest, altruism, and politics. > > The organisation might have been founded for those reasons, although I > think it was primarily politics. I don't think you'll find much (if > any) GNU code that was written because of them. Most of it was written > because "I need a foo. I don't *have* a foo, but I *do* know how to > make one". That's why the code was written - but it doesn't explain why it was contributed to the FSF. Giving over a copyright is not a small thing. > > So tell us - why *do* people write free software? > > I write software because I can, and I release it as free software > because that makes it better over time. Others will vary (I'm not in > the mood for writing an essay on the subject). Whereas I write it because it solves a problem I have, or because it interests me, and I give it away because I hope that others might benefit from it (even if just having a few moments of entertainment, in some cases) just as I have benefitted from the people who did it before me. That would be 'altruism'. Not as a reason to write it, but as a reason to give it away. I do not, and have never, subscribed to the theory that all altruism is merely well-concealed self-interest (though much of it very well may be). I also write code that I don't give away. Mostly either because I don't think anyone else who would ever need it would manage to find it, among the swamp that is the Internet, or because I intend to sell the code (or already have a contract to do so), and I certainly like to be able to eat, as much as the next developer, and employers who will let you open-source the code are still relatively rare (often for good reason). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpKHUUO17WCk.pgp Description: PGP signature
Re: About NM and Next Release
On Fri, Aug 08, 2003 at 08:21:48AM +0100, Andrew Suffield wrote: > On Thu, Aug 07, 2003 at 11:46:20PM -0400, Nathanael Nerode wrote: > > Andrew Suffield <[EMAIL PROTECTED]> wrote: > > >Anybody who has to ask "Why should I/we/they contribute?" is not > > >suitable for Debian. (The "answer", incidentally, is "because we can" > > >or "because it's there", or some other variation; it is a goal in > > >itself, and not a means to an end) > > > > OK, now *that* is just nonsense. People contribute because they: > > > > * use Debian and want to make it better > > * want to do something which is made easier by contributing to Debian > > These are passable, and a variation on the same theme. The first reason is an excellent reason to keep a private repository. The second reason seems to be routinely rejected when brought up by anyone in the NM queue as being an issue. > > * want to contribute something to a project they respect > > * want to help out Debian users > > * want to help promote the goals of Debian > > These are bad reasons. They are also the only reasons anyone would want to contribute to Debian, rather than to, say, NetBSD. Or any other open-source OS you might care to name. "Because it's there" may be a reason to code, but it produces no motivation whatsoever to contribute to Debian when there are MUCH easier places to contribute to. > > I'm sure there are other reasons. > > > > "Because it's there" is a non-reason. OK, maybe it was a > > reasonable (if silly) answer for why to climb Mt. Everest. But Debian > > isn't a natural feature of the landscape, and it certainly isn't an > > exceptional and notable one. (Real reasons for climbing Mt. > > Everest included "I like climbing mountains" and "It's the tallest > > mountain in the world", which were both implicitly understood.) > > > > That 'reason' isn't going to get *anyone* to contribute to Debian. It > > might get them to climb Mt. Everest, I suppose. > > That's funny. Those were all things I've heard from people who've been > with the project for years. > > I don't think you're going to get it, either. It's basically the same > question as "Why do people write free software?", and if you come up > with "altruism", "politics", or "respect" then you're barking up the > wrong tree. Funny. I thought the FSF was, at least origionally, more or less entirely about self-interest, altruism, and politics. There is certainly a self-interest to the early adopter, a risk taken (publishing free code) that one might hope to gain from (others publish free code that you can use in exchange). At this point, however, there is very little reason for self-interest to drive such things; the amount of code available is so vast that nearly anything you want can be found, cobbled together, or otherwise made with little effort. The only real exception is completely new stuff; even that, however, is often available quickly. These days, leeches don't actually write free code, even in the hopes of getting more free code; they already have more than they could ever realistically use, available. So tell us - why *do* people write free software? -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpmDwaRaNtDL.pgp Description: PGP signature
Re: Getting patches into packages, thought and ideas
On Thu, Aug 07, 2003 at 06:25:27PM -0400, Nathanael Nerode wrote: > Andrew Suffield wrote: > >glibc is even worse. It has multiple maintainers, and they still don't > >have enough time to chase down all the important bugs, let alone > >insignificant ones like this. > > This is unfortunately true; glibc seems to be severely broken on a > routine basis upstream. Kinda makes me want a new, freshly written C > library, but that's not an easy prospect. :-) *opens mouth* *closes mouth* *goes back to trying to purge NetBSD of 4-clause BSD licenses so that the netbsd-libc and netbsd-kernel-source-* packages will be free and clear* Only 10,000 files now... (hey, it *was* 15,000). -- Joel Baker <[EMAIL PROTECTED]> pgpue2Q7xC6Kw.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Sun, Aug 03, 2003 at 08:05:01AM +0200, Matthias Urlichs wrote: > Hi, Joel Baker wrote: > > > Diesel locomotives are a giant diesel generator hooked up to electric > > traction motors, running through the switchbox at something like 600v > > (I haven't read the specs in a while, this might be off - but it's high > > enough to warrant being really careful around). Don't even ask about the > > amperage. Sapping off a little power to run a few household outlets is, by > > comparison, peanuts. Or, really, peanut crumbs. > > ... assuming that the circuitry used to sap off 220Vac from that is up to > the task. > > A few years ago in Germany there was a huge stink raised by the > environmentalists (rightly so, IMHO) because the mid-range trains running > on nonelectrified trains sometimes ran with two Diesel locomotives so that > the coffee machines in the train bistro could get enough juice. :-/ Mmm. True enough; older locomotives were generally expected to run basic environmental (heat, A/C, lighting) and if it hasn't been refitted, that might be an issue. Which is silly, really, but nobody really envisioned personal use of appliances throughout, at least when the earlier units were being built (and yes, stuff from the 50s is still in active service today). I suppose one could always ask the rail company if they could arrange a locomotive with a new enough setup that it was intended to be used with such, but I'd have no idea how to do that for a European railway (now, if you want to ask BNSF or Union Pacific, I might be able to find out... :) -- Joel Baker <[EMAIL PROTECTED]> pgpAJmdlZNdVK.pgp Description: PGP signature
Re: debconf 2005 in Vienna, Austria
On Fri, Aug 01, 2003 at 02:06:48PM +0300, Riku Voipio wrote: > > Yes. a debcamp of users would probably blow some fuse :) Speaking as someone who's held an FRA (US Federal Railroad Administration) crew and fireman cert - it's unlikely, unless you do something that would overload a normal house circuit. Diesel locomotives are a giant diesel generator hooked up to electric traction motors, running through the switchbox at something like 600v (I haven't read the specs in a while, this might be off - but it's high enough to warrant being really careful around). Don't even ask about the amperage. Sapping off a little power to run a few household outlets is, by comparison, peanuts. Or, really, peanut crumbs. Now, just try not to be nervous at the fact that there's a pipe running under your feet pressurized to 90 PSI (at least on standard US trains), and you'll be fine. :) There's a reason they call popping the coupling seals on that line (the fail-safe (full stop) airbrake line) completely (rather than bleeding the air off) 'dynamiting'... -- Joel Baker <[EMAIL PROTECTED]> pgpRKx4EOtwNp.pgp Description: PGP signature
Re: setuid/setgid binaries contained in the Debian repository.
On Fri, Aug 01, 2003 at 11:34:11AM +0200, Tollef Fog Heen wrote: > * Steve Kemp > > | On Fri, Aug 01, 2003 at 08:20:08AM +0200, Tollef Fog Heen wrote: > | > | > what's wrong with a low-priority debconf question with a sane default? > | > | Absolutely nothing at all, but it's a slippery slope, and I thought > | we were tending towards less interactivity in installations? > > which is why I said «low priority»: > > 'critical' only prompts you if the system might break. >Pick it if you are a newbie, or in a hurry. > 'high' is for rather important questions > 'medium' is for normal questions > 'low' is for control freaks who want to see everything > > If you select low, you will have to drink off the fire hose. Having > low-priority questionsis good, since it makes it easy to make > customized installs with preloaded answers. The only question I would have about it is that every potentially-sgid game package would need to share the question (so that it only got asked once, but was available whenever needed) - organizing that could be a bit tricky, I would think. Certainly I think it would be one of the more reasonable uses of shared debconf stuff - one question, low priority, a sane default of not being sgid, and assuming packages used something proper (er, dpkg-statoverride?) to register the sgid bit, it doesn't matter if you blow away the answer cache - you can look at the existing state and find out what you need to know (or, presumably, override it). -- Joel Baker <[EMAIL PROTECTED]> pgpHUUfcNpVft.pgp Description: PGP signature
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Wed, Jul 30, 2003 at 12:48:55PM -0400, Jim Penny wrote: > On Wed, 30 Jul 2003 11:38:12 -0500 > Steve Langasek <[EMAIL PROTECTED]> wrote: > > > On Wed, Jul 30, 2003 at 05:56:32PM +0200, Emile van Bergen wrote: > > > > > >I object to this ITP. Not very strongly, but I still object. > > > > > I think it's a wonderful idea to have a decss package in Debian. If > > > Debian cannot distribute the decss that allows Debian users to view > > > DVD movies (yet), then distributing this one is a good alternative, > > > I'd say. > > > > You're clearly quite mad. Regardless of whether this script is > > trivial to implement, it's not something anyone should be encouraged > > to actually*use*. CSS is the *best* feature of the HTML4 standard. > > Why would anyone in their right mind wish to strip nearly all the > > logical structure markup out of a document? > > Uhh, it is to tweak the international copyright cartel, and the RIAA in > particular. They have written "cease and desist" letters to anyone who > has a file names deCSS on their system. This is an attempt to make such > a filename so common that these letters are pointless, and possibly > evidence of illegal activity. It strikes me that even if Debian (or a Developer) wished to encourage such a political statement, the vastly more efficient method would be to include it in some other package to which it might have relevance (for example, something that helped to generate CSS style information, or analyzed it, or whatever). Just drop it into /usr/share/doc as an example program (README.decss or somesuch), or as a helper app somewhere (though I'd be careful of /usr/bin, frankly). No new package, the (arguably useful) script goes into a place where it is most likely to be seen by those to whom it actually *is* useful, and everyone else doesn't have to try to figure out whether it's reasonable as a standalone package, or is just a 'joke', or what. (No, this isn't intended as "how to get around doing an ITP", but rather, as an alternative which assumes you can convince someone that the script is, in fact, useful enough to put into an existing package to which it might be applicable.) -- Joel Baker <[EMAIL PROTECTED]> pgpUFz9MND4T9.pgp Description: PGP signature
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 08:21:09AM +0200, Christoph Hellwig wrote: > On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: > > There is already a PAM modules, libpam-tmpdir which automatically sets > > this up on login by creating a per-user directory under /tmp and > > pointing TMPDIR at it. Despite the scary low version number of 0.04 > > it seems to work reliably and presumably any bugs could be fixed. > > Nice idea, wrong implementation. Let login fork the login shell with > CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. Except for OS types or versions that don't support that, or people who actually want /tmp when they explicitly request it, even if TMPDIR=~/tmp is fine most of the time. I can't think of a better way to get admins to simply turn it off completely than to make it completely override /tmp and have no good way around that. -- Joel Baker <[EMAIL PROTECTED]> pgpPpSvz4iJ0W.pgp Description: PGP signature
Bug#200654: ITP: debpool -- pool-based DEB package archiver
Package: wnpp
Version: unavailable; reported 2003-07-09
Severity: wishlist
* Package name: debpool
* Version: 0.1.0
Upstream Author: Joel Baker <[EMAIL PROTECTED]>
* URL: N/A
License: BSD
Description: pool-based DEB package archiver
DebPool is a pool-based DEB package archiver designed with a goal of
removing any dependancy on code not shipped as part of the core Debian
system.
It is capable of all of the following:
* Tracking multiple distributions (however, it does *not* include
unstable -> testing promotion scripts).
* Generating Release files (requires libdigest-{md5,sha1}-perl)
* Verifying package signatures (requires gnupg).
* Signing release files (requires Release files and gnupg).
* Running in single-pass or daemon modes.
DebPool is intended to be a lightweight replacement for the full Debian
archival scripts, in the tradition of debarchive and mini-dinstall, but
using a pool layout and avoiding external dependancies.
--
Joel Baker <[EMAIL PROTECTED]>
pgplAxvFdAqyR.pgp
Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sun, Jun 29, 2003 at 02:13:48PM -0400, Nathan Hawkins wrote: > On Thu, Jun 26, 2003 at 04:24:23PM -0400, Matt Zimmerman wrote: > > On Thu, Jun 26, 2003 at 09:44:30AM +0200, Christoph Hellwig wrote: > > > > > On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: > > > > ports - NetBSD gives us the potential to bring Debian to _many_ new > > > > platforms. > > > > > > It's not that many actually. The only CPU that NetBSD claims to support > > > but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 > > > aren't really useable unlike their NetBSD counterparts. > > > > However, NetBSD doesn't run on IA64 or S/390 as far as I know, while Debian > > does. > > Of course, FreeBSD (5.0) does run on IA64, so I suspect it won't be that > long before NetBSD has a port to it. I also recall seeing that people > are in the process of porting both FreeBSD and NetBSD to S/390. Not to mention a (reasonably close to?) working amd64 port (recently renamed). -- Joel Baker <[EMAIL PROTECTED]> pgpllBGNSltA2.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote:
> On Wed, 25 Jun 2003 14:04:54 -0500
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> > And not only 80386 needs this - There is the Sparc64 port which would
> > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
> > had support for subarchtectures, not only would the ix86 mess be able to
> > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
> > you fancy). And I am sure this can somehow help maintain the non-Linux
> > ports - NetBSD gives us the potential to bring Debian to _many_ new
> > platforms.
>
> No it doesn't. I've yet to even hear of an architecture that NetBSD runs
> on but which Linux doesn't. They just have a different definition of
> "architecture" than us. (ie: our "hppa" may be three or four arches to
> the NetBSD kernel folk.)
There are a couple. I don't think most people care about any of them,
right now (and quite possibly never will, in the case of old VAXen,
for example).
In discussing it the other day, I actually found a concise way to
express one of the major reasons I choose to work on the port and find
it worthwhile:
NetBSD's motto is "Yes, it runs NetBSD".
NetBSD other motto is "correctness above all" (by comparison, OpenBSD is
"security above all", FreeBSD is "features above most", and Linux would
probably be "bleeding edge above most").
Sort of like Debian's release schedule is "when it's ready", and for the
same reasons.
Their -current is more or less like our unstable ("It may break, but people
always scream at us when it does so for any significant length of time").
They don't release fast (other than security patches), but they do have a
good history of their releases being rock-stable.
--
Joel Baker <[EMAIL PROTECTED]>
pgpVPPhefbfAy.pgp
Description: PGP signature
Re: maildirmake
On Tue, Jun 24, 2003 at 01:12:04PM +1000, Matthew Palmer wrote: > On Mon, 23 Jun 2003, David B Harris wrote: > > > Exim is capable of handling Maildir mailboxes. It's Priority: important. > > I don't know if that counts as "shipping it by default" or not, but I > > would certainly say that it's the closest thing around. > > Capable of handling, yes, but then, so is cat.Once delivered, though, > there's no way of getting it back out again unless you're running something > like courier or similar. Or most modern local MUAs... after all, most folks don't read their mbox with cat, either (though it's equally possible). > My logic was that, from the basic system, Maildir mailboxes are no use. > Things like courier make Maildir useful, so that's where the maildirmake > script should live. It *might* make sense to put it in exim where people > can run it to make their mailboxes, but since the delivery is useless > without other programs to post-process, I'm still not won over on the > idea... It is, to within a close order, as useful as mbox mail delivery; however, it probably isn't worthy of it's own package, and having multiple MTAs (or MUAs) provide it makes little sense, really... perhaps it belongs in one of the "general utility" packages? -- Joel Baker <[EMAIL PROTECTED]> pgpEAWccWVLSz.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
On Fri, May 23, 2003 at 09:04:05AM +0200, Martin Schulze wrote: > Martin Schulze wrote: > > Only a few people will probably have noticed the mess resulting from > > tons of different kernel packages in the stable (and unstable) > > distribution. Not only there are several versions of kernel source in > > each architecture, they are also different for most architectures. > > Only mips and mipsel share the same kernel source. > > > > To make it worse, there are also third party kernel modules that > > depend on a particular version of the kernel source (they don't depend > > on the particular Debian revision, though, I hope). > > > > As a result of this, it is almost impossible to update the kernel in a > > released Debian distribution. > > Manoj emphasized[1] that using one single kernel source package per > kernel version and maintaining several patch packages for each > architecture which finally build our kernel-image-$version packages is > possible. > > However, Herbert Xu hasn't contributed to this thread yet and most of > our architecture maintainers haven't raised a word either. These are > most probably the people who will continue to do the work, and hence, > need our support if the kernel source tree should be consolidated. Well, okay, this is only semi-ontopic for the thread, but as the person currently working in ~/Debian-Packages/netbsd-kernel-*, I'll speak up: I'm trying very hard to arrange that we don't repeat the misfeatures of this particular past. This is, granted, far easier than for Linux, since there isn't really a concept of a 'separate arch repository' to be out of sync, on NetBSD. (No, this isn't pimping it; I don't even have it compiling yet.) That said, I firmly believe the idea is one with merit, even if it won't be easy. -- Joel Baker <[EMAIL PROTECTED]> pgpifBkogNNq0.pgp Description: PGP signature
Re: Request for Clue: i18n of fortune-esque things
On Thu, Apr 24, 2003 at 09:35:41AM +0200, Andreas Tille wrote: > On Thu, 24 Apr 2003, Joel Baker wrote: > > > larger sense, is whether there is a way to have the translations available > > in some easily selectable format. > I think the i18ned fortune makes this simple. That's more or less what I was hoping - however, checking /usr/share/doc/fortune-mod doesn't show any references to 'language', or any obvious references to i18n or l10n, at least on stable (my chroots are currently down due to one machine having some severe stability problems). Is this just a more-recent-than-stable development? > > I suppose that simply having multiple text/index files with a language > > designation as part of the filename would work, though it feels... ugly. > > But perhaps that's an extension for the fortune program itself, at some > > point, to support, similar to man's breakdown... > I'm afraid I do not understand your problem right. > > Kind regards The above will probably suffice; i18ned fortune is really what I was looking for. -- Joel Baker <[EMAIL PROTECTED]> pgpdl6JcCLWI0.pgp Description: PGP signature
Re: Autobuilder locale setup
On Wed, Apr 23, 2003 at 02:02:45PM -0600, Adam Conrad wrote: > Roger Leigh wrote: > > > > This works fine when the locales exist for each localisation, but if > > they don't exist, it defaults to C locale/US-ASCII charset. Can the > > autobuilders guarantee a full set of generated locales, or is only C > > available? > > Autobuilders don't even have "locales" installed by default, as it's > non-essential, so you certainly can't count on any specific locales being > there, no. You can, however, generate the locales that you need and make > them available to you during your package build, with some trickery. See > debian/locale-gen in the gcc-3.2 source package, for instance. Do keep in mind that locales are not guaranteed to even exist on all archs (to wit, only glibc based arches have it as it's commonly used). NetBSD *does* have locale support, but it's a somewhat different beast. Which has not (yet) even been solved for gcc, sadly (I don't know enough about the system, yet, to usefully fix this issue for gcc). Granted, the likely result is that it simply fails to build (ever) on such archs, until some useful solution is found, so it probably doesn't matter all that much (won't keep it out of testing or any other such evilness, etc...) Failing that, it's on my TODO list for netbsd-libc, but rather behind a number of other things like backporting some important compiler support features. -- Joel Baker <[EMAIL PROTECTED]> pgpR00DWyAbTR.pgp Description: PGP signature
Re: Request for Clue: i18n of fortune-esque things
On Wed, Apr 23, 2003 at 11:38:32PM +0200, Andreas Tille wrote: > On Wed, 23 Apr 2003, Joel Baker wrote: > > > What I was wondering is whether there is a way to do translations of > > the fortune data, without having to have 'fortunes-debian-hints-' > > packages. Granted, I probably won't be able to do much useful about > > translating them, myself, but I'd like to at least know if it's doable to > > support such a thing. > I just had the idea of translating these hints myself and thus I talked > with Grisu about using the DDTP server for this purpose. He promised > to think about this ... Certainly I'm all for anything that would manage to translate the text in the package, be it DDTP or individual volunteers; the question, in some larger sense, is whether there is a way to have the translations available in some easily selectable format. I suppose that simply having multiple text/index files with a language designation as part of the filename would work, though it feels... ugly. But perhaps that's an extension for the fortune program itself, at some point, to support, similar to man's breakdown... -- Joel Baker <[EMAIL PROTECTED]> pgpcrjZvZ2dPc.pgp Description: PGP signature
Request for Clue: i18n of fortune-esque things
So, as some of you may remember, after a discussion on debian-devel about wanting some way to give a "tip of the day" or similar functionality for new (and sometimes used.. er... experienced) Debian users, I did an ITP for fortunes-debian-hints. It's now in testing (or so the PTS would lead me to believe), and has a small, if hopefully useful, seed of hints. (Speaking of which, folks should feel encouraged to submit more - I have a mild preference for using the BTS, but email to my @d.o address will suffice if you're only doing 1 or 2 and want to avoid hassling with it). What I was wondering is whether there is a way to do translations of the fortune data, without having to have 'fortunes-debian-hints-' packages. Granted, I probably won't be able to do much useful about translating them, myself, but I'd like to at least know if it's doable to support such a thing. -- Joel Baker <[EMAIL PROTECTED]> pgp1PoPdEVsp3.pgp Description: PGP signature
Re: Bug#150411: Release-critical Bugreport for April 4, 2003
[ I host the xshipwars upstream mailing lists... ] On Fri, Apr 11, 2003 at 11:32:04AM -0500, Adam Majer wrote: > On Fri, Apr 11, 2003 at 10:27:06AM +0100, Colin Watson wrote: > > On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote: > > > On Fri, 4 Apr 2003, BugScan reporter wrote: > > > > Package: xshipwars-server (debian/main) > > > > Maintainer: Adam Majer <[EMAIL PROTECTED]> > > > > 150411 [P ] xshipwars-server: POSIX shell incompatibilities > > > > 173966 [ ] xshipwars-server: won't uninstall unless the server > > > > is running! > > > > > > This package has is taged patch to one bug and in fact includes another > > > patch in the text of the other bug which is tagged pending. Moreover > > > it contains an offer from Colin Watson to sponsor the package from > > > half a year ago. I guess someone should hijack the package. > > Yo, what's the dillio? At least *ask* me if I'm still here! :) > > Both bugs are trivial and xshipwars wouldn't be going anywhere anyway > because lijsw has to get fixed (it is a C library compiled as > C++ library - for why look at the orig.tar.gz files). > > If you want to hijac a package, look at some of the O: packages > that need to get picked up. > > > Hold it for a bit, please. I've been talking to the maintainer privately > > for the last week. An upload is waiting until the new libjsw is > > accepted. > > As he said :) You're a braver soul than I. I started a packaging attempt on it once (long ago), and... well... let's just say I know the insides of the code, and I have known the primary author since well before the project existed, and I will never, ever try to package it again as long as she's the primary author... (In other words, I'm vouching to anyone who wonders that the code is enough to drive anyone seriously insane, and making it sane is no easy task.) -- Joel Baker <[EMAIL PROTECTED]> pgps8O3JmKrpW.pgp Description: PGP signature
Re: /run and read-only /etc
On Thu, Apr 10, 2003 at 07:27:42PM -0400, Jeremy Jackson wrote: > Overall I think it is wonderful to see support for read-only root being > worked on. > > On Wed, 2003-04-09 at 15:41, Matthew Garrett wrote: > > Jeremy Jackson wrote: > > > > (doing this with bind mounts) > > > > >2.2 kernels are out though. > > > > As are BSDs. I have no idea whether the Hurd supports bind mounting. > > > Can it be assumed that all systems that may use this support ramdisks? > What other schemes would allow a read-only root? Mounting a small fs on > /run (although I hope it's not in the root directory)? I think all of the BSDs currently in porting support some concept that is functionally equivalent to a ramdisk. Can't say anything useful about the Hurd. -- Joel Baker <[EMAIL PROTECTED]> pgpzUc7Rh08Jq.pgp Description: PGP signature
Re: ocaml compiled binaries and rpath
On Fri, Apr 11, 2003 at 11:11:17AM +0200, Sven Luther wrote: > On Thu, Apr 10, 2003 at 10:56:34PM +0200, Martin Pitt wrote: > > lintian says: > > > > W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets > > /usr/lib:/usr/X11R6/lib > > N: > > N: The binary or shared library defines the `RPATH'. Usually this is a > > N: bad thing. Most likely you will find a Makefile with a line like: > > N: gcc test.o -o test -Wl,--rpath > > N: or > > N: gcc test.o -o test -R/usr/local/lib > > N: Please contact debian-devel@lists.debian.org if you have questions > > N: about this. > > Just ignore it or add a override. Any reason not to Build-Depend: chrpath, and do 'chrpath --delete' on the result? -- Joel Baker <[EMAIL PROTECTED]> pgpoDdFlmOlfG.pgp Description: PGP signature
Re: private debian pools
On Sun, Dec 08, 2002 at 02:03:44PM +0100, Roland Mas wrote: > Brian May (2002-12-07 16:36:58 +1100) : > > > I have a set of scripts for creating private debian package pools, > > available at: > > Wonderful. We now have two tools providing almost the same > functionality, except only one does package pools (bin2) and only one > is mature (mini-dinstall, by Colin Walters). Could we possibly hope > for a merger of those two? I'd very much like to have a pool-aware > mini-dinstall... And don't forget debarchiver, which doesn't (yet) support pools, but is in use in a number of places for doing old-style archives, too. I'd honestly prefer to see the actual archive scripts (The One True Archiving Tools, of which all others must, by definition, be emulations) packaged and useable by mere mortals, but the last I'd heard, this was a long way off, and not terribly high on most priority lists. -- ******* Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpBLKkdFPmTn.pgp Description: PGP signature
Re: Pick a name, any name...
On Thu, Nov 28, 2002 at 07:39:02PM -0800, John H. Robinson, IV wrote: > Ben Armstrong wrote: > > > Bah, that's what CNAME is for. > > that is _NOT_ what a CNAME is for. a CNAME is for when the hostname is > in a domain that is OUTSIDE of your control. > > ie: evil.debian.org -> www.msn.com = CNAME (we don't control the msn.com > domain) > forge.debian.org -> quantz.debian.org = A (we control the debian.org > domain, so we can save the internet by REDUCING THE NUMBER OF > UNNECESSARY DNS LOOKUPS AND REDUCE THE END USERS DELAY WITH DNS LOOKUP > REQUIREMENTS) > > isn't this a FAQ somewhere? > > -john Except that every major implementation of the DNS protocol in the past ten years or so has generated a reply that had the A record the CNAME points to, if it was also authoritative for that record (which, generally, is the case if it's an in-domain indirection). And, by the way, that *is* one of the uses of a CNAME. To allow things such as service names (www, ftp, etc) to point to a single IP, which might have one of those names, or something else, as it's formal name. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpzMoBwuSBiG.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Wed, Nov 27, 2002 at 07:05:31AM +0100, Tollef Fog Heen wrote: > * "Joel Baker" > > | > (I can think of one trivial example--devfs makes it really easy to tell > | > which disks are available to the partitioning program. Can you describe > | > a simple method to do that, which is guaranteed to work on any kernel? > | > Likewise, can you describe a kernel-independent way of parsing the pci > | > device table and loading relevant drivers?) > | > | To run with your example... I could care less how it's done on a Linux > | kernel, if the API says "Calling this routine will return a list of device > | names which can be safely handed to the partitioning subsystem". Maybe > | that's devfs on Linux, a Perl script on NetBSD, and green cheese on some > | other system. *As long as the API does not assume anything about the system > | underneath*, it *becomes* the 'simple system to do that on any kernel'. > | That's all I'm asking for - careful API design, that tries very hard to > | *not* make any assumptions about such things, and breaks things down far > | enough that one can safely encapsulate OS-specific ways of doing it such > | that they can be replaced. > > Yes, that's a goal, eventually. We are not there yet. First, get > things working, then make then work and look nice. Trying to do two > things at a time will make you fumble and not do any of them well. I might argue, in the case of APIs, that it is more a case of "If you don't have time to do it right, how will you ever have time to do it over" - it becomes *very* hard to un-entrench bad API choices, a lot of the time. > | On the other hand, if it *is* supposed to support non-Linux ports, all I'm > | asking for is that people try to be mindful of such assumptions and keep > | them hidden as implementation details, rather than core assumptions. > > The core assumption in d-i is debconf and some implementation of > dpkg. Apart from that it is all modules which can be switched at > will. Yes, there are linuxisms and i386isms in the code. Yes, they > will be fixed. However, in contrast to the above, it sounds like you have things split out enough that hopefully it won't come back to bite anyone later, too hard. Specific bits of code are far easier to fix than flawed design. I will grant that my perspective may be skewed; I typically do what programming work I do under folks who prefer lightweight processes (XP and things not quite so lightweight, but close), and for whom not having a clear API means you don't write code - because you have no idea what the code should be doing. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgprJcKvPjZN0.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 08:54:29PM -0500, Michael Stone wrote: > On Tue, Nov 26, 2002 at 05:07:51PM -0700, Joel Baker wrote: > >In the origional message, I merely pointed out that keeping such things > >properly encapsulated is crucial, if you EVER want to be able to run on any > >other kernel. > > Which original message? The one I saw said "Certainly it will have a > hard time working on any of the BSDs anytime soon, if it relies on devfs > more than trivially" and "Use of /proc should also, prefferably, be > limited to traditional /proc items and not the Linux view." You didn't > say anything about encapsulating them, or using them only where > appropriate, you just said to avoid them. I suppose it boils down to what you consider "relies on" to mean. If things are hidden behind a module that can easily be replaced so that it never touches devfs, then I don't consider it "rely on" devfs. I said to avoid *relying on* them, not to avoid *using* them when possible. > >That's all I'm asking for - careful API design, that tries very hard to > > That's what you're asking for now, and it doesn't seem nearly as > controversial as what you asked for the first time. (Seems pretty close > to what I said when I suggested you'd have to plug in some > kernel-specific code for certain functions.) Which came later. But I suggest that, at this point, we write it off as a failure of communication; it would appear that we both want more or less the same result, and just picked different words for it. Which is unfortunate, but it happens. Sorry. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpXsan2MxJkr.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 06:37:50PM -0500, Michael Stone wrote: > On Tue, Nov 26, 2002 at 04:26:16PM -0700, Joel Baker wrote: > >I must admit to some confusion, here. Should I take this as implying that > >there is no particular intent to try to make Debian-Installer play nicely > >on anything but Linux kernels? > > I'm saying that some things that an installer does are by their nature > specific to a kernel. Others are not. If the people writing the software > decide that a particular piece is better written to use /proc or /devfs, > then they should use /proc or /devfs without losing a lot of sleep over > it. In the origional message, I merely pointed out that keeping such things properly encapsulated is crucial, if you EVER want to be able to run on any other kernel. > (I can think of one trivial example--devfs makes it really easy to tell > which disks are available to the partitioning program. Can you describe > a simple method to do that, which is guaranteed to work on any kernel? > Likewise, can you describe a kernel-independent way of parsing the pci > device table and loading relevant drivers?) To run with your example... I could care less how it's done on a Linux kernel, if the API says "Calling this routine will return a list of device names which can be safely handed to the partitioning subsystem". Maybe that's devfs on Linux, a Perl script on NetBSD, and green cheese on some other system. *As long as the API does not assume anything about the system underneath*, it *becomes* the 'simple system to do that on any kernel'. That's all I'm asking for - careful API design, that tries very hard to *not* make any assumptions about such things, and breaks things down far enough that one can safely encapsulate OS-specific ways of doing it such that they can be replaced. > If you want to support the same functionality on whatever other kernel > you want to use, you'll have to write some (kernel-specific) code to do > so. Does that mean you can't leverage the partitioning tool once a device > is given? Or that you can't use the network config tool once the network > drivers have been loaded? Of course not--so why are you trying to start > some sort of kernel jihad? Have you stopped beating your wife yet? It isn't about a 'kernel jihad', or saying that Linux sucks. It's saying "If you want a Linux specific installer, fine, but tell those of us working on non-Linux ports so we can dump Debian-Installer and work on something that will someday actually install our ports". On the other hand, if it *is* supposed to support non-Linux ports, all I'm asking for is that people try to be mindful of such assumptions and keep them hidden as implementation details, rather than core assumptions. Three examples: 1) 'Core' /proc, which appears to be the same on all known ports. Still good to have things that use it be tied behind an API (in case there is ever a port that doesn't have it), but whatever is written for the Linux version will probably work just fine on the rest. 2) Sysctl, which on Linux can be found either via 'sysctl' or /proc/sys, but on other OSes is generally only 'sysctl'. If if was written as /proc/sys, I'd probably just rewrite it when I came to it, and suggest that it was a more portable way to access it all (bringing it back into the realm of example #1). 3) Devices for partitioning, which Linux can find via devfs, and the others may or may not be able to imitate so easily - but which, if bound behind an API, becomes an implementation detail, so we write modules to handle this on other OSes. Don't forget to keep assumptions about "what is a valid device name" out of this, though; what you call /dev/hda (or /dev/discs/disc0) I might call 'wd0', or even 'wd0a' (partitions within slices, and other quirks). -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpXDZZgKw3pz.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 05:58:06PM -0500, Michael Stone wrote: > On Tue, Nov 26, 2002 at 03:20:40PM -0700, Joel Baker wrote: > >In practice, I find that once such assumptions creep in, it can be very, > >very hard to remove them without yanking out a lot of entrails to go with. > > Which is the price to be paid for using a different kernel. An > installer, by its nature, is going to be kernel dependent. It also needs > to be small and maintainable. I don't think it's imediately obvious that > coming up with a kernel-independent hardware detector and module loader > (for example) is worth the trouble. If you want to write one, great--but > don't impose that as a requirement on others. I must admit to some confusion, here. Should I take this as implying that there is no particular intent to try to make Debian-Installer play nicely on anything but Linux kernels? Whatever the answer is, fine, but it would be nice to know so that those of us involved with the rest can decide to either not waste our time on something that won't benefit us at all, and build something that will, or so that the folks working on it know that making such assumptions *will* cause problems when they become invalid. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpC9xI1ub1lJ.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 08:03:12AM -0500, Michael Stone wrote: > On Mon, Nov 25, 2002 at 06:43:03PM -0700, Joel Baker wrote: > >Certainly it will have a hard time working on any of the BSDs anytime soon, > >if it relies on devfs more than trivially; they have no concept of it, nor > >are they really likely to anytime soon. > > > >Use of /proc should also, prefferably, be limited to traditional /proc > >items and not the Linux view of using it as a sysctl area (though there is > > Another option is for the bsd port to write their own installer module. > If something is radically easier to do using devfs or proc I don't think > it's reasonable to forbid it because of a hypothetical bsd port. In principle, agreed. In practice, I find that once such assumptions creep in, it can be very, very hard to remove them without yanking out a lot of entrails to go with. This can be handled, but the worth of being careful to properly keep these things from creeping out beyond where they can be replaced is still there. -- ******* Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpsgaV71ohba.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Tue, Nov 26, 2002 at 11:20:18AM -0600, John Goerzen wrote: > On Tue, Nov 26, 2002 at 11:39:41AM -0500, Colin Walters wrote: > > Because, somewhat circularly, that's what has emerged as one of Debian's > > strong points, and we like it. Certainly it makes the releases slower. > > But it's one thing that really differentiates Debian from the > > competition. Being the most portable Free OS is worth something, in my > > opinion. > > I think NetBSD still has us beat on that point. And thus, our evil plans to subvert it in the name of our cause to RULE THE WORLD! Er, wait. Did I say that in my out-loud voice? Damn. Now I'll have to feed you all to the sharks with lasers on their heads. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpTkeWohCNJt.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Mon, Nov 25, 2002 at 07:28:33PM -0600, Adam Heath wrote: > On 26 Nov 2002, Tollef Fog Heen wrote: > > > Let's first have a working installer on at least a few arches before > > walking down that road. However, it is a problem which I was notified > > of a few days ago: d-i relies heavily on devfs and, well, 2.4 doesn't > > work on m68k and it doesn't look like it will in the foreseeable > > future. So, help with getting this worked out will be appreciated. > > devfs support should be removed, in my opinion. There is still continuing > talk of removing it from the kernel, as distributors(us and the other guys) > have failed to support it. Certainly it will have a hard time working on any of the BSDs anytime soon, if it relies on devfs more than trivially; they have no concept of it, nor are they really likely to anytime soon. Use of /proc should also, prefferably, be limited to traditional /proc items and not the Linux view of using it as a sysctl area (though there is nothing wrong with calling 'sysctl' for such things on the BSDs, at least not on NetBSD and not that I *know* of on FreeBSD). -- ******* Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpE93tR8aVd0.pgp Description: PGP signature
Re: Antigen found =*.pif file
On Sat, Apr 20, 2002 at 07:41:42PM +0100, Carlos Sousa wrote: > On Sat, 20 Apr 2002 12:24:51 -0600 > "Joel Baker" <[EMAIL PROTECTED]> wrote: > > I don't think that declaring something which complies with RFC > > 2821/2822(the core SMTP-based email RFCs) is a good idea. The message > > should not have left the remote server without a qualified domain, but > > this is a bug in *their* implementation, *not* in the receiving MTA. > > > > Please do more research into the standards before making such a claim > > next > > Have you done yours? Quoting from RFC 2822: >"In all cases, the "From:" field SHOULD NOT contain any mailbox that >does not belong to the author(s) of the message." Are we talking about From:, or From_? Only the former is specified in 2822, the latter is from 2821 (which has no such specification, AFAICT). Rewriting the From: header is, indeed, not good; I was under the impression that we were, however, seeing From_ rewritten. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Antigen found =*.pif file
On Sat, Apr 20, 2002 at 11:22:55AM +0100, Carlos Sousa wrote: > On Sat, 20 Apr 2002 12:19:45 +1000 > Martijn van Oosterhout wrote: > > > >> i guess antigen didn't specify any @ in From:, and the other > > > >> mta's filled in their own name for some reason... > > > > > > > > That's the default behavior of all MTA's I'm familiar with. > > > > > > Some MTAs do indeed qualify random unqualified addresses they find > > > with their own mail domain name. > > > > The reason is so the you can type mail and have it end up > > at the right place. i.e. you don't need to know the mail domain to > > send a mail to the local user. > > In that case, the mail message should *never* leave the local domain. > > > They also fix the from address so that if the message is > > forwarded offsite, the reply still makes it. > > Still makes it where? In my case, the message originated in a > university in the US, but the MTA there didn't add its domain. Then it > appeared in my mailbox as coming from my ISP's domain, so if I reply to > it, it'll get nowhere near its original sender. > > I agree this *has* to be a bug. Relaying MTAs should not take over > important mail headers, that's dangerously close to mail forgery... I don't think that declaring something which complies with RFC 2821/2822 (the core SMTP-based email RFCs) is a good idea. The message should not have left the remote server without a qualified domain, but this is a bug in *their* implementation, *not* in the receiving MTA. Please do more research into the standards before making such a claim next time. Though it's "free" status may be in question, the doc-rfc package remains available to Debian. Well, the split version of it does, anyway. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: O: gnu-standards -- GNU coding standards
On Tue, Apr 09, 2002 at 04:20:54PM -0500, Branden Robinson wrote: > On Tue, Apr 09, 2002 at 01:45:56PM -0600, Joel Baker wrote: > > You know, I keep hearing this. Does this mean we should ditch the entirety > > of GCC's manuals, even old ones which weren't under the FDL, since the FSF > > has *clearly* indicated that *they* do not consider them to by software, > > since they created a *separate license* solely for documentation - which > > means that for their intent, documentation != software, and thus, Debian > > should respect that and not publish it, since it's not software at all? > > What the FSF considers software vs. documentation is not relevant to the > DFSG. Not to the DFSG - but it *should* be, to Debian, if we are to be a "good neighbor". Legally? Sure, we can do it. Is it *right*? I don't think so. You're certainly welcome to disagree with me. It's people not being good neighbors and respecting the author's intent that cause needing such licenses in the first place. This is, I will grant, a fact of life - but I don't have to encourage it, do I? > What matters is whether Debian applies the DFSG to a work, irrespective > of whether the work is categorized by its author, the FSF, or Debian as > "software", "documentation", or "fried green tomatoes". I'm simply saying that *I* believe that Debian *should* apply the author's intent to determining if something is software or not-software. If we then choose not to publish non-software, hey, that's not being a bad neighbor, just one who doesn't want to be in that business. Fine. But this whole "all the world is software" is making the *words* of the Social Contract and the DFSG into gosphel, rather than the intent (as the DFSG author has *said*, it would appear). If you want to see what happens when words become more important than intent, look at your favorite villan among major religions and their history. Am I saying we should ignore the DFSG, or the SC? No. Will I uphold them as they stand? I agreed to in my NM application, yes, and I will. Do I think they're holy documents that can never be changed? If so, why the do we have methods for changing them? I'd already be working on a GR to clarify and/or resolve it, and at least *try*, but I'm not permitted to offer one yet. > I don't have a problem with putting fried green tomatoes in main as long > as they're DFSG-free fried green tomatoes. ;-) I do, if people are going to bandy about the Social Contract clause "Debian is 100% Free Software" as meaning that everything MUST be software. Fried green tomatos do not run well on any CPU I am aware of. They tend to cause short-circuits and smell bad. > On a more serious note, the position you're stating is a false > alternative. People who would rather see non-DFSG-free documentation in > main are trying to say that their opponents would exclude DFSG-free > documentation from main because it's not software, not because it's not > DFSG-free. That argument is ass backwards, and dishonest. I didn't bring it up. Go read the archive if you haven't seen folks (I believe Steve is one major proponent) saying that unless we treat it all as software, it can't go in. I say that declaring an apple to be an orange does not make it just a funny colored orange. > The important trait of a copyrighted work for Debian is its licensing, > not what ontological category someone has elected to place it in. Nobody has yet to explain to me why invariant sections are not worthy of a similar exception to Clause #4 of the DFSG, or don't in fact fall under clause #4 directly. What is wrong with the author wanting their source (or parts of their source) to remain unmodified, so long as they permit us to distribute something which also updates it? See, this is why I don't understand the assertion that the GFDL isn't free. Even if you make the ENTIRE DOCUMENT invariant - I don't think that it's nice, or that we should encourage it, but I don't see why that makes it any more non-free than TeX is, so long as one can patch it externally. I think we should actively discourage it, just as we actively discourage TeX style "pure source" licenses, but please explain to me why it can't qualify under clause 4. > /me wonders if that last sentence will summon Eray Ozkural, and if so, > if that makes it a new corollary of Godwin's Law No comment. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bootstrapping build process?
On Tue, Apr 09, 2002 at 09:15:26PM +1000, Brian May wrote: > Hello, > > We have the somewhat unusual situation that Heimdal build depends on > kerberoskth and kerberos4kth build depends on Heimdal. > > kerberos4kth depends on heimdal because, this way it can share some low > level libraries which are included in Heimdal. Libraries that don't have > anything to do with Kerberos in fact, such as libroken and libcomerr. > This depends isn't very satisfactory, ideally these libraries need to be > split up into a seperate source stream package, but that isn't going to > happen any time soon. > > heimdal depends on kerberos4kth because it supports kerberos4. > > This worked fine until the move to non-us. > > However, now that the packages have moved into non-us, the builders are > confused because they don't know how to build either package, because it > depends on the other one being built first. > > Mikael's suggestion was that I remove kerberos4 support from Heimdal, > and upload, hence allowing kerberoskth to build. When kerberos4kth is > built, I upload a new version of Heimdal with kerberos4kth re-enabled. > Althought this will break at least on other package while Heimdal > doesn't have kerberos4 support (arla), it shouldn't be for long. > > I was hoping that this could be bypassed though, by telling the > autobuilders to initially resolve the dependancy for heimdal when > building kerberos4tkth from non-us/testing. > > Is this possible? > > Any comments? A pox on circular build-depends (says one of the new-port builders). The best way to resolve such things, without resorting to trying to trick the autobuilders, is to try to get the porters to rebuild it manually. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: O: gnu-standards -- GNU coding standards
On Tue, Apr 09, 2002 at 08:45:03AM -0500, Steve Langasek wrote: > On Tue, Apr 09, 2002 at 12:12:41AM -0500, Jeff Licquia wrote: > > On Mon, 2002-04-08 at 20:53, Branden Robinson wrote: > > > Why should the DFSG have to worry about such philosophical questions? > > > Why isn't it enough to worry about the license? > > > Because software isn't documentation? > > > Think of it this way: national security would be so much easier to > > maintain if we could just define cryptography as a weapon of war, > > equivalent to a nuclear device, "for the purposes of the import > > regulations". We all know how well that worked. > > > Similarly, it would be a lot easier to just define documentation to be > > software "for the purposes of the DFSG". But does it make sense? > > The alternative is that documentation will be treated as something we > are enjoined by the Social Contract from distributing at all. Debian > Will Remain 100% Free Software. This may have been poor phrasing on > the part of the authors, but there is *not* a clear consensus that this > is the case; which means that your only remedy is a GR to modify/clarify > the Social Contract and/or the DFSG, and until that happens, no amount > of debate here will prevent packages from being bounced out of main if > their documentation licenses do not meet the DFSG. You know, I keep hearing this. Does this mean we should ditch the entirety of GCC's manuals, even old ones which weren't under the FDL, since the FSF has *clearly* indicated that *they* do not consider them to by software, since they created a *separate license* solely for documentation - which means that for their intent, documentation != software, and thus, Debian should respect that and not publish it, since it's not software at all? -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
