Plan to package xscavenger
Hello all! I intend to package xscavenger, a lode runner like game (remember the good old commodore 64 days?). To be honest, I already did. I also contacted the author, and we work together on a new upstream release. The whole thing is GPL, and it includes a level editor and some dozen levels, sound and nice animations. Oh, you can create own animations, too. However, there is an issue with the sound server. It was taken from koules, and Hubicka took it from xgalaga. I will check this soon. As soon I become registered as a developer, I will upload my package. Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Plan to package xscavenger
On Sun, Dec 14, 1997 at 10:32:51PM +0100, Remco Blaakmeer wrote: > On Sun, 14 Dec 1997, Marcus Brinkmann wrote: > > > > > Hello all! > > > > I intend to package xscavenger, a lode runner like game (remember the good > > old commodore 64 days?). > > > AFAIK, we already have a xscavenger package, which is maintained by Adrian > Bridgett <[EMAIL PROTECTED]> . This is fun, I first installed a local version of my package, which is version 1.3.1-2 by now, because I cleaned the sources. It gives only 5 warnings compiled with -Wall, the orig source gave me a few hundred. Adrian: Please take a look at my homepage: http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/scavenger.html You can find version 1.3.1 there, which will soon become the new upstream version, I discuss the last things with the author (did you ever mail him? He didn't know that there exist a debina packet of scavenger). Seems that I am a few days to late, I will look for another task... Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Plan to package xscavenger
On Mon, Dec 15, 1997 at 12:20:10AM +0100, Marcus Brinkmann wrote: > On Sun, Dec 14, 1997 at 10:32:51PM +0100, Remco Blaakmeer wrote: > > On Sun, 14 Dec 1997, Marcus Brinkmann wrote: > > > > > > > > Hello all! > > > > > > I intend to package xscavenger, a lode runner like game (remember the good > > > old commodore 64 days?). > > > > > AFAIK, we already have a xscavenger package, which is maintained by Adrian > > Bridgett <[EMAIL PROTECTED]> . > > This is fun, I first installed a local version of my package, which is > version 1.3.1-2 by now, because I cleaned the sources. It gives only 5 > warnings compiled with -Wall, the orig source gave me a few hundred. ... and therefore dselect didn't show me the xscavenger package 1.3-1 from adrian. Sorry for that. Can one specify local/games to prevent this? Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FUN USE AND INSTALL DIRECTLY ON X WINDOW
On Sun, Dec 14, 1997 at 11:53:07PM +0100, TABLEAU wrote: > Hi > > I use debian 1,3,1. > > for the future version de debian, it's possible in french ? Maybe. Some people are working on internationalization and localization. However, it is a big task. If you want to help, mail to debian-i18n@lists.debian.org and [EMAIL PROTECTED] > it's possible to mask the password? ( all ) If you mean shadow passwords, then use "shadowconfig on". > Why debian it's not installed directly with X Window ? Because some people have computers, that can not run Xwindows or they simple don't want it because it is too slow. Debian will have an install tool (deity), that supports console and X, but it is not released yet. > X+ > > Excuse for my english, it's not correct No problem. Please use for further questions the debian user list, [EMAIL PROTECTED] You can subscribe with "subscribe" in the body of a mail to [EMAIL PROTECTED] Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Plan to package xscavenger
On Mon, Dec 15, 1997 at 06:46:20PM +, Adrian Bridgett wrote: > On Mon, Dec 15, 1997 at 12:20:10AM +0100, Marcus Brinkmann wrote: > > On Sun, Dec 14, 1997 at 10:32:51PM +0100, Remco Blaakmeer wrote: > > > On Sun, 14 Dec 1997, Marcus Brinkmann wrote: > > > > I intend to package xscavenger, a lode runner like game (remember the > > > > good > > > > old commodore 64 days?). > > > > > > > AFAIK, we already have a xscavenger package, which is maintained by Adrian > > > Bridgett <[EMAIL PROTECTED]> . > > > > This is fun, I first installed a local version of my package, which is > > version 1.3.1-2 by now, because I cleaned the sources. It gives only 5 > > warnings compiled with -Wall, the orig source gave me a few hundred. > > I didn't really watch the compile when I made the package, but it seemed > like it went okay - I havn't noticed any problems. I'm using all the latest > stuff I think. No real problems, just warnings, most because of missing prototypes. > > Adrian: Please take a look at my homepage: > > http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/scavenger.html > > > > You can find version 1.3.1 there, which will soon become the new upstream > > version, I discuss the last things with the author (did you ever mail him? > > He didn't know that there exist a debina packet of scavenger). > > > > Seems that I am a few days to late, I will look for another task... > > I just packaged it - since you seem keen on fixing/upgrading it etc, it > would make sense for you to maintain it. I don't really have the time or > inclination to do any actual coding (I hate C :-)) I don't want to steal you a package, but if you offer it, I will take it over. It would be a good starting point, because it is so easy and I can learn a lot about packaging and programming. Another thing that bothers me is the copyright. Are there good reasons to place it in non-free? I think there is, because it uses the sound code from koules, which uses the sound code from xgalaga, which is shareware/a mix of different files. I will probably resolve this soon. Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Plan to package xscavenger
On Sun, 14 Dec 1997, Adrian Bridgett wrote: > On Sun, Dec 14, 1997 at 03:34:34PM +0100, Marcus Brinkmann wrote: > > > > Hello all! > > > > I intend to package xscavenger, a lode runner like game (remember the good > > old commodore 64 days?). > > > > To be honest, I already did. I also contacted the author, and we work > > together on a new upstream release. > > > > The whole thing is GPL, and it includes a level editor and some dozen > > levels, sound and nice animations. Oh, you can create own animations, too. > > > > However, there is an issue with the sound server. It was taken from koules, > > and Hubicka took it from xgalaga. I will check this soon. > > > > As soon I become registered as a developer, I will upload my package. > > I've already packaged version 1.3 - it's in hamm. I changed the locations of > the files to fit in with Debian and changed things so that everything is > called xscavenger rather than half being xscavenger and half being scavenger. Ok, perhaps this is a good idea. > I wasn't aware of the sound server problem as the README said it was GPLed. Yes, I found it by fortune. sound.c says "see copyright.h", but copyright.h doesn't exist. :-( Dave said he took sound from koules, so I asked koules maintainer. He said he took it from xgalaga *arrg* > You certainly welcome to take maintainership. If you have a look at > debian/dists/unstable/main/source/games/ > their should be a file called "xscavenger-1.3-1_i386.diff.gz (or something > like that) which has all the changes I made to it - you should keep the > changelog file, but the rest can be changed. I already have it ;) And I will incorporate your changelog in my, means I start from scratch. > PS: You wouldn't know how to do level 13 would you - I'm stuck and I can't > think of any other possible combinations I can do :-) There is no way to > get back inside the yang-yang once you have gone outside it AFAIK, and when > I get the bottom lot of gems, the man kills me as he is right behind me :-( The same level I'm stuck :( 1) You have to wait. The enemy will be trapped and you can walk over him. collect all games at the top in the ring. Then you stand upon the enemy and dig a hole beside him (left or right). But then you can just drop down, and the enemy is faster than you can jump on the floor inside the ring. There I don't know further. I should ask Dave about it. You can even walk on the enemyys head, and so you can catch the ladder group in the upper right. Tell me if you did more than I. Thank you, Marcus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can I take wml and eperl?
On Mon, Dec 22, 1997 at 01:10:17AM -0700, Anthony Fok wrote: > On Sun, 21 Dec 1997, Tommi Virtanen wrote: > > > PS. Currently wml includes eperl, iselect, > > weblint, m4, txt2html etc. I intend to split > > these (atleast the bigger ones) to separate > > packages, and make wml depend on them. See > > /usr/doc/wml/COPYRIGHT.OTHER. No reason to > > have eperl or m4 installed twice.. But that > > cames *after* getting a working version out. > > I am ambivalent on this one. Currently, the installed size of WML is only > 1990 KB, i.e. less than 2 MB. Basically, the ePerl, m4, etc. included in > WML are somewhat stripped down already (i.e. no example files, just the > executables and the manpages). It might not worth the trouble to split up > the package. Sorry, do you mean that wml contains copies of m4, eperl, txt2html and other? If this is the case, they should be removed IMHO and wml should depend on the debian packages. 2 MB to download takes 20 minutes for me and costs a few buckets. I think if it is easy possible, it should be done, because it reduces bandwidth. (Note that I don't know if the executables provide the same functionality, I'm just guessing). (On the other hand, we could link all executables statically, because they would be smaller then 2 MB in most cases >:-] Merry christmess, Mrcs (whr r my vwls ?) -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can I take wml and eperl?
On Mon, Dec 22, 1997 at 06:54:08PM -0700, Anthony Fok wrote: > On Mon, 22 Dec 1997, Marcus Brinkmann wrote: > > > Sorry, do you mean that wml contains copies of m4, eperl, txt2html and > > other? If this is the case, they should be removed IMHO and wml should > > depend on the debian packages. 2 MB to download takes 20 minutes for me and > > costs a few buckets. > > 2 MB is the installed size, i.e. the space that it takes on your > hard drive after unpacking. :) The .deb was about 700 KB? It is even shorter, ok... (but it could be even even shorter ;) Installed size: 1.2 MB I got a little hot, because I have only 50MB left on my disk... > > I think if it is easy possible, it should be done, because it reduces > > bandwidth. (Note that I don't know if the executables provide the same > > functionality, I'm just guessing). > > Christian and Tommi have already convinced me to do so. :) Hehe. BTW, I > am only doing non-maintainer uploads. Tommi will probably take over > eventually, once he gets his Debian developer status, that is. i am waiting, too. Hey, I didn't want to flame you. I just wanted to throw my 2 cents in... > The latest wml .deb depends on m4 and eperl. More dependencies and > symlinks will come when we finish packaging other components for Debian. > This, for sure, is the Right Thing (TM). :-) > Merry Christmas to you too! :) ...and a Happy New Year! Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: next release ?
On Sun, Dec 28, 1997 at 02:08:00AM -0300, Nicolás Lichtmaier wrote: > > when will be the next release ? > > I think that no less than 2 months. > > But.. you may install hamm now from ftp://ftp.debian.org/debian/hamm/hamm/! > > It's fairly stable for general use. Be sure to read the howto http://www.gate.net/~storm/FAQ/libc5-libc6-Mini-HOWTO.html before! thank you, Marcus who is "up dp hamm" for quite a few weeks now (GIMP is cool!) -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: my user on my box!
On Sun, Dec 28, 1997 at 10:14:43AM -0800, Jon Björklund wrote: > Hi there guys! > > I am using Debian 1.3.1 and finds it a perfekt linuxdistribution. > But there is one _very_ BiG problem in all unices I have tested, > and that is the users and root. > What I want is to get my user named ceed to be as powerful as root but > at the same time it shouldn't be root. Is there a way of fixing this?? > And I do not want to go around su:ing all my day. As other mentioned on this list, this is no problem or bug, but a feature. Their should be absolutly no reason to have root access all the time (do you know one?) I assume you have a stand alone machine, and you are the only user. Then I would recommend you to keep the first console for root. Then you can login as ceed on other consoles, and switch back to your root console via ALT-F1. This is what I do, and you will experience, that you don't need too much root access. If you want to give ceed access to floppy, cd, sound and other, add "ceed" at the end of the appropriate lines in your /etc/group file. This file controls the access for common files and devices. > And finally can you pleaze give me a small description of what each > user in the original /etc/passwd is! This "users" are no real users, this means, you can't login as, for example "news" (they have an asterisk * as password). They are for system maintenance, and special system programs, as daemons, can run as "news", for example, so they don't have to run as root for special tasks (the news daemon only needs access to news specific files, and not to the usr directory, for example). This somewhat complicated mechanism does protect the system against you and you against the system ;) Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Intend to package gtk-- ...
Hello! I plan to package gtk--, a C++ wrapper for Gtk, the famous set of widgets behind The GIMP, as everybody (should) know... at least, if there isn't anybody who is more knowledgable. As soon I have it ready, I would put it on my personal web site and announce it, because I'm not acknowledged as developer (yet, should be soon). As this would be my second package (my first is xscavenger, which already existed and which I have taken over now ;), and my first one containing shared libs, I will surely come back to you with a lot of questions ;) About gtk-- (a pretty ugly name for a debian package). It is version 0.6.3 by now, and does a Good Thing it seems: It provides an OO interface to Gtk. As you probably know, Gtk itself is OO'ed, but implemented in C, so the idea is not too far, isn't it? Some features: * typesafe callback support * classes use the neat C++ syntax, derivation from classes, overriding virtual methods with C++ syntax There are a lot of misfeatures 'though: lack of documentation, gdk not fully supported yet, many others... see http://www.iki.fi/terop/gtk/gtk--.html for more information. Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Financial support
On Thu, Jan 01, 1998 at 04:54:29PM -0800, Jim Pick wrote: > > Look for an updated dwww package and a new "kaffe+kore" package this week Yuhuu! Is it the version with the "big step forward", you promised some time ago? It would be nice if dwww could evolve to the main debian documentation center it is supposed to be, as we have policy that preferred doc format is html, havn't we? > from me. Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
autmake & debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 03:02:38PM +0100, Christian Schwarz wrote: > On Tue, 6 Jan 1998, Hamish Moffatt wrote: > > Thus, the use of debstd is depreciated. Note, that I've removed debstd > from all of my packages lately and would like to see others doing the same > thing. As soon as we have the macro-utility (was it called automake?) set > up, we should consider removing debstd. Isn't automake the GNU program for using with autoconf ? automake creates Makefile.in's out of Makefile.am's. The Makefile.in's will be processed by configure (which itself is created by autoconf out of configure.in) to Makefiles. Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake & debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 08:08:51PM +0100, Christian Schwarz wrote:
> On Mon, 5 Jan 1998, Marcus Brinkmann wrote:
>
> > Automake does support the GNU standard, a less restrict one, and (perhaps)
> > the gnits standard (the new GNU standard). Will there be automake support
> > for Debian packages ?
>
> (BTW, the discussion about this was in mid Oct 97.)
(Ok, perhaps I will look in the archive. I certainly wasn't ready for this
technical topic at that time ;)
> The idea is to create the debian/rules file by a macro processor. (Since
> automake is used to create Makefiles and debian/rules is a Makefile,
> someone suggested to use it. However, doubts have been presented that it
> does not fit exactly to our purposes. Someone would have to do some
> experiments on this. If it doesn't fit, we can use or write another macro
> generator.)
Although I'm not able to judge auto{conf,make}'s capabilities, I had the
impression that they are strong tools. It would be nice to have some
general approach like this become standard for debian packages (I imagine
that auto compiling and porting would be easier then).
[...]
> Furthermore, since debian/rules would be generated by the maintainer only,
> everyone else can recompile the package and get the same results. (With
> debstd this is one problem. You need exactly the same debstd version than
> the maintainer had to get the same package.)
I see.
> It would be nice if we could find one (or more) volunteers to do some
> experiments on that issue.
Yes, I think it would be a Good Thing.
Thank you,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux
Marcus Brinkmann http://www.debian.org
[EMAIL PROTECTED]
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: AucTeX
On Thu, Jan 08, 1998 at 03:26:48AM -0900, Britton wrote: > > On 7 Jan 1998, Davide G. M. Salvetti wrote: > > > AucTeX is listed as orphaned in wnpp; I'm willing to take over its > > maintenance if nobody objects. > > I think this might be because teTeX has now replaced AucTeX as the Debian > TeX/LaTeX distribution of choice. Of course TeX/LaTeX is so darn > complicated I'm not really sure about this. Certainly not ;) Tetex is a TeX distribution, but AucTeX is an Emacs mode to write TeX documents more easily ;) > Btw, if you have ever managed > to make dvi files with ps images print right through magicfilter, I would > love to hear how you did it. Is there really a ps2dvi program? Or do you mean the other way round ? Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [?] egcs increases C++ binary size dramatically
On Tue, Apr 07, 1998 at 04:43:31PM +0200, Bernhard Rosenkraenzer wrote:
> On Mon, 6 Apr 1998, Dirk Eddelbuettel wrote:
>
> > I did not change any configuration options. I compiled the older package
> > with
> > the latest GNU gcc/g++ 2.7.*, and the new one with egcc/eg++. xpdf makes
> > quite heavy use of C++, but as it worked with GNU g++ for years, I think we
> > can exclude templates, exceptions, ... And yes, the new one is stripped as
> > well.
> >
> > Isn't the size increase a bit much ? Comments ?
>
> It's related to the fact that egcs does exception handling - add
> -fno-exceptions to your CFLAGS, and you'll get a shorter binary.
I think this is not the right way to think of C++ programming. If you don't
use exceptions, you are free to disable them, but they are really an
integrated feature in the standard. GNU g++ had poorly to none exception
handling, egcs does a better job here, but maybe it is not optimized for
size yet.
However, you can give the compiler a hint that a function does not throw any
exceptions by adding throw() at the right place:
class ABC {
ABC (int theInt) throw();
}
for example. I don't know if egcs does make use of this promise by the
programmer, but it certainly should. Take the bigger binary as a sign that
the C++ support gets better. Maybe the size will go down again if it gets
again far more better.
Marcus
--
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@
Marcus Brinkmann http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [?] egcs increases C++ binary size dramatically
On Tue, Apr 07, 1998 at 11:14:17PM +, Falk Hueffner wrote:
> It seems that programs are larger even if they do not use exceptions
> at all (possibly even C programs). For those, it seems totally
> resonable to disable exceptions. It should probably even added to the
> policy, since it saves space.
Well, the rule is that every possible exception will be thrown that could be
thrown in the function ("assume the worst"). You have to declare the thrown
exceptions explicitely if you want to restrict the list (which does make
sense, doesn't it?).
C programs should be compiled with a C compiler.
Exception handling is broken enough yet. Please don't make it even more
unsafe by disabling it in some parts of the programming environment.
Note that by ANSI C++ even the new operator may throw an exception ( bad_alloc()
), and this operator is used in nearly every C++ program. For compatibility
with C functions, you can disable this with new(nothrow).
Hoever, I thought about what I said: I don't think that the program will be
smaller when the exceptions are declared, but some compile-time checking can
be done.
Note that the saving of space is misleading: Notably, a C++ program that
uses exceptions for error handling instead convential methods can even be
smaller, and the source code is *much* cleaner and shorter. It is not
uncommon to have half of the code provided for error handling. With
exceptions, this shrinks down significant. So, the bigger size is more a
sign of unefficient C++ programming style. Only to use exceptions in a few
places and use other global error handling strategies most of the time is
IMHO unnecessary.
Marcus
who prefers safety over brevity.
--
"Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@
Marcus Brinkmann http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [?] egcs increases C++ binary size dramatically
On Wed, Apr 08, 1998 at 02:58:39PM +0300, Amos Shapira wrote:
> On Wed, Apr 08, 1998 at 01:01:46AM +0200, Marcus Brinkmann wrote:
> > However, you can give the compiler a hint that a function does not throw any
> > exceptions by adding throw() at the right place:
> >
> > class ABC {
> > ABC (int theInt) throw();
> > }
>
> Shouldn't the compiler still handle eceptions in functions which call
> functions which throw exceptions?
The compiler will abort() if an exception is not caught. I don't know if the
exception handling code is in the function that calls or in the function
that is called. Note that I'm not at all sure if the above code will lead to
shorter code, as it is mostly for compile-time checking etc. Violations
against the above declaration are possible and in large complex programs
unavoidable.
> If so, this probably means that you should have exceptions handled in
> any binary which uses a function which throws exceptions (e.g. almost
> any STL container).
Exception handling is a powerful feature, and makes other global error
strategies mostly unnecessary. Therefore the size of compiled and well
written C++ programs will not be larger than an equivalent C program. *And*
the source code will be much cleaner, as you don't have to nest if()
statements or such things.
Voting for Exceptions,
Marcus
--
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@
Marcus Brinkmann http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [?] egcs increases C++ binary size dramatically
On Thu, Apr 09, 1998 at 05:15:59PM -0600, Jason Gunthorpe wrote: > > On Thu, 9 Apr 1998, Marcus Brinkmann wrote: > > > Exception handling is a powerful feature, and makes other global error > > strategies mostly unnecessary. Therefore the size of compiled and well > > written C++ programs will not be larger than an equivalent C program. *And* > > the source code will be much cleaner, as you don't have to nest if() > > statements or such things. > > Actually egcs just has a gross implementation of exceptions, the overhead > added for the stack unwinding is horribly high, I have't looked too deeply > but it may be a fixed overhead per-function and then some added stuff > depending on the function's content so if you have lots of small functions > you get burned really badly. This is a problem of egcs (gcc). C++ on Linux *is* horrible at the moment. But this does not say anything about the language feature in the standard and how it *could* be implemented. Not using exceptions is curing the symptoms but not the disease. > As I said before, the exception handling information doubles the size of > my binaries (+100k, + 240k, etc) which is pretty bad. I still think that without using exception handling you have to write error handling code by yourself. If you do it good, you double the size of your program either way (approx. 50% of C code is error handling, when the programmer cares about erro handling, esp. in large projects). Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Thu, Apr 09, 1998 at 01:09:39PM -0400, Raul Miller wrote: > Brian White <[EMAIL PROTECTED]> wrote: > > The subject in question is whether to include these packages in "stable". > > "unstable" will include them for sure. > > I think they are appropriate for "stable" provided they are classifed > as "Extra". That is what the "Extra" priority is for, after all. I happen to agree. And we also need a 2.1.x Kernel package. Brian, here in Germany, every Megabyte you have to download is costing real money. A lot of money. Please put as much on the CD as possible. Declare it extra, put it in an unstable dir, put warnings all over the place, but please include it. We already exclude non-free comlpetely for good reasons, no question. But why should we exclude free software, even if it is not production ready. I understand your concern, you want a stable Debian main Distribution. But for special hardware, you need some components. Those you can find in Extra. Some of these components could be a Kernel 2.1.x snapshot. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Thu, Apr 09, 1998 at 05:27:14PM -0400, Brian White wrote: > > Brian, here in Germany, every Megabyte you have to download is costing real > > money. A lot of money. Please put as much on the CD as possible. Declare it > > extra, put it in an unstable dir, put warnings all over the place, but > > please include it. > > > > We already exclude non-free comlpetely for good reasons, no question. But > > why should we exclude free software, even if it is not production ready. > > > > I understand your concern, you want a stable Debian main Distribution. But > > for special hardware, you need some components. Those you can find in Extra. > > Some of these components could be a Kernel 2.1.x snapshot. > > Good reasons, all of them. Do you know the answer to the second question I > posed? > > > What do you figure to be the number of people who will want to use these > > utilities with a 2.1 kernel that do _not_ have any sort of internet > > access? You mean this, don't you: > > Also, how likely are the current versions of these programs > > to work with future versions of the unstable 2.1 kernel and the 2.2 > > kernel that will eventually come from it? True enough. But a Debian 2.1.x package and packages that works with it could be good for seeing and trying out. So you know what debian packages there are and what they provide before you even switch on your modem. OTOH, we don't have a kernel-source package for hamm. So you have made your point, as I have made mine. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
On Thu, Apr 09, 1998 at 03:56:08PM -0500, Manoj Srivastava wrote: > > I think the right thing to do is to leave the default prompts > alone, and teach people how to set up prompts. There is no way you > can cater to all tastes and all shells, people invariably change > them, and anyway, we should make it easy for people to change > prompts. True! > The defaults are functional, though not pretty. No one can > agree on what is pretty. I think users should be allowed to make > their own choices. > > I append my personal prompt setting scheme, in hopes this > inspires someone else (any improvements greatly appreciated) Manoj, have you considerd autoconf support for this beast ;) Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Sat, Apr 11, 1998 at 01:16:19PM -0400, Brian White wrote: > > > > Also, how likely are the current versions of these programs > > > > to work with future versions of the unstable 2.1 kernel and the 2.2 > > > > kernel that will eventually come from it? > > > > True enough. But a Debian 2.1.x package and packages that works with it > > could be good for seeing and trying out. So you know what debian packages > > there are and what they provide before you even switch on your modem. > > > > OTOH, we don't have a kernel-source package for hamm. > > > > So you have made your point, as I have made mine. > > Okay, how about this... > > 2.1 kernel-requiring stuff (and a current 2.1 kernel?) can be included > under "contrib". This keeps it out of "main" and puts it into the realm > of "user-beware". (Note: This is not to insinuate that everything in > contrib is dangerous or anything, but just that you should think at least > once before installing it.) I'm not sure how many people think about contrib (I seldom look at the section when installing software, well, I get suspicious if it is non-free), and it doesn't quite meet the definition of contrib (more the spirit of extra), but if you think it is appropriate... IMO it could even go in a not-dselectable directory on the CD, not listed in any package file at all. A developer would know where to look, and it could be mentioned in a readme.new-kernel. > Acceptable? Sure. My only interest is that a 2.1.x kernel is on the CD ;) And I would not start fighting around for it... Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Sat, Apr 11, 1998 at 03:18:46PM -0400, Brian White wrote: > > I was thinking "project/experimental" would be better, but I don't think > that goes out on many CDs. >From a logical point of view, I think project/experimental is the best choice. Why don't we include selected directories from there on the official CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)? Great idea Brian, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies_2.0.4 (source i386) uploaded
On Sun, Apr 12, 1998 at 02:22:55AM +0100, Enrique Zanardi wrote: > Another weekend, another set of boot floppies ready to be tested. > And this one fixes some nasty bugs, like the "Can't resolve the NFS > server name" bug, or the "Install program restarts after installing base" > bug. I haven't had time to include pkgsel, but will try to do it in a few > days. And now, give those little * a hard testing time! :-) GRR. Just after downloading the "current" ones :-/ Will give them a try, thanks for your work Enrique! Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [conradp@cse.unsw.EDU.AU: ANNOUNCE: Express (web browser) released]
On Thu, Feb 12, 1998 at 10:43:49PM +0100, Martin Schulze wrote: > I wonder if we should give it a try. > > Regards, > > Joey I hope all people will eat the mozilla source now. It should be possible to cut it down for smaller projects. I feel that if mozilla would be incorporated in Gnome, we would have something similar to Win98. > -Forwarded message from "K." <[EMAIL PROTECTED]>- > > Express is (yet another) web browser using GTK, and is intended for > general Gnome consumption. It uses the gtk-XmHTML widget, so make sure > that is installed before trying to use it. > > Source and screenshots are available at: > > http://www.cse.unsw.edu.au/~conradp/express/ [...] -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Mon, Apr 13, 1998 at 12:19:03PM +0200, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Sat, 11 Apr 1998, Marcus Brinkmann wrote: > > > Why don't we include selected directories from there on the official > > CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)? > > gettext is in experimental so that it will *not* be included in CDs... > > If we start putting experimental things in CDs, then we should create > another distribution "really-experimental", since experimental > seems not to be "safe" enough... Dear Santiago, I though I did express clearly, that I don't want to have such software as mentioned above distributed *as part of the main distribution*. I just think that it is a good idea to put as much free software on the CD as possible. expermintal software could be included in a directory, that can't be accessed through dselect. This would make it easy for developers or other interested people to get the software, without having the risk that newbies could install experimental software by mistaken. Remember that some people have to pay a lot of money for the downloading time. gettext for example is a huge package that is needed to develope i18n software. i18n is a stated goal of Debian. This is only an example. A 2.1.x kernel tree is also an example. I can download patches, but the whole kernel is costing me real money, and I'm just a student. Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Mon, Apr 13, 1998 at 04:50:05PM +0200, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > Hi. > > Marcus, I was just clarifying (once more) the status of gettext in Debian. > > It is in experimental because the author asked me not to distribute it > "widely". This means that even if it is not accesable by dselect, we > should not put it on CDs yet. I know that, although I don't understand that at all. IMO this policy is just standing in the way of translating, etc. We could have all bash scripts i18n'ed by now, as bash supports this since a long time. But you need gettext to use this feature. We all know how important spreading a program is. We should honour the wishes of the author, but nevertheless downloading it costs me real money, and getting it on CD has the very same effect as putting it on ftp. > If a package being in "experimental" does not implicitly mean "not to be > distributed in CDs", then we would need definitely another different > "experimental" for gettext. Maybe non-free/experimental? Sorry for the shot. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test Report (was: Re: boot-floppies_2.0.4 (source i386) uploaded)
On Tue, Apr 14, 1998 at 11:59:18AM +0100, Enrique Zanardi wrote: > On Mon, Apr 13, 1998 at 05:16:54AM +0200, Marcus Brinkmann wrote: > > >2) irritating: When installing from a (not yet mounted) hard disk partition > > > and entering the path to the main distribution, the > > > following > > > message appeared: > > > " /usr/lib/dpk//methods/disk/setup: line 8: 200 Broken Pipe > > > find "$mountpoint$2" -follow -name '*.deb' -print 2> > > > /dev/null > > > 201 Done | head -1 > > > 201 Done | grep . > /dev/null" > > > But all worked fine. > > You meant when using "dselect"? Perhaps you should file a bug report > against dpkg. Well, I only encountered this once (yes, this was using dselect), and as I may not be able to reproduce this, it could be useless to file a bug. I may do it anyway. > > >3) bad: Still perl problems. Not with libnet, but dpkg-perl depends on > > >perl. > > >So I got error message after "install", switched to console, > > >manually mounted partition with debian-image, manually installed > > >perl, and then "configured". After this, "install" worked again. > > dpkg-perl should depend on perl-base, as there's no perl but perl-base > in the base system and dpkg-perl works with perl-base. > I have filed a bug against perl-base, and I've seen it has another > long-standing packaging bug, so I guess its maintainer (Klee Dienes) is > really busy these days. Does anyone has the time to do a non-maintainer > upload? Klee is really *busy*. He didn't respond to some mail about koules (another, but very unimportant) package. I did a nmr of koules, and still didn't hear anything. Do you have filed a bug against dpkg-perl, too? (As you say you filed one against perl-base?). > > >After running kbdconfig manually, basis layouot was okay, but I > > >couldn't enter german keys. I think this is because /etc/inputrc > > > has > > >"set convert-meta off" commented out. I think it should be the > > >default. > > In fact that was the default for a few libreadline*.deb versions, because > we wanted Debian to be latin1-compatible "out of the box", but Guy Maor > (readline maintainer) changed it back because leaving it "on" broke "META-x" > handling, and there were a few bug reports about that. (Guy also removed some > definitions that made the Home, End and Delete keys work). I guess it's time > (again) to discuss which should be the defaults. Perhaps asking the user at > installation/upgrade time. This setting does not need to change (well, we need a real keyboard setup sometime, but this can wait). As I wrote below, the real problem was LC_ALL, not convert-meta (as I found out later). > > > After removing the "#", and therefore switching off > > >meta-convert, I still had problems, because the wrong font was > > >loaded. Editing /etc/kbd/config didn't help (what use has this file > > >anyway). I'm not sure what actions should be taken here. > > > > I tracked this down to a missing LC_ALL="de_DE" for bash in /etc/profile. > > Coudl we implement something along this (for several shells e.g.) in the > > boot disks? With the correct keymap the locale setting should probably > > set, too. > > May be. Is it OK to modify /etc/profile at install time? (/etc/profile is > a conffile of libreadline). I can hear the sound of the mythical can of > worms opening... I did hear something about /etc/envronment, but I'm not sure what purpose it has and if it works for all shells, etc. Well, I hope it is okay to change /etc/profile, as it is *very* annoying for non-english users (esp. first time user) to have to guess keys (and not knowing how to fix this). Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [gtk-list] ANNOUNCE: GTK+ 1.0.0 Released!
On Mon, Apr 13, 1998 at 09:32:22PM -0800, Ben Gertzfield wrote: > Debian packages for Debian 2.0/i386 have been uploaded to the master > Debian FTP archive and ftp.gimp.org. > > GTK+ 1.0.0 will officially be a part of Debian 2.0, due to be released > in a few weeks. Did the interface change (e.g. do we need to upload new versions of related packages) ? Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [gtk-list] ANNOUNCE: GTK+ 1.0.0 Released!
On Tue, Apr 14, 1998 at 05:32:17PM -0800, Ben Gertzfield wrote: > >>>>> "Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > Marcus> Did the interface change (e.g. do we need to upload new > Marcus> versions of related packages) ? > > No, the API has not changed since 0.99.4. There are still some packages > using the old API though, I believe. Well, the last gtk-- version 0.7.18 worked for gtk since 0.99.7 I believe so I hope the author will release a new version if necessary. We still have a lot of time till release (alsa!). Thank you, Marcus > > -- > Brought to you by the letters V and N and the number 6. > "I'm with insurance." -- 12 Monkeys > Ben Gertzfield <http://www.imsa.edu/~wilwonka/> Finger me for my public > PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Thu, Apr 16, 1998 at 07:37:20PM +0200, Santiago Vila wrote: > > > > If a package being in "experimental" does not implicitly mean "not to be > > > distributed in CDs", then we would need definitely another different > > > "experimental" for gettext. > > > > I'm not sure whether or not "experimental" is appropriate for gettext, then. > > I'm sure experimental is appropriate for gettext, as long as we all are > sure that experimental is not appropriate to be put in CDs. Is gettext so unstable? I doubt it. If it is only in experimental because the upstream author expressed his wish not to distribute it widely, I consider this as an abuse of experimental/. > > Perhaps including project/experimental isn't such a good idea > > after all. > > I agree. I do not. I think the whole thing about free software is to spread it. Probably not on the binary CD, but what about the source CD, which is mainly interesting for developers. I hope some vendors will be kind enough to be not so picky. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dictd and wordnet
On Thu, Apr 16, 1998 at 09:05:12AM +0200, Andreas Tille wrote: > On Wed, 15 Apr 1998, Bob Hilliard wrote: > serious package (I don't consider xteddy to be serious but only for the > sake of learning maintaining a package). I blame you for that. How can you take xteddy not serious? We need it. Everyone needs a teddy. This is human psychology. Could you make xteddy pop up at kernel oops? ;) Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Fri, Apr 17, 1998 at 01:07:34AM -0500, Manoj Srivastava wrote: > Hi, > >>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > Marcus> Is gettext so unstable? I doubt it. > > Dpes not matter. We should be respecting the upstream authors > wishes. Already Debian has the reputation of not forwarding bugs > upstream; I do not want to add to that a report that we flagrantly > ignore express requests by the authours. Sure, I honour the wish of the upstream author. I don't know how our reputation is. > Marcus> If it is only in experimental because the upstream author > Marcus> expressed his wish not to distribute it widely, I consider > Marcus> this as an abuse of experimental/. > > Fine. Create a nerw heirarchy that like > not-to-be-widely-distributed-use-at-your-own-risk-do-not-put-on-cd > and put it in there. What purpose would this distinction serve? > > Marcus> I do not. I think the whole thing about free software is to > Marcus> spread it. > > When it is ready. Early shipping is a major source of > potential mebarrasement, and may alienate users. If the authors > themselves consider it unfit for general consumtion, are we not being > presumtuous in saying we know the software better than the authors? > > Marcus> Probably not on the binary CD, but what about the source CD, > Marcus> which is mainly interesting for developers. I hope some > Marcus> vendors will be kind enough to be not so picky. > > It should not be a part of the Official CD, in my opinion, > until the author gives an OK. I do not ask for it (again). I just hope that somebody is keen enough to put it on CD (*not* on the official CD), to save me *money* that I can spend better than on the telephon company (in good books for example, to learn programming and help with gettext). IMHO opinion, the upstream author is only hurting himself, but his MMV. Marcus done with Debian i18n (not the group, btw, they are trying to swim against the stream, which I find brave). -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Boot Disks and Adaptec 2940
Hello! I recently crashed the root partition of a hamm station. Fixing it, I installed several packages, also kernel-image package. The system was not able to boot anymore. Trying to come into the system, I tried Debian 1.3 boot disks and some newer disks (20-2, 20-3?). All disks hang after detecting Adaptec aic7xxx scsi devices, with or without aic7xxx=no_reset. I don't remember how I was able to boot from CD and install hamm (had problems then, but I was able to do it), but obviously the disks are/were not working with the current system (we installed a few more cards and a SCSI CDROM Writer after installing Linux). The system is a SCSI only, two 4GB disks, one CD ROM reader and one CD ROM writer. Adaptec 2940 AU controller. Well, the solution was to compile a new kernel on a different system to be able to boot in the system. As Adaptec Cards are common in Germany, this should be fixed (if at all possible). I can try fresh boot disks, but not before thursday. Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Image names "rescue" and "default" was: Re: April 11th bootdisks - major failure
On Sat, Apr 18, 1998 at 11:02:51PM -0400, Gregory S. Stark wrote: > > I rebooted with the rescue disk and tried to use the rescue image but got > something to the effect that there was no such image. When I used the regular > image and ran fdisk and saved the partition table from there it was ok. Enrique, could you *please* fix the help screens? They say you should boot "default options=value" and "rescue options=value", but they are not there! I had to use "linux" in all cases, and it took me quite a while to figure it out. (What is the status of adaptec 2940 support, btw? Older boot disks hang during boot...) Thank you, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Image names "rescue" and "default" was: Re: April 11th bootdisks - major failure
On Sun, Apr 19, 1998 at 07:13:32PM +0100, Enrique Zanardi wrote: > On Sun, Apr 19, 1998 at 02:03:26PM +0200, Marcus Brinkmann wrote: > > > > Enrique, could you *please* fix the help screens? They say you should boot > > "default options=value" and "rescue options=value", but they are not there! > > I had to use "linux" in all cases, and it took me quite a while to figure it > > out. > > The wierd thing is that rescue _is_ there: Oh, well. You are right. This is really weird. > syslinux.cfg: [snipped] > It worked fine with older versions of syslinux, and now it doesn't work, > although /usr/doc/syslinux/syslinux.doc.gz says nothing about changing > the syntax of this file. Don't you love this kind of bugs? Yeah, I like them exceptionally much. And you can debug them *soo* easy... Hopefully the syslinux maintainer knows more... > > (What is the status of adaptec 2940 support, btw? Older boot disks hang > > during boot...) > > It seems they still hang. It's a problem with our curren kernel > (kernel-image-2.0.33_2.0.33-6.deb) but as I don't own an adpatec card, I > don't know what to do to fix that. Well, it seems that the probing confuses the drive... I try again, but I think I remember that in the middle of the adaptec driver output, the Western Digital 7000 driver yells that he can't find a drive. I'm not sure if tehy are related. I will probably do some testing, but I don't own a scsi card, too (this machine is in a firm). A not so good hack would be an alternate kernel for Adaptec only. We need this if the issue can't be resolved, or we have to remove the Adaptec driver. This would make installation on a SCSI-only machine impossible, though :-/ > I'm CCing the syslinux and kernel maintainers, to see if they can help. Hopefully they know more. Thank you very much Enrique! Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: > As far as I can tell this license is DFSG-free; please let me know if you > disagree. This is weird, especially because of point 3. He means the right thing, but he doesn't mention modification, redistribution of modificated versions and selling. Please point him kindly to Debian, the dfsg and to a more explicit license we require to put it in main. This would mean, that you point him to Artistic License, GPL, Xfree's and so on. Thank you, Marcus > Copyright (c) 1997-1998 by Armin Biere. > > Author: Armin Biere. > > Permission is granted to anyone to use this software for any > purpose on any computer system, and to redistribute it freely, > subject to the following restrictions: > > 1. The author is not responsible for the consequences of use of >this software, no matter how awful, even if they arise >from defects in it. > > 2. The origin of this software must not be misrepresented, either >by explicit claim or by omission. > > 3. Altered versions must be plainly marked as such, and must not >be misrepresented as being the original software. > > > 4. This notice may not be removed or altered. > > Armin Biere > Thu Mar 5 16:48:52 EST 1998 > -- > J.H.M. Dassen | RUMOUR Believe all you hear. Your world may > [EMAIL PROTECTED] | not be a better one than the one the blocks > | live in but it'll be a sight more vivid. > | - The Hipcrime Vocab by Chad C. Mulligan > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Thu, Apr 23, 1998 at 06:20:21PM +0200, Oliver Elphick wrote: > Marcus Brinkmann wrote: > >On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: > >> As far as I can tell this license is DFSG-free; please let me know if you > >> disagree. > > > >This is weird, especially because of point 3. He means the right thing, but > >he doesn't mention modification, redistribution of modificated versions and > >selling. > > He says anyone can use it for any purpose! That includes everything > you mention. All he's asking is that people say if they have altered > it from his original version. I can't see any problem. I know what he wants to say, and I understand that. However, the word "use" is very well undefined, and I don't know how the court would see it. The general consens seems to be that "use" does not imply everything I said. The "use" of software is probably only running and, well, "using" it. I'm not a lawyer, so this is no legal advice. But I would really recommend you to get a better copyright from the author, especially as he seems to want to share the code. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd : which software does support this ?
On Thu, Apr 23, 1998 at 03:59:18AM +0200, Remco Blaakmeer wrote: > On Thu, 23 Apr 1998, Herbert Xu wrote: > > BTW, about the issue of programs breaking on 50 out of the 100 different > systems they normally run on: can't this be solved by some smart #ifdef's > in the code? I'd think that if you write a patch that adds a good feature > while not breaking other things, most upstream authors will accept it. Sure, if it does not conflict with any of the other 250 #ifdef's you have in to support all 100 operating systems (from zx spectrum [does anyone remember those? I have one, is it valuable?] to Alpha station) ;) Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: less: extra entries for lesspipe
On Thu, Apr 23, 1998 at 12:49:43AM -0700, Darren/Torin/Who Ever... wrote: > -BEGIN PGP SIGNED MESSAGE- > > >This seems like a bad idea. "strings" is not the obvious information > >to provide about an executable. (Consider size, objdump, od, hexdump, > >et cetera). > > Okay. Sounds good to me. I wanted at least one objection though so > that I wasn't just disregarding the user's request out of hand. Please collect flashy examples and provide them with the package, possibly with one line comments. Thsi would make life for newbies easier, for interested people it would be something to get starting with and all the prof's can improve it without caring about defaults ;) Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 21164 must be fixed before 2.0.34 comes out!
On Sat, Apr 25, 1998 at 12:48:39PM +0100, James Troup wrote: > [EMAIL PROTECTED] writes: > > > On Sat, Apr 25, 1998 at 08:25:06AM +0200, [EMAIL PROTECTED] wrote: > > > On Sat, 25 Apr 1998, Herbert Xu wrote: > > > > FWIW, I just tried it on my Debian 2.0 2.0.32 machine: > > > what means FWIW ? > > > > For what it's worth. > > > > Note: there are several useful acronym lists / search systems on the > > web [ ... ] > > and the `jargon' package in doc/ Yes, but FWIW is not part of Jargon atm (4.0.0-3), although someone submitted an entry for FWIW, IIRC ;) FWIW was the worst to find out for myself, it really puzzled me a long time, as non-native english speaker ;) CU, M -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: consistency check
On Sat, Apr 25, 1998 at 06:11:25PM +1000, Anthony Towns wrote: > On Sat, Apr 25, 1998 at 09:26:24AM +0200, [EMAIL PROTECTED] wrote: > > > i am always not sure, wether my system is OK. :) sometimes it might be > > useful to do a new installation (no update) only because then much of the > > old unneeded rubbish is gone. > > *shudder* > > Reboots are for new kernels. And for libc5-libc6 transition ;) Well, I always amnage to crash something when mangeling with svgamode, X and dosemu, I hope ggi will be an integral solution here. > Reinstalls are for new computers. I get your point and Debian is aiming at that (and is doing a pretty good job). I even had success avoiding a reinstall when I crashed the root partition (/etc without backup!). This shows how great Debian is. However, two things come to mind: a) Testing purposes (developers only) and b) Repartitioning (here you have a good chance for a reinstall, because moving the root directories across partitions can be a pain, if you don't know your tools well (/dev and /proc comes to mind)). I still find your two rules of thumb very well said, I'm just a little verbose today and am only chatting ;) Have a nice day, Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Mon, Apr 27, 1998 at 11:34:00AM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Marcus Brinkmann) wrote on 23.04.98 in <[EMAIL > PROTECTED]>: > > > On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: > > > As far as I can tell this license is DFSG-free; please let me know if you > > > disagree. > > > > This is weird, especially because of point 3. > > I can see nothing weird there. I don't remember, you are late... > > He means the right thing, but > > he doesn't mention modification, redistribution of modificated versions and > > selling. > > Huh?! First, not mentioning selling is *good*. Second, he does mention all > the other stuff - to alter == to modify. Don't spread misinformation, please. Did we read the same license? I quote it her for you: Copyright (c) 1997-1998 by Armin Biere. Author: Armin Biere. Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. The author is not responsible for the consequences of use of this software, no matter how awful, even if they arise from defects in it. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. This notice may not be removed or altered. Armin Biere Thu Mar 5 16:48:52 EST 1998 And now my comments: 1) He does not mention that selling is allowed. So you are not allowed to sell it. 2) He does not mention that you are allowed to redistribute the software after altering and marking as in 3, so you are not allowed to redistribute altered version. > > Please point him kindly to Debian, the dfsg and to a more explicit > > license we require to put it in main. This would mean, that you point him to > > Artistic License, GPL, Xfree's and so on. > > Don't. Kai, please think before you post. We both know that the author wants the right thing, but the license is poorly worded and does not tell the right thing to the court. It is better to educate authors who use broken licenses, because they will be happier, too, if they know what is wrong about their license. It is hard to express the right thing in legalese. The license above clearly does not say what the author wants to say. You are reading it in the way the author probably meant it, however, this is insufficient for the Debian distribution. We have to interprete the license the way it is written. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Mon, Apr 27, 1998 at 11:36:00AM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Adrian Bridgett) wrote on 23.04.98 in <[EMAIL PROTECTED]>: > > > On Thu, Apr 23, 1998 at 09:53:54AM +0200, [EMAIL PROTECTED] wrote: > > > As far as I can tell this license is DFSG-free; please let me know if you > > > disagree. > > > > > > > > > Copyright (c) 1997-1998 by Armin Biere. > > > > > > Author: Armin Biere. > > > > > > Permission is granted to anyone to use this software for any > > > purpose on any computer system, and to redistribute it freely, > > ^^ > > Hmmm - which version of free is this - ethically or financially? > > It's quite obviously "without restrictions". As the part of the sentence > you cut out makes clear. It's quite obviously with restrictions, but you have been to eager with cutting: Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: ^ However, it is not as obvious as you want to make us believe. Things that are not explicitely allowed are forbidden. Things that are not spelled out, are not there at all. There is only little room for interpretation of legal texts. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Mon, Apr 27, 1998 at 09:40:33PM -0400, [EMAIL PROTECTED] wrote: > On Tue, 28 Apr 1998, Marcus Brinkmann wrote: > > > And now my comments: > > 1) He does not mention that selling is allowed. So you are not allowed to > > sell it. > > Last time I heard, "redistribute freely" was taken to mean that you were > free to distribute it however you like (including by selling it) Well, I'll not comment further on it, as I'm not a lawyer. If it is so as you said, this is probably not a problem. > > 2) He does not mention that you are allowed to redistribute the software > > after altering and marking as in 3, so you are not allowed to redistribute > > altered version. > > "Altered versions" must be "plainly marked" and "must not be > misrepresented as being the original software". It doesn't make too much > sense to require someone to mark modifications if they can't redistribute > them. I never said that it would make sense, this is the reason why I would suggest the author to choose the license mnore carefully if I had to cope with such a license. I've seen worse licenses, though, and quite a lot that have been more silly. The other comments state the difference in copyright law, if everything is forbidden that is not explicitely allowd or if everything that is not explicitely forbidden is allowed. We have the Bern convention in europe which specifies the former. I don't know about the letter, and would assume the worst to be on the safe side. In general, I prefer to have a license that does not leave any ambiguity or interpretation on my side. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pronouns (was Re: Proposed Constitution)
On Tue, Apr 28, 1998 at 05:02:57PM +0100, Ian Jackson wrote: > This discussion is ridiculous. > > In my view singular `they' is perfectly correct. If I can use it in > my PhD thesis (with a footnote[1] and supporting references, and > without any complaint from the examiners) then we can use it here. > > Furthermore, language is defined by use, not by prescription (try > asking a linguist, rather than a schoolteacher). Singular `they' is > very well accepted practice in this speech community; in the contexts > I have used it it is (I believe) clear, clean and unambiguous. I hope you are well aware of the fact that a lot of people will not understand it, and probably will ask you about it. I can tell you that most german readers may be confused. I don't know about other countries, but I assume the situation is not very different there. > I will not change the current draft, and blustering here will not make > me change my mind. If you're so horribly bothered you'll have to > propose an amendment; I wonder if you could find five sufficiently > anal (and wrong) supporters. Ian, I find your attitude arrogant and egocentric. Your constitution is hard enough to read for non-native speakers, and if you don't want to rule out people that don't have a Ph.D. in Oxford English, you probably want to reconsider your position. I will not make you the favour to propose a change, because I don't have the time for kid games and name calling. I only ask you to have a footnote explaining: If you need it in your Ph.D. to warrant this language, you certainly want it in an internationally used document, too. Remember that Linux as well as Debian is an international project. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pronouns (was Re: Proposed Constitution)
I´m did a little research and nobody here at my university I ask (not too many people, and not represantive, but FWIW) did know this use of "they". I would really appreciate a list of word explanations, as reading english legal texts is hard. I´m willing to learn new stuff, but I hope that Ian can provide such a list. Marcus On Wed, Apr 29, 1998 at 10:37:36PM -0400, Raul Miller wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > I hope you are well aware of the fact that a lot of people will not > > understand it, and probably will ask you about it. I can tell you that most > > german readers may be confused. I don't know about other countries, but I > > assume the situation is not very different there. > > If this is a problem, we could fix it by supplying a short list of > definitions of words which are known problems for people with various > backgrounds. > > -- > Raul -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, Apr 30, 1998 at 04:06:44AM -0500, Manoj Srivastava wrote: > Hi, > >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes: > > I may have over reacted to being the lone voice crying in the > wilderness bit. I prefer to keep away from such discussions until the air cleaned up a bit, but for the sake of the people who count votes here are my 0.02$: I think the policy should be strictly followed. Exceptions to and errors in the policy should be reported as a bug and properly included/fixed. The policy should include a rationale where the reason is not obvious. It should make clear what parts are required (must) and which are common practice (should). I prefer a must over a should. People should not be angry when policy is wrong for them, but they should happily work on the policy. The policy is not something that is forced on the developers by some "higher person", but something the developers force on *themselves*. You can only experience real freedom if you feel the border. In short, I agree with Manoj. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ease of use and configurability
On Thu, Apr 30, 1998 at 03:13:52PM -0500, Branden Robinson wrote: > Am I the only one who feels that, to a large extent, ease of use *is* a > technical problem? In the end no one can beat this ;) > This is a somewhat major proposal and would be a big piece of architecture > if implemented. However it's something I've been kicking around in my head > for months and I haven't yet come up with a good counter-argument. > > I'll also be pretty surprised if something similar hasn't been proposed > *somewhere* before. > > I note that on April 20th, the "Gnome System Control Panel Project" was > announced (see http://www.gnome.org). I think this is our opportunity to > work with its originator, Andy Doran, on making a consistent, easy, and > powerful interface for configuring programs. Branden, I don't want to put you down, and I didn't even read your proposal carefully. Just some random thoughts about this issue: 1) There was a very long discussion on debian-admin (I can send it to you, if you like), where all the technical issues have been discussed. It is *very* complicated to do it right. For example, you have to make sure that editing the configuration files manually will not break anything. 2) The KDE (and Gnome) approach of several little config programs will not work, as every single program is to specific and has the configuration hard coded and seperated from the underlying programs. This is a very bad thing, IMHO. Also, the programs run only in a certain environment, for example KDE. What happens when I want to mix KDE and Gnome tools? There is no one that guarantees that this will work. Also they only work under X. 3) Please take a look at COAS. It seems to do what we want. It is GPL'ed, distribution independent, and does provide a framework for multiple extensions. We certainly should work on this (note: I did not looked at COAS, but it seems to be the Right Thing. Some other people could tell us about their experience with COAS?) I hope we will have the best system in the long run. I don't feel good about suboptimal configuration tools, they tend to create more problems then they solve. Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ease of use and configurability
Great, I did it wrong... should go to bed. Anyway, here is the errata: > 1) There was a very long discussion on debian-admin (I can send it to you, Obviously, this should be debian-admintool. > 2) The KDE (and Gnome) approach of several little config programs will not > work, Obviously, this was not what Branden suggested. Sorry for the fuzz, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, Apr 30, 1998 at 06:36:37PM -0400, Dale Scheetz wrote: > On Thu, 30 Apr 1998, Marcus Brinkmann wrote: > > While I agree with much of what you say about the need for policy to be > clear, I will continue to urge caution when being dictatorial about > policy. > > I only disagree with Manoj's characterization of my position. I have never > said "Ignore policy if it suits you". What I have called for is a reasoned > application of "The Policy Statement", which represents the current set of > written policies. When I wrote I agree with Manoj, I meant his technical position, not the way he interpreted the position of you or other people. However, I think you know that already... > For example, the "stripped binaries" rule in the policy statement is fine > with me. I don't see it as "broken" the way Manoj has suggested, because > we have an unwritten policy against delivering broken packages. I see the > unwritten policy as having a higher priority than the "stripped binaries" > policy as written. Dwarf, I really enjoy learning. Reading the Debian list, I learn more than I would learn elsewhere. Reading Stroustrups fantastic book about the C++ programming language, I learn a lot. Reading the policy manual I learn a lot of things about making a distribution. I'm not very experienced (I have two years or so experience with Linux, and one year of it with Debian). I try to do it right, but I'm sure I'm messing up things quite often. I try my best, but if the policy manual says I have to strip binaries, I'll strip them, as it sounds correct. Obviously, I do not maintain a package where this does not work, but I would like to *know* about the exceptions, so that I am aware of them. [snipped] I do not comment on the changelog issue. In general, the policy should be unambigouus (little room for interpretation avoids confusion. This does not mean that there is no flexibility, but the policy should state it where other solutions are okay, too), and exceptions should be recorded. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Suggestions for base package
Hello! Some user suggested on debian-user to include a ppp setup utility on the base disks. Actually, he suggested wvdial, but he was not aware of pppconfig, which works better and is great. Naturally, I missed to vut&paste his name... I think this would be a of great help for newbies. I tried it and it worked out of the box. He also suggested to add a few default nameserver to resolv.conf if empty. I have to admit, that I too have problems to remember the number of my local ns sometimes, which can be a pit when needed. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
COAS & Debian (was: Re: Ease of use and configurability)
On Fri, May 01, 1998 at 08:17:00PM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Branden Robinson) wrote on 30.04.98 in <[EMAIL > PROTECTED]>: > > (I've asked that before: what's the current status of COAS, anyway?) Oh yeah. Bruce wanted to port it to Gtk. Obviously, this has somewhat changed. I don't know if he is still working on it. I asked him some time ago, but got no response. Perhaps we should create a COAS for Debian group? Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20914: seyon package copyright (fwd)
On Mon, May 04, 1998 at 03:42:28PM -0400, Dale Scheetz wrote: > On Mon, 4 May 1998, Raul Miller wrote: > I understand your concern here, but there is no restriction against > distributing modified binary, only modified source. Am I the only one reading the following in the way that derived works are forbidden? " ...provided that in all above cases Seyon is intact and is not made part of any program either in whole or in part [...]." IIRC, we have to be able to derive a program (or would you allow a 10MB patch?). Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
Hello! On Tue, Jun 02, 1998 at 09:19:11PM +0200, joost witteveen wrote: > > > The document authors already can enforce a lot of things, keeping the > > document free: > > > [...] > > I want to hear valid reasons why this is not enough before I even think > > about non-free documents in main! > > Uhm -- just one reason: GPL (the text) is non-free: you are not allowed > to modify it (from the GPL, first few lines): > > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. Nah! You can't change the copyright of a program, so what? You can derive a new copyright from the GPL, but you mustn't name it GPL. Changing the name is enough, because license textes themselves are not copyrighted in the normal sense (IIRC). The NPL for example is a copyright somewhat derived from the GPL (although it is completely different). As I stated in my original mail, requiring a name change is okay and does not make a document non-free IMHO. > Fortunately (if I'm correct) the GPL does not _FORCE_ us to include a copy > of the GPL document with debian -- so there _is_ a way to distribute a > ``free'' > debian: `rm /usr/doc/copyright/*GPL'. (and maybe put a note there, saying > that we cannot distribute the GPL due to licence problems, but it can be found > by writing to ...). > > Actually, I'm more serious than it may seem. Yes, I realise it's a bit harsh > to remove it (and other references) from Debian, but if that helps to > make the FSF distribute the GPL with a different licence, then it's a good > thing. This is not necessary, as this has nothing to do with software freeness anymore. The point is that you can't change the copyright of programs (this does not make them non-free!), and the programs contain a reference to the GPL. You *can* derive a new license from the GPL, but you may not call it GPL anymore in the legal sense. Where is the problem? The problem is that the GPL is a legal text, and a sequence of bytes. We want to have the right to change the sequence of bytes, not the legal text. If we encode the GPL in unicode instead of ASCII, is this a infringement against the quote above? Let's not get bizarre here. I'll try to summarize: 1) A software entity that forbids to change the copyright is not non-free becasue of this clause (if this would be true, we could only ship PD software). 2) Requiring a name change is sufficient to cope with this problem. > Hasn't TeX learned us that there is no distinction between documentation and > source code? > Or how about those C(++) systems that let you write documentation and source > code in one file? Yes, you make very valid points here. IMO, this problem rises now because we have more and better documentation than some years ago. Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
On Wed, Jun 03, 1998 at 09:58:03PM +0200, Joost Witteveen wrote: > OK, that may well be true. But still the text of the GPL is clear: you > are not allowed to change it, whether you change the name of your cahnged > version or not. I'll mail RMS about this and come back to this list when I get an answer. Thank you, Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which gcc builds potato?
On Tue, Sep 21, 1999 at 09:23:07AM -0400, Ben Collins wrote: > On Tue, Sep 21, 1999 at 12:49:29PM +, Dale Scheetz wrote: > > On 21 Sep 1999, Ruud de Rooij wrote: > > > > > Dale Scheetz <[EMAIL PROTECTED]> writes: > > > > > > > So, what, if anything, is being built with egcs? > > > > > > Nothing, since egcs does not exist in the distribution anymore. > > > > Well, egcs 1.1.2-2 is still in my source archives, so someone must be > > using it. egcs64 is currently being used to build Ultra kernels, so I > > figured the 32 bit egcs was being used for some purpose as well. > > > egcs isn't used anymore and is obsoleted by the latest gcc 2.95.x line. Not true. The Hurd port is still using egcs. We would like to switch to gcc 2.95.x, but it has some problems. Mark Kettenis is working on it, and I am sure we will follow very soon, but anyway, currently egcs is the only option for us. (gcc 2.95.x couldn't compile itself last time I tried). Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Status of GNOME in potato
On Sat, Sep 25, 1999 at 08:16:45PM +, Vincent Renardias wrote: > Development tools > glade-0.5.3.tar.gzGUI builder > * current Debian version: 0.4.1-1 I am waiting for gnome-libs. > Gtk---1.0.2.tar.gzC++ language bindings > * 1.0.2-1 [OK] Note that Gtk-- is currently completely revamped, and although there probably will be an update, Gtk-- 1.0 is mostly dead meat. I am not sure 1.1. makes it into potato though. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Lizard / Debian
On Tue, Sep 28, 1999 at 11:59:47AM +0200, wayne forrest wrote: > My question is : Has Debian got any interest in this , and is there > anny plans for future releases made to make use of the Lizard. > > I am pretty sure that this software will give Debian a great boost. I am not so sure. First, I can't see much difference to our installation except that it has funky graphics, a hell lot of warnings allaround the place (EXPERS only. ONLY do that uf you KNOW what you are doing. Please use the default if you don't know what you do). Those get in the way if you know what you do. The package selection only allows one profile to be selected, not multiple. Then, they make the mistake of configuring everything in this tool. Video card, sound card, adding new logins etc. In short, it looks like a better yast. In Debian, we use a more distributed approach. What may be useful is to snarf some of the code and put it in various places (The qpl makes this hard, though). For example the mouse detection code, but only if it is really reliable (and I mean more reliable than the gpm mouse detection code, which is pretty good). And I don't think a tetris belongs in the installation program, point. I think with debconf we are on a better track. I don't want to say that Lizard is bad software, it is probably very good for what it does. But it doesn't fit into Debian, neither from the concept, nor from the implementation (has it a frontend which is usable over a serial line?), nor from the license (IMHO). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, Sep 28, 1999 at 01:12:06AM -0400, Raul Miller wrote: > > Alternate question: why do we even have to package up flat text files? > Why can't we just import them into debian in some regular manner? [I can > see that naming convention is important, but are there any other issues > beyond that? -- I mean, besides the issue of the current implementation > of dpkg.] Exactly. A better designed package manager would support modular package format handling. then we could simply do (let's call the package manager hpm for now): hpm -i blacksteel.etheme instead dpkg -i etheme-blacksteel.deb hpm -i realvideo.tar.gz instead alien; dpkg hpm -i somestuff.rpm instead alien; dpkg hpm -i CPAN:mymodule hpm -i CTAN:mytexstyle hpm -i gutenberg:faust and so on. I think we will be able to do this in a few years, because we have to to cope with the grow of free information and data available. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: GNOME package versions
On Tue, Sep 28, 1999 at 12:17:22PM -0500, Chris Cheney wrote: Content-Description: Message Body > > I took a few minutes to check what versions of gnome packages were in potato > and in /incoming to compare against the current gnome ftp site. The first > column shows the version in debian and the filename is the version on the ftp > site. > > *** means it does not appear to be packaged yet. > *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz Look for libgtkmm* binaries and gtkmm source package. > 0.4.1 1166853 Sep 24 16:56 glade-0.5.3.tar.gz I only need to download: > 1.0.40 3196381 Sep 27 15:19 gnome-libs-1.0.42.tar.gz and recompile. Will be done in no time. Don't worry. But only if it is installed in the archive by now (last time I checked it was stuck in incoming). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: architectures, endianness
On Wed, Sep 29, 1999 at 02:13:58AM +, David Coe wrote: > Do we have a table/chart somewhere that explains which > Architectures use which endianness? Gpart has incomplete > support for endianness, the beginnings of which are > implemented as shown below; IMHO, gpart should check the endianess with the AC_C_BIGENDIAN at configure time, at least if it is an autoconf program, which it should be. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: architectures, endianness
On Tue, Sep 28, 1999 at 09:32:56PM -0500, Chris Lawrence wrote: > On Sep 29, David Coe wrote: > > Do we have a table/chart somewhere that explains which > > Architectures use which endianness? Gpart has incomplete > > support for endianness, the beginnings of which are > > implemented as shown below; it behaves as if only i386 > > and alpha are little-endian --is that true? > > At least on Linux, use /usr/include/endian.h to determine the > machine's __BYTE_ORDER (which will be __LITTLE_ENDIAN, __BIG_ENDIAN or > __PDP_ENDIAN). Thus there's no need for architecture testing... This is not Linux specific, but a feature of GLIBC. However, you usually don't include endian.h directly, but . Which is exactly what the AC_C_BIGENDIAN autoconf dcheck oes :) But the autoconf check is better, because it also can run a small test program if __BYTE_ORDER is not defined, so you get it right even on machines which don't define this macro in their header files. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Re^2: strange behavior of dh_dhelp
On Tue, Sep 28, 1999 at 08:25:00PM +0100, Marco Budde wrote: > > Please tell me what for do we need doc-base? To piss off people like you of course. Shaking my head in despair. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 12:54:32AM +, David Coe wrote: > > Is that still an accurate description of the legal status (from > FSF's perspective) of XEmacs, and if so, shouldn't we move it to > non-free? The FSF does only include code in GNU programs if the author assigns the copyright to the FSF by signing a paper. This goes for all substantial contributions to GNU programs. So, if you want to include a few dozen of lines to fileutils, textutils, bash or whatever, you have to assign the copyright to the FSF, so they can defend the code for you. Debian does not require legal papers from contributors, we just don't care and hope that our ass is covered by our good intentions (we act responsible and in good faith). No problems with XEmacs. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Corel changes BTA?
Hello,
I have seen on IRC a link to the changed BTA by Corel (I lost the link,
hough). Someone who received this please verifies the correctness of this
information, as I do not participate in the beta test and don't know if
this is real (although it looks real).
A quick check shows the following relevant changes. They seem to solve the
solution pretty good know. Are there any more issues we should be concerned
about?
I applaud Corel to not only clarify, but also put a clarification on paper.
I also ask people not to send angry letters to Corel, but further try the
way of negotiation and discussion, if there are still problems to be found.
Regardless of intentions, this is a big success, because we could one more
time defend the spirit of Free Software by social means (as opposed to legal
force). I want to thank everyone who was involved (especially Bruce Perens).
---
5. Use of Product:
(i) The use of each component of the Product shall be governed by the terms
and conditions of the applicable software license agreement that accompanies
such component. For example, your use of components which are licensed under
the GNU General Public License ("GPL") is governed by the terms of the GPL.
(ii) Notwithstanding the foregoing, those portions of the Product identified
as being developed independently by Corel, including without limitation the
files listed on the attached Schedule "A" ("Corel Softwware") , may be used
bby Users solely during the Term and solely at the User Location for the
purpose of evaluating the Products for the benefit of Corel. User may not
reproduce and distribute copies of the Corel Software to any other person.
[ About Schedule A: This is a list with about 30 program names, that goes
like "Corel Explorer", "hardreboot", "etcdev", "setup" etc. Most of them
sound like small utilities that may very well be developed independently by
Corel. However, some of them have a k*, like kchangepwd. They probably link
to KDE libraries, I don't know which license those have. Considering that
their license may be LGPL or more free, and considering the opinions of KDE
developers, I don't think that Corel is on thin ice here).]
...
11. Intellectual Property Rights. All right, title and interest to all
intellectual property with respect to the Corel Software shall remain with
Corel. No license or other right of any kind is grnated by Corel's
furnishing the Corel Software to User, except for the limited right to use
and tet the Corel Software as part of the Product as expressively provided
in this Agreement. Nothing in this section shall effect the rights of
copyright holders of non-Corel Software or the rights granted to User under
license by such copyright holders.
Part 13: Confidentiaity of Information
[This section has in BOLD:]
For clarity, non-Corel Software is not considered Confidential Information.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 09:14:15AM +0200, [EMAIL PROTECTED] wrote: > On Thu, 30 Sep 1999, Marcus Brinkmann wrote: > > > The FSF does only include code in GNU programs if the author assigns the > > copyright to the FSF by signing a paper. > > Wrong. > > Take a look at http://www.gnu.org/software/ > At least shtool and WindowMaker are copyrighted by their authors. Well, there is a distinction between software that is GNU and software that is used in the GNU system. So, a GNU system includes X, which is obviously not copyrighted by FSF (not even GPL). There are even cases where parts of GNU software contain code not copyrighted by the GPL (thanks to Gunnar Evermann for pointing out an example in emacs). But rest assured that the FSF is very eager to get the copyright assigned to them, and incorporating parts which are not is an exception usually (I say this from my experience). Thanks for the correction, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: [ISSUE] No support for shadow groups, yet we perpetrate to have it
On Fri, Oct 01, 1999 at 06:53:18PM -0400, Ben Collins wrote: > This may sound silly, but in fact, glibc does not support shadow groups[1] Indeed. I think we can drop this idea altogether. How many people do use passwords on groups anyway? thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: [ISSUE] No support for shadow groups, yet we perpetrate to have it
On Fri, Oct 01, 1999 at 07:44:38PM -0400, Ben Collins wrote:
> On Sat, Oct 02, 1999 at 01:28:53AM +0200, Marcus Brinkmann wrote:
> > On Fri, Oct 01, 1999 at 06:53:18PM -0400, Ben Collins wrote:
> > > This may sound silly, but in fact, glibc does not support shadow groups[1]
> >
> > Indeed. I think we can drop this idea altogether. How many people do use
> > passwords on groups anyway?
>
> Group passwords are supported, just not shadowable (man getgr{ent,nam}).
Yes, I know. What I meant is shadowing the group file does only make sense
if you actually have passwords in it :)
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: ITW/P: freecati
On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote: > even opt-out lists are the wrong solution...because they don't work very > well (especially when usage of them is optional). telephone pests should > be limited to calling ONLY an opt-in list, people who are willing to > receive unsolicited calls. opt-in lists will not lead to usable results, because the statistics will be skewed, and you know that. Nevertheless, I agree that calling random people is rude. > cold calls are annoying regardless of their purpose. sales calls are > especially annoying, but that doesn't excuse academic or market research > surveys. Yes. What I find acceptable are snail mail surveys. Those can be easily ignored, and are paid by the sender. (Note that I find mail advertisement highly offensive, but surveys are not at all comparable in mass). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: linking binfmt_misc with mime-types
Hi, On Mon, Oct 04, 1999 at 12:26:18PM +0100, Edward Betts wrote: > Are we proposing that all mime-types have binfmt_misc setup? Does that mean, > the kernel will be able to `run' any file in mailcap? Is that what we really > want? > > I am neither fore, nor against this idea. On the one hand it would be quite > cool, entering the name of an html document on the command line and it loading > in lynx. On the other hand it goes against the Unix philosophy a bit, > documents are programs are documents. Ahhh. Nice that you mention it. Maybe this should really be implemented on the Hurd, because it fits perfectly fine into the hurd philosophy. (Why this is so, you must know that every component of the Hurd is replacable by the user, without the necessity to trust thode components. So, in this case, adding a personalized exec server is fine if you want to do so.) The Hurd craps "Unix philosophy" (whatever this is) anyway. One could also say it takes UNIX philosophy most seriously. Indeed, I don't think you mean UNIX phiosophy here, but monolithic kernel tradition. > Some more questions. Is it possible to recognise an html file by a couple of > magic numbers at the beginning? Most html starts or , but it is > not certian that it will look like this. Another thought is the possiblilty of > running perl scripts without the bang path, but then how would the shell tell > it is a perl script. Uh, for SGML documents, how about looking at the ? Anyway, I suggested even to use the file utility, so you can make use of the magic database. > If we put loads of entries into binfmt_misc are we likely to fill some kernel > data table? Ha! Under Linux probably... > What happens if it overloads? Complain to Linus for choosing a monolithic design or use the Hurd. > Do we significantly affect the > performance of the system? U. I better not speak about performance and the Hurd :) But to answer your question: On the Hurd, it would first try to load it as executable, and only if that fails it would closer look at the file. So no. > If the kernel is checking each file against a list > of magic numbers will it take a long time to run a file? (Probably not the > kernel is fast, and most files we will run will be ELF, which is probably > checked first.) Indeed. > This is not user independant is it? On the Hurd it is! > The system can not be set so that one user > has support for running Java/JPEGs from the command line, and another does > not? Yes! Oh, you mean Linux? No. See above :) http://www.debian.org/ports/hurd Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: linking binfmt_misc with mime-types
On Tue, Oct 05, 1999 at 08:50:29PM +1000, Brian May wrote:
> This is getting a bit off the original thread...
Just a little ;)
> IMHO, any magic type of database, is a "hacked" solution.
As long as the maguc type is based on the content of the file, it works
rather well. As we don't need a full classification, but only for those fies
we actually will execute, there will hardly be confusion about this.
> What I really would like is a filesystem that can store a mime-type for
> every file... That way no magic databases are required.
That's a nice idea. Where we are at it, we should also store the package
information for a file, so we don't have an external database
(var/lib/dpkg/info) for this. It would also speed up the dpkg -S command
;)
> In addition, the
> kernel could be configured to assign default mime-types for different
> file extensions, or something.
You say a magic type database is a hack, and on the other hand file
exetensions are a better indicator? Phew. Microsoft uses file extension
(".tgz file" if it can't recognize). I think examining the content is a
much better strategy.
> This would mean instead of having lots of different programs trying
> to determine file types (each with a very different method - some use
> extensions, others use magic databases or a combination of the two).
Mmh. I like to think of the file utility as the standard reference. I didn't
knew about any other such databases. That apache uses file extensions is
bad, but it's reasonable for a browser which only serves a well defined set
of files.
> Programs like Apache wouldn't have to work out the mime type from the
> extension, but could just look at the value given by the filesystem.
> Changing the mime-type for one file would automatically effect
> all programs.
Yep. For this and other stuff (package managment) a filesystem which can
store arbitrary metadata would be nice.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: linking binfmt_misc with mime-types
On Tue, Oct 05, 1999 at 08:39:00PM +1000, Brian May wrote: > Agreed. I would always be reluctant to make all my documents executable > in order to get this to work... This is indeed a bit ugly, but then, it's just a bit ;) > These are questions I can't answer. I seriously doubt the kernel will be > able to reliably distinguish all file types though - especially > ones like HTML. Under Linux, I would never suggest such a thing. But in the Hurd, it's not part of the kernel, so what? Anyway, I say it again: Proper HTML can be recognized with the leading . Cludgy, non-conforming HTML is not a good thing to start with. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: procps trying to overwrite /bin/kill
On Wed, Oct 06, 1999 at 09:44:46AM +0200, Mirek Kwasniak wrote: > > No, news bsdutils package is without kill. Oh, wee, another portable program bites the dust. Is the kill in procps linux specific, eg, does it make use of the proc filesystem? This won't work in the Hurd, so the Hurd would be without a kill. But then, we haven't ported util-linux yet (we can still use their kill even if linux ports don't). Maybe we should just fork out our own version of kill, as this seems to be the last fashion here. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: better RSYNC mirroring , for .debs and others
On Thu, Mar 09, 2000 at 12:46:05PM -0700, Jason Gunthorpe wrote:
>
> On Thu, 9 Mar 2000, David Starner wrote:
>
> > I'm not arguing the rest of your points, but I'm curious about
> > this one. IIRC, the last thing a full bootstrap of GCC does,
> > after building stage one binaries with the native compiler,
>
> Hum, It *used* to do this, can't seem to get it to do it today though
>
>
> IIRC it only applied to debug information, it included timestamps or
> some such.
There is a small header at the beginning of an object file which is
different each time, because it contains a time stamp.
This is why 'make compare' removes the first 16 bytes of the object
files before comparing.
for file in *$(objext); do \
tail +16c ./$$file > tmp-foo1; \
tail +16c stage$$stage/$$file > tmp-foo2 \
&& (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $$file differs
>> .bad_compare) || true; \
done
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Danger Will Robinson! Danger!
On Sat, Mar 11, 2000 at 04:06:01PM -0500, Jacob Kuntz wrote: > our biggest handicap is that we're always a year behind everyone else. being > a year behind is suicide in any industry. The simple fact you are missing is that Debian is not an industry. Don't make the same mistakes as the industry. Making last minute changes and rushing in x.0 versions of critical software is just Plain Wrong. Especially the Linux kernels are often very unstable 'til x.12 or 14. Everytime a new version of the kernel is released the same story. Sigh. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Danger Will Robinson! Danger!
On Sat, Mar 11, 2000 at 11:44:39PM -0600, Manoj Srivastava wrote: > >>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > Marcus> Making last minute changes and rushing in x.0 versions of > Marcus> critical software is just Plain Wrong. Especially the Linux > Marcus> kernels are often very unstable 'til x.12 or 14. > > Why is it bad having a stable kernel installed as default, and > a 2.4-pre kernel, marked as extra, with warning in the long > description, also in the distribution? Nothing wrong about that, if we don't go a long way to make additional changes in the various admin packages (isdn, pcmcia comes to mind). I was always a supporter of the latest and greatest kernel as a binary package in extra. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Danger Will Robinson! Danger!
On Sun, Mar 12, 2000 at 01:37:01PM +0100, Michael Meskes wrote: > On Sat, Mar 11, 2000 at 11:14:56PM +0100, Marcus Brinkmann wrote: > > The simple fact you are missing is that Debian is not an industry. > > Which doesn't mean that all arguments are not valid. As Manoj pointed out, > being outdated is not making us reach our technical goals. However, just because a distribution does contain kernel x.y does not mean it is technical excellent or even up-to-date (I want to point out that most distributions always contain up to date versions of the kernel, apache, X and gnome, but most other packages are often older versions than in Debian). > > Don't make the same mistakes as the industry. Making last minute changes and > > rushing in x.0 versions of critical software is just Plain Wrong. > > Especially the Linux kernels are often very unstable 'til x.12 or 14. > > No one ever suggested dumping 2.2 for 2.4. All that's talked about is ADDING > a 2.4 image. Nothing wrong with that, if it contains a warning that various packages may not work with this kernel installed (as long as it is not tested much). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: So, what's up with the XFree86 4.0 .debs?
On Sun, Mar 12, 2000 at 10:47:51PM -0500, Branden Robinson wrote: > > You are going to keep /usr/X11R6 for this release right? I guess that the > > XFree86 people might get a bit irritated if you tried to drop it. > > Actually, I've evilly been toying with the idea of #defining ProjectRoot to > /usr for 4.0. Upstream has already moved almost entirely to the way Debian > currently does things as far as filesystem layout goes. If you do this, I would cheerfully go with ProjectRoot / on the Hurd! Please :) Thanks, Marcus
Re: Turbo Vision non-free? (Was Re: Another packages wishlist)
On Thu, Mar 16, 2000 at 04:51:51PM -0800, Jakob 'sparky' Kaivo wrote: > /* > * Turbo Vision - Version 2.0 > * > * Copyright (c) 1994 by Borland International > * All Rights Reserved. > * > */ > > That's about as non-free as you can get. Only if there isn't a copyright file somewhere laying around, giving a license to us. Probably contact borland for a license if there isn't. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Debian and GNOME, partnership with Helixcode?
On Tue, Mar 21, 2000 at 08:31:01AM -0500, Miguel de Icaza wrote: > > > I'm sorry to disagree with you, the GNOME project *does* > > distribute binaries (and packages too), looking > > in http://www.gnome.org/start/ will give you pointers > > to packages for Caldera, RedHat and SuSE distributed > > from the GNOME site (ftp://ftp.gnome.org/pub/GNOME/stable/latest). > > Sadly, those packages are seldome updated, and there is not an ongoing > effort to keep them up to date. I tried to assemble such a team, in > the gnome-packaging-list, but that group never produced binaries. The good solution would be to make Debian packaging rules snapshot-able, so that you can build packages with appropriate version numbers, package names and dependencies right out of CVS. Currently, a Debian package is a Debian package, and it is not trivial to make a package which looks different from the "official" package. The debian-snapshot list was created to aim at a solution, but nothing came out of it so far. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Compiling Error
On Wed, Mar 22, 2000 at 01:15:01PM +, Michal Fecanin Araujo wrote:
> --
> #include
>
> FILE *output=stderr;
>
> int main()
> {
> fprintf(output,"Hello World\n");
> }
> --
>
> The problem is that its not possible to initialize output with stderr
> because it is not a constant. Is there any solution to this without
> modification of the code, only with gcc options.
No. Your code is invalid, and it should be fixed. You already know the fix.
Now you just have to accept it.
> The following modification is obvius and Iam not interested in it.
Tough.
Thanks,
Marcus
>
> --
> #include
>
> FILE *output;
>
> int main()
> {
>output=stderr;
>fprintf(output,"Hello World\n");
> }
> ---
Re: Signing Packages.gz
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: > The whole file --- verifying each entry would take at least three minutes > on my hardware, and god knows how long on anything moderately old or > outdated. I certainly wouldn't want to try it on m68k on a regular basis, > eg. (If doing something just once takes a second; doing it 4000 times > takes a bit over an hour) I don't think it is useful to sign the Packages file, because: > Whose key should be used? Probably a special one just for dinstall, > that's kept fairly securely by the Novare and -admin folks, and revoked > regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). > There doesn't really seem a huge amount of choice here, to me. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. There was some discussion about this in the past. The trick is that security should be implemented in dpkg(-dev), not somewhere else. This has the advantage that it works also with individual packages you don't get from an archive source. It cuold also be used to verify the origin of the package. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
Hi Anthony, On Mon, Mar 27, 2000 at 08:37:10AM +1000, Anthony Towns wrote: > On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote: > > On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: > > > The whole file --- verifying each entry would take at least three minutes > > > on my hardware, and god knows how long on anything moderately old or > > > outdated. I certainly wouldn't want to try it on m68k on a regular basis, > > > eg. (If doing something just once takes a second; doing it 4000 times > > > takes a bit over an hour) > > I don't think it is useful to sign the Packages file, because: > > A signature authenticates the source of a document. That's worthwhile, > since verifying the source of a Packages file lets you transitively > verify the source of all the packages in a distribution. This is true if the signature is made in a secure manner. Storing the key on a medium that is available by dinstall is not secure, because a compromise of dinstall or higher instances (master etc) will reveal the secret key. > > > Whose key should be used? Probably a special one just for dinstall, > > > that's kept fairly securely by the Novare and -admin folks, and revoked > > > regularly. > > Any such key would have to be considered insecure, no matter how soon you > > revoke it. So the paranoid people still don't trust it, and the other don't > > care (probably). > > Nonsense. > > The only reason not to trust a key dinstall uses explicitly for signing > Packages is if you believe dinstall is compromised. If you believe that, > then you shouldn't be downloading .deb's *ever*, because you're immediately > running *untrusted* scripts as root on your systems. So you agree with me. What exactly do you think is "nonsense"? > If dinstall *isn't* compromised, it's still possible that your favourite > FTP site is, in which case all they need to do to compromise your machine > is replace a .deb with their own hacked version and let you download it. Yes, and I can decide if I should trust this package at installation time. I can base this decision on the keys in the Debian keyring package, and further information I get from the Debian web site etc. In your model, I can not perform these further tests. I would have to trust dinstall (and higher instances) completely, or loose. > Automatically signing things is less secure than manually signing things, It is only as secure as dinstall/master is, so we gain nothing at all by your suggestion. Here is a huge difference between your and my suggestion. What I proposed has problems (and I will address the problems you raised below), but it is a real improvement at least. > and you need to do some extra stuff to not have gaping security holes > when automatically signing things, but sometimes there isn't that much > of a choice. There is in this case. > All this FUD about "no, no, we can't do that, it's not > secure!" is, well, just that. *Nothing* is absolutely `secure', some > things just have fewer or different exploits than others. Wrong. The issue is not the degree of secureness in real life, where you "hope" that the few exploits won't be found. What we should be concerned about is theoretical secureness. Security models matter. > > > There doesn't really seem a huge amount of choice here, to me. > > Packages should come with their *.changes file, and dpkg should have an > > option to verify the signature of individual packages. There was some > > discussion about this in the past. The trick is that security should be > > implemented in dpkg(-dev), not somewhere else. This has the advantage that > > it works also with individual packages you don't get from an archive source. > > It cuold also be used to verify the origin of the package. > > Note that this makes debian-keyring a more or less standard package. Only if you care about security. > Note > that it requires you to trust everyone in that keyring with every aspect > of your system. Well, this is already the case, and can't be prevented for a binary distribution. However, a little bit more exact is that you trust everyone in that keyring with every aspect of the package I install from a single person (if I don't trust someone, I can simply choose not to install the packages from this origin.). Of course, one package, however small, can ruin the whole system in its scripts, binaries etc. > Note that this doesn't help with revoking signatures: if some idiot > decides that being a Debian maintainer should give him the right to 0wn > all the machines that use his package; then gets thrown out; he can still > us
Re: Signing Packages.gz
On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote: > You are wrong about signed .debs vs signed package files. Signed .debs are > not worth the bytes to transfer a signature and the time check it. Their > only real use is to check the master archive against hack/corruption and > even that is better served by saving the uploading .changes file > [preferably on multiple hosts, hence d-devel-changes]. In fact I would > argue .deb sigs only give people a false sense of security because it > makes the system as weak as the weakest key in our keyring. > > Signed package files on the other hand provide a really fast and efficient > way to definately verify the whole chain, from us to the user. I can't follow your reasoning. In the signed .debs case, I, as a developer, assert that the package comes from me. A user can directly verify this by checking the signature. In the signed packages file case, I as a developer, assert that the package comes from me, which is verified by dinstall. Then the user verifies whatever comes from dinstall, but he can not directly check if what is in the archive comes really from the developers (not a problem if dinstall can be trusted). The latter adds a chain, thus one further point of weakness. I might add that as the dinstall key can't be kept truly secret if it is stored on a net-connected machine, this weakness is rather huge. You already trust the maintainers (either directly or through dinstall). What makes you think that adding a middleman improves the situation? > In > particular, we could have a relatively insecure daily use dinstall key > [for unstable] and a strong release key (aka the key the security team > uses) I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it is shared among the security team). Of course, if the security team use their personal key in the latter case, I can trust it. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
Hi, On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote: > But unfortunately that's not quite the choice I have either, since for > some reason that I can't fathom, people seem to think that a dinstall > key would be an abomination to man and God and I'd probably be summarily > kicked out of the project as soon as I tried sending a patch somewhere. > Or at least it'd never get applied. It seems you feel personally insulted. I am sorry for this, but unfortunately it doesn't change the situation that the signed packages case adds a further point of weakness to the chain of trust. You are correct that both systems can be applied. Signing debs verifies that a package comes from a (probably former, if keyring is out of date) developer. Signing Packages verifies that the contained packages come from master. As dinstall verifies the keys on the packages (which already exist, btw, they are just not propagated), it puts itself in the middle of the chain: signed packages --> dinstall --> user 12 We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept "truly"[1] secret (it directly depends on the security of master), this weakness is rather huge. This problem is avoided if the link 1 is propagated to the users: signed packages --> dinstall \ 1 \--> user 1 In this situation, I don't have to trust anyone except the Debian developer. Not the admin team, not the security team, not master, not dinstall. Can't you see that this is a crucial advantage? If you also want a link 2 from dinstall to the user, I don't care. But don't tell the users that link 2 asserts that all packages come from Debian developers, it doesn't. What link 2 asserts instead is that the packages come from master. It solves the mirror problem, but does not solve the master problem. I don't object to a signed Packages file, but it is important to see which problem it solves and which it doesn't solve. Also it is important to realize that the secret key automatically used by dinstall can not be stored in a highly secure way. Thanks, Marcus [1] As secret as any PGP key should be kept. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Tue, Mar 28, 2000 at 12:41:22AM -0500, Chris Frey wrote: > > Quoting from the mailing list archives... :-) > > Marcus Brinkmann <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: > > > The whole file --- verifying each entry would take at least three minutes > > > > I don't think it is useful to sign the Packages file, because: > > > > > Whose key should be used? Probably a special one just for dinstall, > > > that's kept fairly securely by the Novare and -admin folks, and revoked > > > regularly. > > > > Any such key would have to be considered insecure, no matter how soon you > > revoke it. So the paranoid people still don't trust it, and the other don't > > care (probably). > > Can someone explain to me why any such key would have to be considered > insecure? If it is accesible by dinstall, it has to be stored on masyer a machine connected to master. Hack master, and you get the secret key and you can tamper with it the way you want. > If we are trusting the admin folks to generate the > Packages file itself, can't we trust them to sign it properly? We could. However, we can make it so that we don't need to trust the at all, only individual developers. > Is there another avenue that I can't see where this key could be compromised? It can not be compromised per se. However, it is subject to the same security as master is, which is much less than it should be (read the pgp docs to find out how a secret pgp key should be stored and used). > And by the way, how do the paranoid people do things now? I don't know. I am not paranoid. > Do they compile everything from source? This is one solution. > The source is the only place I can find a signature at all, and this is > the path I am currently venturing out on. yes. However, we already have the signatues on binary packages in the changes file. We just need to propagate it to our users. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: ATTN: pjw@edmc.net
On Fri, Mar 31, 2000 at 11:19:40PM -0500, Branden Robinson wrote: > Blacklisters may have the right to speak and *say* what they think I should > do, but they have no right to be heard. > > If you have the right to refuse to listen to me on my terms, I have the > right to refuse to listen to you on yours. Yes, but you have not "the right" (what loaded words!) to close the bug reports. Feel free to ignore them, but don't close them without a better reason. Someone else might want to take alook into it, and listen to the submitter. (And be able to contact him). Also, it might be that the submitter reads the bug archive to correspond with you. I don't know if you were serious or not, but I think the whole discussion got well out of hands. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 08:52:36PM +0200, Torsten Landschoff wrote: > On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote: > > > It seems you feel personally insulted. I am sorry for this, but > > unfortunately it doesn't change the situation that the signed packages case > > adds a further point of weakness to the chain of trust. > > Interesting. So signing Packages.gz will lower the security? No. Currently there is NO chain of verification (I should not have said "trust", it's the wrong term. Sorry). However, it doesn't establish a complete chain of verification from the developers to the users, au contraire to what you seem to believe. > > We already use link 1 (signed changes files), and trust it. This won't > > be changed by either proposal. Yes, even in the signed packages file you > > trust all developers keys. > > There is a difference between our master server trusting the uploaded changes > files. master will by definition always have the current keyring. The user > might not. Yes, but this doesn't change the point. The problem of out of date keys is a known problem in any public key cryptosystem. > Okay - signing Packages will make Debian as secure as master is. Fine. > We must assume that master is secure otherwise we are doomed anyway. Wrong. If you have signed debs, and you are careful when updating the debian-keyring package, there is no risk even if master is compromised. > Currently Debian is as secure as the worst maintained mirror. > > > What link 2 asserts instead is that the packages come from master. It solves > > the mirror problem, but does not solve the master problem. > > So let's fix the mirror problem and let the master problem for later. This is the Debian way, right? Fetching the stick at the wrong end first. (Yes, this is a troll). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 01:36:56PM +1000, Anthony Towns wrote: > On Sat, Apr 01, 2000 at 03:38:29PM +0200, Marcus Brinkmann wrote: > > I could not trust either. The former, because it is stored on a network > > connected machine, the latter because it is transfered over the net (if it > > is shared among the security team). Of course, if the security team use > > their personal key in the latter case, I can trust it. > > Are you really sure that no developer stores their key on a net connected > machine? No, but if I find out, I can investigate the installed packages or delete his key from my personal copy of the debian-keyring (and could configure the not-existing dpkg-verify software to use this smaller keyring), if I really cared. Do you see the difference? I can make an informed decision, while in the signed packages file case, I can not verfiy the origin of any of the packages I don't have the changes file for. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 02:49:40PM -0700, Jason Gunthorpe wrote: > > On Sat, 1 Apr 2000, Marcus Brinkmann wrote: > > > In the signed .debs case, I, as a developer, assert that the package comes > > from me. A user can directly verify this by checking the signature. > > No, the user cannot verify that. The user can check the signature against > our keyring but they have no idea who *should* have signed it. It seems to be hard to understand, so I will explain it one more time: Why do you think this is not true in the signed packages case? Because you only have one key to verify and trust, the dinstall key. In my case, there is also a single one key to trust: The key used to sign the debian-keyring package. To complete the analogy: You could sign the debian-keyring package with your dinstall secret key to reach the same effect. Only that we alread have a debian-keyring package, and no mechanism to sign Packages files. The signature on the Packages files corresponds the signature on the debian-keyrng package in some way. Both secret keys should be kept private, but it is easier with the latter, as it is a trusted maintainers package. If this ever changes, we need to publish a different public key to verify against, the same is true for the dinstall key. > This means > that all I need to do is nix one of our maintainers keys and I can > undetectably forge Debian packages willy nilly. > > This is aside from the other problem of keeping 600 keys up to date on the > client machines and making sure that huge keyring is not disturbed in > transit. Oh yeah. I think if you are paranoid, you don't care about 500k additional bandwidth. Can you be more specific about the "disturbed"? I don't know of any valid attack that involves "disturbing the transit"? BTW, just to turn it around for the sake of argument: The Packages file is bigger than the debian-keyring. > > whatever comes from dinstall, but he can not directly check if what is in > > the archive comes really from the developers (not a problem if dinstall can > > be trusted). > > If we store the .changes files as I propose then the end use can check it, > if they want. Yes, and it should be stored, and verificable automatically. > But nobody will, because it is not a usefull thing to check. You say so. I disagree, and I think I gave sufficient arguments to show the opposite. Unfortunately, the people involved in this discussion are not interested in working out a good solution, but to win an argument. I don't have time for child games, sorry. The signed deb case not only has all the advantages of the signed packages file (there is almost a one to one correspondency, modulo location of the secret key (dinstall/debian-keyring)), it also allows verification of individual packages from a different source, which does not come with a packages file. It seems that people around here are happily throwing away an integrated solution in favour of a simple one. I doubt that the dinstall key will be stored secretly, and I doubt that the responsible people will tell the truth about this. This will lead to a false security by the user, and this is what I am concerned about. > It has use to definitively verify the root archive (say, after a hacking > or something) but otherwise the end user cannot make much use of it at > all. The root of the packages are the developers, not master. > > The latter adds a chain, thus one further point of weakness. I might add > > that as the dinstall key can't be kept truly secret if it is stored on a > > net-connected machine, this weakness is rather huge. > > The dinstall and security keys (particularly the security key) are going > to be far, far more secure than the weekest key in the key ring. It's a single point of failure, while maintainer keys only are applied to some packages. > > I could not trust either. The former, because it is stored on a network > > connected machine, the latter because it is transfered over the net (if it > > This is a flawed assertion - by your logic SSL is insecure and must not be > used. In reality it is a perfectly good system that has really good > security benifits. I don't know SSL, so, no comment. It does however serve a different purpose (encryption of streams, as opposed to verification of archives), so I doubt whatever is true for SSL is applicable to this discussion. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote: > > On Sat, 1 Apr 2000, Marcus Brinkmann wrote: > > > Wrong. If you have signed debs, and you are careful when updating the > > debian-keyring package, there is no risk even if master is compromised. > > Hahha! > > Sorry, your are deluded if you belive this :> Seriously, if someone can > hack master we are all vunerable - how many people out there do you think > use the same password on master as on their home boxes? How many people > foward ssh agents and put that key in their home .ssh/authorized_keys? How > many people have foolishly left their pgp key on master? > > Hint: Lots to all of the above [except the last, we purged a bunch of > people for that awhile ago]. Ok, I was only looking at master as the ftp archive. I am happy that the the last is not true anymore. BTW, those people should be forced to use a new key to sign Debian packages. The SSL problems I don't know about. > If master is compromized right now, we would take the d-changes archive > from a more secure machine [which we may not even have, hence the interest > in storing that in the archive], a slink cd, some potato CDs developers > might have, etc, and begin painstakingly verfiying each and every .deb and > .dsc to make sure it comes from where it was supposed to come from - there > is no automated way to do this and only people like James would actually > know who should be singing what packages. Yes, this is exactly my point. What would you do when you have signed Packages file and master is compromised? The attacker could replace some packages and create a new signed Packages file, just as dinstall does, and you had no way to find out after the mirrors catched up. In the signed deb case, you can easily verify all packages individually. (thanks for proving my point). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:18:17PM -0700, Jason Gunthorpe wrote: > > Now link 2. It is currently absent. What you seem to suggest is to add a key > > (dinstall-key) here, so the user can verify the archive. This adds a point > > of weakness. As the dinstall key can't be used automatically and kept > > "truly"[1] > > How about this, if someone was able to hack master to the point of being > able to get the dinstall key, I assure you they would be able to hack > some]weak developer machine and lift their key too. This is a seperate problem. I agree that this should not be the case, but it has no place in this discussion. If individual developer keys are compromised, we have a problem no matter what. Developers should not store secret keys on net connected machines, point. However, this only affects the developers packages, not the whole archive. > I also assert that the > chance of a hacker getting the security key is lower than say 50% of the > keys in our keyring. I would not make such claims. In any way, see above. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
on to trust, and that they themselves haven't been > compromised, is less trivial. (This is asserted by `Debian', but hey, > like you say, Debian could be compromised. Who'd wanna trust them?) Debian is compromised, but you had to compromise James to get a fake key in. You are correct about the trust analysis. > > In this situation, I don't have to trust anyone except the Debian developer. > > Not the admin team, not the security team, not master, not dinstall. Can't > > you see that this is a crucial advantage? > > Can't you see that it's a crucial *flaw*? You have to trust *every* > person who's a developer. And guess what. That means you have to trust > the admin team and the security team. It means you have to assume that > every machine every developer stores a secret key on is maintained as or > more securely than master. Only for individual packages. In the signed packages case, you have to trust everyone and their dog, *and* the security of master, *and* the admin team etc. This is exactly what I find irritating. You are trying to convince me that my proposal is flawed because you need to trust anyone. But it is exactly this false sense of security in your model, that one might believe he only needs to trust the admin team or dinstall. There are still all developers who uploaded the packages. In my model, you actually need to trust *less* things. The only way to look at it where you get more keys to trust is the out-of-date keyring issue. But those are seperate things. I have to be careful manually when upgrading the keyring. The rest can then be automated, just as dinstall is. So, even in my model there is only one key you really have to trust, and this is the debian-keyring. The trust for all other packages in the archive propagates. > > If you also want a link 2 from dinstall to the user, I don't care. But don't > > tell the users that link 2 asserts that all packages come from Debian > > developers, it doesn't. > > No, it asserts that all packages come from *Debian*. Debian itself states > that they'll only distribute packages that come from developers listed in > the keyring; and yes, it might turn out that Debian as an organisation has > been compromised, or hacked, or is just lying. Yes. I don't know how one can come to the conclusion that this is acceptable, though. Especially if there is a better solution, that is not much harder to implement. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 01:01:30PM +1000, Anthony Towns wrote: > On Sun, Apr 02, 2000 at 02:57:06PM +0200, Marcus Brinkmann wrote: > > > > As dinstall verifies the keys on the packages (which already exist, btw, > > > > they are just not propagated), it puts itself in the middle of the > > > > chain: > > > Well, as Jason points out, they are propogated: by the -devel-changes > > > list. > > They are not delivered to the user when he is downloading a deb, with no > > dselect method, and not with apt, and espcially not when downloading the > > package manually. > > But they could be, with minimal changes. Stick the latest .changes files > in debian/changes somewhere and add some code to apt to get it. The changes file would be sufficient, but it is not ideal, because it always signs a group of packages. Much better would be to stick the signature inside the deb. > I'd be interested in seeing some code for this. You keep throwing around the > word `easy', as though it *is* just as plausible to implement this method. > Please, at least write some pseudocode for it. before making the ar, run pgp/gpg on a list of md5sums of all files contained in the ar. Add this signature to the ar. When extracting a deb, verify the md5sums and the signature. > Make sure you consider the necessity of keeping debian-keyring up-to-date > in case of compromised keys. Make sure you either explicitly do use a > `single key' that's easy to verify, or not. If you do, make sure you allow > some way of coping with James' key being updated, or James retiring and > someone else taking over the job; and make sure you cope with upgrades > that possibly skip the generation where this happens. Of course. This all is not different from the dinstall keyring, and should be solved in exactly the same ways. [snip] > Marcus: How would dpkg with debian-keyring handle all this? > Well, the default should be to use the installed debian-keyring. This will work well for Debian native packages. Of course, care has to be taken when updating it (and this should be done manually, IMHO). For third party packages, we can allow a seperate key-ring, where root can add public keys from third parties he trusts. There could be a default /etc/debian/third-parties-keyring.pgp or it could be specified at the command line. The origin of the package should be displayed at installation time, of course, if verificable. > And note that saying `This distribution is Debian' is different to > saying `This distribution is made up of stuff put together by Debian > maintainers.' The latter could be put together for a special series of > `When Packages Attack!' and include all the best security holes ever > distributed by Debian. So dinstall (ha!) or lets say the admin team is doing a security check on all packages before adding them to the archive and to the Packages file? They are auditing the source and recompiling the binary packages before making a release? What Debian ships IS "the distribution is made up of stuff put together by Debian maintainers." And this, I think, is the critical point. The signed debs case integrates well with a distributed system like Debian is, where there is no central authority to decide what's good and bad. And this is the way Debian should be. If you are claiming that what Debian ships is something different than what the maintainer put together, I shall neglect all responsibility for all my packages from now on. I read the rest of your mail, but I don't think there is much else I would answer differently than I did before, and it is preferable to keep the reply short, to focus on the new things. Thanks, Marcus
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 08:11:15PM +0200, Torsten Landschoff wrote: > > We might want to revoke the old key. If James leaves we can't revoke his key > because it is HIS key. We can however revoke the dinstall key because it > is by definition Debian's key. But this is nitpicking. Who is Debian? Where is the safe where the secret key will be stored (as the keys from Microsoft are)? Who will be responsible for all this, and what makes you belief that those will be more careful about the key than James? The central authority doesn't mix extremely well with the distributed organization Debian is. Note that a signed Packages file works extremely well for a single cooperation who produces a Debian based distribution, or an individual. People keep forgetting about Debians nature, and this keeps bothering me. > You have started the child game. We want to make a simple change to apt as > dinstall and you keep telling us that it won't make things better. Now you > said that making things better but not perfect is not the Debian way of > doing things. Yes. Because the Debian installation tool is dpkg, and not apt. This is the second main point that I disagree with (aside of the security discussion, which is complicated and by now covered well). A solution for Debian should serve all people, those who use apt, those who use dpkg and downloaded files, those who use other methods (dselect etc). Thanks, Marcus
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 02:30:12PM -0600, Jason Gunthorpe wrote: > On Sun, 2 Apr 2000, Marcus Brinkmann wrote: > > > This is a seperate problem. I agree that this should not be the case, but it > > has no place in this discussion. If individual developer keys are > > compromised, we have a problem no matter what. Developers should not store > > secret keys on net connected machines, point. > > > > However, this only affects the developers packages, not the whole archive. > ^ > > GAH!? Don't you see that isn't true?? Look, a hack attempt would go like > this. > > 1) Break root on master > 2) Use that to break user account on developer victum (any will do) > (Hint: I have already shown that torsten at least could be > attacked quite easially) > 3) Steal PGP key > 4) Use stolen PGP to form new glibc package with trojan, sneak into > archive using #1 And it wouldn't be strange that random Joe is uploading a pgp package? And random joe or the real glibc maintainer will not speak up if this really happens? But you have a point, and I add this case: This only affects the developers packages and NMUs. (one could vaguely interpret a NMU as the developers package, as it is carrying his signature, but I admit that I didn't have NMUs in mind when writing this.) Thanks, Marcus
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 01:36:01PM +1000, Anthony Towns wrote: > > Debian *can* make this decision, because we know each other. Most users > can only go `James who?'. This is easily identified as a play with names. Who is this "Debian" person you refer to anyway? After all, behind every action is a developer. > And if he's already compromised your local mirror, and decides that no > one needs an updated debian-keyring, or any of those irritating bugfree > packages? This is free software after all. You can already make a mirror that only carries out of date packages. What sort of an attack is that supposed to be? > To reiterate: signed .debs don't cope with any of the following attacks: > > * Past/current developers doing nefarious things, especially if > they also manage to compromise your local link in the distribution > network. I still disagree (the details are spread over several mails of course). > * Vandalism against Packages files Can you explain this attack to us? > * Maliciously distributing the worst possible selection of valid > packages See above. Seems to be a "Free Software" attack to me. Maybe you should file a bug report against the GPL. (You didn't laugh? Sorry, but it was supposed to be funny :) > These attacks are all based on the fact that sometimes it's Debian as a whole > acting in concert that you trust, not any and all particular developers. A Debian as a whole does not exist. There exists an abstract incorporation, but that's it. The rest is a bunch of developers. I don't see the difference in trusting the key of James or some other Debian admin. I see a difference between a personal key and a key which is lying around on some net-connected machine. You are attempting to abuse the public key (PGP) protocol to verify a group as the ownership of something. This can't work, because it was not designed to cope with such a situation. You would need to use an entirely different cryptoprotocol to solve this. All problems I see (and you keep to sweep under the table) are a direct result from this. Instead, with signed debs, the PGP protocol is used exactly for what it was designed: A signature from an individual, not from a group. (Of course, you *can* have a key that is accessable to several people, for example for organizations, as Microsoft. However, those people have to share the location, and thus act like one abstract individual. That the same can't be true for Debian is obvious: We don't have a headquarter). One note: Of course this is not the case if the Packages file is signed locally by an indivual. But in this case, the analogy to the debian-keyring key is complete (only the technical details are different, and individual debs can't be checkd of course. ) > Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload. > (each .deb has to be signed separately, no matter which way you do it) There are solutions to this. (Read the pgp/gpg manuals). You can pass the phrase from other programs or the environment. As a side note, realize that the secret dinstall key can't be protected efficiently by a passphrase, because the phrase itself had to be stored and readable by dinstall. > Securing the way Debian distributes its software is a *long* way from > making it impossible for an attacker to compromise huge numbers of > Debian boxen. And is of course an orthogonal issue. Thanks, Marcus PS: I would like to meet this Debian person, he must be terrible shizophrene. ;)
Re: Intent To Split: netbase
On Mon, Aug 14, 2000 at 09:54:40PM -0500, Branden Robinson wrote: > On the other hand, fsck seems to be a good example of a program that can't > do much for the unprivileged user. That's not true. You can have disk image files you might want to check for correctness. In the Hurd, any user can boot a subhurd (a self contained system with its own critical server processes and root fs, much better than chroot) and wreck it. With fsck you can controll afterwards if the bug you traced down in the subhurd (with gdb from the parent hurd) was corrupting the filesystem. There are probably some emulators on Linux that will benefit from this as well. The distinction between sbin and bin is not a hard one. It is soft based on experience and the common case. It's also basically nonsense, because of the 2176 binaries in my path, I use a couple of dozen regularly, and having 300 further, even useless, binaries wouldn't distract me in any way. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
