Package priorities and dependencies.
I have been working on a prototype of a system to allow "Custom Systems" that can be installed "simply" with dselect. The approach has been to make a subdirectory, containing links into the archive for the packages that are needed by the "Custom System". The technique is working out fine, but I have discovered some problems with the distribution as a result of my experiments. I built one subdirectory (called importnt for DOS sake) containing links to all the packages is bo with the priority "important". This seemed like a good "foundation" to build on. Select subsets of "standard" can produce a system taylored for size and functionality. Two packages in the list of "important" refused to install because they declared (correctly) their dependence upon packages of lower priority. at depends on libelf0 priority: optional groff depends on libg++27priority: standard It seems to me that packages of any priority level should not be dependent upon packages of lower priority. This doesn't mean that at and groff should be removed from important. It does tell me that libelf0 and libg++27 should be priority: important, because they have important packages that depend on them. This tells me that libelf0 and libg++27 should have their priority field changed to "important". Does this make sense to anyone but me? Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
On Sun, 15 Jun 1997, Thomas Koenig wrote: > Dale Scheetz wrote: > > >Two packages in the list of "important" refused to install because they > >declared (correctly) their dependence upon packages of lower priority. > > > > at depends on libelf0 priority: optional > > This dependency isn't needed... hmm... > > For some reason, the configure script created by autoconf always > looks for -lelf and, if it can find it, adds it to the list of > searched libraries. > Probably because the author considered that this would make a better at. > First, why does my autoconf - generated configure search for -lelf and > then always adds it? IMHO, this is a bug in autoconf; I never asked it > to do that. It gets configured somewhere. Autoconf didn't come up with that on its own. > > Second, this is a bug in at; I'll uninstall the libelf binary from > the system I compile at on, so this doesn't happen again. That will > be fixed in the next release, although it's far from being a critical > bug :-) While I'm sure that removing libelf from the development environment will do what you suggest, I'm not sure that you either need or want to do that. The actually dependency is determined by dpkg-shlibdeps found in the rules file shortly before the package build. This actually interrogates the program file, given as a parameter, using ldd to determine which libraries it has been linked against the executable. These get added to the dependency field by dpkg-gencontrol just before the package is built. This means that the executable was, in fact, linked against libelf0. This implies some functionality, derived from those linked routines that the author, at least, thought of as beneficial. It is also entirely possible that removing them from the output of autoconf will fail to result in a viable executable (unresolved etc...) although many packages are designed to be built under differing conditions. This makes it possible that at will build without it just fine, but with reduced capability or speed of operation. Even if libelf0 only gives minor improvements in the package, the fact that the author intended to take advantage of that librarys capabilities where possible makes it desirable to keep it as a dependency. > > >This tells me that libelf0 and libg++27 should have their priority field > >changed to "important". > > In principle, you're right :-) Thanks for supporting the principle ;-) I guess I was pushing for more practical application of the principle in these two cases. Waiting is, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
On Sun, 15 Jun 1997, Clint Adams wrote: > > > Does this make sense to anyone but me? > > It seems unnecessary for shared libraries to have priorities if they're > useless without programs which depend upon them. > I don't see your point, and you seem to have missed mine. I was trying to point out that allowing dependencies to reach outside a packages priority has the potential to cause problems, specificly when package intallation is organized using the priority levels (as has been suggested in the past as a solution to several packaging problems) Once the base system (required packages) is installed, all the important packages should be capable of installation, followed by all standard, etc... The two dependencies I sited for the priority group important are a case in point. Luck, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
On Mon, 16 Jun 1997, Santiago Vila Doncel wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Sun, 15 Jun 1997, Dale Scheetz wrote: > > Two packages in the list of "important" refused to install because they > > declared (correctly) their dependence upon packages of lower priority. > > > > at depends on libelf0 priority: optional > > groff depends on libg++27priority: standard > > > > It seems to me that packages of any priority level should not be dependent > > upon packages of lower priority. > > I think this reasoning is wrong: We don't want to install libelf0 and > libg++27 because they are "important", we want to install them to satisfy > dependencies! The library itself is useless if no program uses it. > > So IMHO you should have added to your initial list of packages the ones on > which they depend, until all dependencies are satisfied. dselect does this > automatically. If you don't like it, it is supposed to be done by hand. > If this is true then there is no purpose served by priorities and they should be abandoned. THIS IS NOT THE CASE. As I understand it the priority scheme was designed to give a "horizontal" installation method. It was intended to provide another selection method for performing installation based on a "usefulness" criterion. I still argue that for this to continue to be useful it must continue to be modular in its design or it looses its usefulness. I firmly believe that dependencies should be provided within the same priority level or this organizational structure will fail to live up to the expectations for it. Later, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Need someone to take some of my packages.
I am finding myself with almost no time to spend on packages, coupled with a large project that I must deal with, leaves me without the resources to make code freeze on several of my packages. The one that is desperate for a new home is imap-4. I have never been able to adequately test this package. There are several outstanding bugs that I have been unable to come to terms with and for this reason alone the package would be better off in more skilled hands. If you have any interest in this package, please contact me for the details. The other two packages that I should find better homes for are; libident, and m4. Each of these packages have "minor" bugs reported against them and are not a maintainance problem. The also fall into the catagory of "relatively untestable" packages, and would fair better under someone elses care. Please contact me if you are interested in any of these packages. Waiting is, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
What, why, where, utmp?
One of my "gaping holes of ignorance" has to do with utmp entries; what they are, why are they gone, where is the package that creates them? I know that one of the latest "fixes" to dpkg-buildpackage deals with the lack of utmp entries, but don't understand why they were abandoned. I just discovered that the command "login" is supposed to log the user out and present a new login prompt. This command works ok if you are logged in as root, but when you try to use it as a user, you get a utmp entry missing error, with some statement about login only running from the base shell. So, if there is anyone out there who can explain the problem (and has the inclination) I would appreciate some education. A good reference would probably work as well. Thanks in advance, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bo -> hamm
On Fri, 5 Dec 1997, Santiago Vila Doncel wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Fri, 5 Dec 1997, Rainer Dorsch wrote: > > > I was wondering, if anybody has a package, which does the upgrade from > > Debian > > to hamm (probably a simple shell script is sufficient). > > > > If so, I would like to install this script and try the hamm distribution. > > If > > not, wouldn't it be worth to do it? > > Probably. > > There is no such script, as far as I know, but there is a wonderful > tool written by Manoj Srivastava, pkg-order. Using this package I think > it will be very easy to write a "script to upgrade the system". > > (BTW: Currently, this would be really more robust than using dselect or > following the libc6-mini-howto). > Well, there actually is a primative attempt of mine available in the /upgrades directory of any complete debian archive. It is called DoList. It was my first attempt at a perl program so it is relatively free of "perlisms" and very straight forward. It uses dpkg to install, or remove (depending on tags in the list), packages indicated in a list (from a pre-prepaired file) in the order that they appear on the list. This script was used successfully by me to do the "by hand" upgrade portion of both 1.1 and 1.2 upgrades (I was too busy with 1.3 and just did a fresh install..well, actually several ;-) There are example lists for the base section that installed those packages in the proper order. I always intended to create a list for the "standard" distribution but never found the time. With Manoj's pkg-order you will not need to worry about ordering your list by hand (something that wasn't available the first time I did this). Anyway, take a look at DoList and see if it will do the job. Luck, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RAS on an NT box.
I need to connect a Linux box to an NT server over a dial-up line. The NT box uses a "Remote Access Server". I remember seeing a discussion of this recently, but can't find the reference in my mail archives. Can anyone clue me in as to what package/howto I need to look at to deal with this? TIA, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RAS on an NT box.
On Sun, 14 Dec 1997, Philip Hands wrote: > > I need to connect a Linux box to an NT server over a dial-up line. The NT > > box uses a "Remote Access Server". I remember seeing a discussion of this > > recently, but can't find the reference in my mail archives. Can anyone > > clue me in as to what package/howto I need to look at to deal with this? > > You need to enable ms_chap in PPP --- see README.MSCHAP80 Thanks...read it. Is there any reason, besides the libraries that this hasn't been simply built into our standard ppp package? > > I am intending to make ppp generate a separate package (ppp-lite ?) so that I > can make the main package depend on libpam and libdes (needed for ms_chap) > without needing to put all that on the boot disks. > How much bigger does it get if you static link libpam and libdes? There are a growing number of ISPs and corporate nets that use NT RAS for their remote entry needs. I just got a request for information on RAS from one of my clients, as well as a request for help from one of the purchasers of my book. (both of these after I asked about this on the list...time just doesn't work like it's supposed to) > In the mean time, you'll need to grab the source and recompile it. > > BTW if ppp-lite gets installed on the boot disks, what do I need to do to > make > ppp get installed over the top of it --- is it just > > Replaces: ppp-lite > If fundamental components of the package are different, you will need a conflicts: field as well. This will let dpkg remove the lite package and replace it, in toto, with the bulkier ppp package > in the ppp package ? > > Cheers, Phil. > > P.S. I've never tried the NT RAS thing, so I'd like to hear how you get on. > One thing that is not mentioned in the docs is what to set in the options file to enable chap. It does talk about the two options required for ms-chap, but I assume that you also need chap enabled? Thanks for all the help, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
out for a week
I'll be out of touch for the week starting Sunday 21 December. Have a Happy and a Merry, or vice versa ;-) Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
On 1 Jan 1998 [EMAIL PROTECTED] wrote: > We need someone to do a non-maintainer upgrade of libc5-altdev, installing > the patch in David Engel's mail. I'm busy with boot floppies. Can someone > pretty please do this? I have been talking with David about helping out here. I'll take a look at his patches this weekend and see if I can get something out. > > Also, it looks to me as if libc6 depends on versions of kernel-headers > and kernel-source that are _not_ in hamm at the moment. > This is truely bothersome. I'll see what I can come up with. I will be relying on David's input until I get up the learning curve some, but our preliminary discussions indicate we are at least thinking on the same page. Do I need to let anyone else know what I'm doing? (the various intermediate maintainers) Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: need libc5 non-maintainer upgrade
On 2 Jan 1998 [EMAIL PROTECTED] wrote: > It looks as if Richard has taken care of libc5, and libc5-altdev doesn't > need a change. Dale, did you do the ae-using-slang upload? I'm going to > need that soon. > I've been out of town, and just got back this evening. I already have the patches, (got them before I left) but haven't integrated them yet. I hope to get to it this weekend. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: gmp_2.0.2-3.deb in hamm/devel ?
On Fri, 2 Jan 1998, Gregor Hoffleit wrote: > Pardon my ignorance, but why is there an gmp_2.0.2-3.deb in hamm's devel > directory when we have gmp2_2.0.2-4.deb in hamm/libs ? > As the maintainer, I have no idea. I uploaded both gmp2 and gmp2-dev and they are both where they belong. gmp2 will conflict with and remove gmp, so there really is no problem, but I guess you could make this a bug report against ftp.debian.org... Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Pre-processor "Manifest Constant"
Does the gcc preprocessor have any such constructs as "manifest constant"s? The coherent C compiler used several such items to insert date/time into the compiler output, among others. These seem to be either pre-declared values, or function calls that actually interigate the system and leave output for the preprocessor to deal with. I am pretty sure that the term "manifest constant" is not used in Linux, but I'm not informed enought to know what other term might be used. Any pointers to the docs would be greatfully accepted. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Pre-processor "Manifest Constant"
On Sun, 4 Jan 1998, Richard Braakman wrote: > I think you can find what you want in the cpp info file, node > "Standard Predefined". It lists macros like __DATE__ and __TIME__. > > gcc itself also defines __FUNCTION__ and __PRETTY_FUNCTION__, which > behave more like string constants and can not be used in preprocessor > directives. > Thanks, that's exactly what I needed to know! Much appreciated, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New Maintainer for libc5/libc6
I have been "speaking" with David Engel about the current problems with libc5 and libc6. I have agreed to take over these packages (with a boost up the learning curve from David) and become their maintainer. While I am not as informed as I would like to be, as to the inner workings of these libraries, it is time for me to learn what I can about their construction and installation. While this makes me an inferior candidate in some ways, I have been the only one to respond to David's frustrations finding help with these packages. If anyone else has a more pressing need to maintain these packages, now is the time to step forward. If I hear no objections, I will work toward applying David's patch and getting a new release of libc5 out ASAP (hopefully before the end of the week). My goal is to get a libc5 that can be installed on a bo system and allow a clean upgrade path to libc6. Any and all help will be appreciated, so don't hesitate to comment if you think it will help. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Question/request concerning master
On Mon, 5 Jan 1998, Ben Pfaff wrote: > Firstly, there is this: > > blp:/raid/home/blp$ ftp master > Connected to master.debian.org. > 220-This system is for internal use by the Debian developers. It is not > 220-open to anonymous FTP. Please use ftp.debian.org or one of its many > 220-mirrors. > 220- > 220 debian FTP server (Version wu-2.4(14) Wed Jan 8 21:17:19 MET 1997) > ready. > Name (master:blp): pfaffben > 530- > 530-Sorry, there are too many anonymous users using the system at this > 530-time. Please try again later. There is currently a limit of 10 > 530-anonymous users for your domain group. > 530- > 530 User pfaffben access denied > Login failed. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> quit > 221 Goodbye. > blp:/raid/home/blp$ > > Why am I considered an anonymous user?! I suspect the error message of being a "fall through". I just tried the same route and was rejected. In the past this has been because someone has disabled ftp on master, and it usually clears up soon. You should still be able to telnet into master and then ftp from your site to master. > > Secondly, could the lftp program be installed on master? It's nicer > than ftp, and it's freer than ncftp. > Can't speak to this one ;-) Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
On Mon, 5 Jan 1998 [EMAIL PROTECTED] wrote: > On Mon, Jan 05, 1998 at 12:30:09PM -0500, Dale Scheetz wrote: > > If anyone else has a more pressing need to maintain these packages, now is > > the time to step forward. If I hear no objections, I will work toward > > applying David's patch and getting a new release of libc5 out ASAP > > You did notice the updated versions of this patch posted in the "need libc5 > non-maintainer upgrade" thread, didn't you? > The patch I intend to use comes directly from David. Any changes to that patch need to be discussed before I will add them to the package. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 5 Jan 1998, Michael Alan Dorman wrote: > Christian Schwarz <[EMAIL PROTECTED]> writes: > > How about this: > > > >``Whenever the source package is changed WRT to the last uploaded > >version, its version number has to be incremented. In addition, if > >the source package is not changed but the binary package changed > >(because it has been recompiled in another environment), the version > >number has to be incremented too (this is, the source package has > >to be changed and uploaded again) to make sure dpkg/dselect recognizes > >the changed package.'' > > > > Any comments are welcome. > > Looks good to me. > I'm a bit confused by the context of these comments. What is being solved here? It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. All debian changes are reflected in the diff file produced by dpkg-buildpackage. Any changes to the debianized source (even a simple change in the dependencies) should create a new and unique version of the .deb .changes .dsc and .diff files, none of which requires either changing or uploading source files. What am I missing here? Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Mon, 5 Jan 1998, Dale Scheetz wrote: > > > It was my understanding that the only time it is necessary to upload a new > > source package was when the upstream source changed. > > Here, "source" means "Debian source", i.e. orig source + diff. > In fact, you upload a new "Debian source" each time you upload a new diff. > > We are trying to clarify what happens when you just "recompile" a package. Then we are still discussing "non-maintainer uploads/version numbering". In that case I find the paragraph to be ambiguous, confusing, and not to the point. If there is a reason to upload a new .deb package then that alone is sufficient to require an incremented version number. Every "new" release of a package should come with a "new" version. Only if an md5 sum of the "new" package is identical to that of the old would the version remain the same. In that instance there is no reason to upload the new file. Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Mon, 5 Jan 1998, Dale Scheetz wrote: > > > > > Then we are still discussing "non-maintainer uploads/version numbering". > > In that case I find the paragraph to be ambiguous, confusing, and not to > > the point. > > Maybe, but the official maintainer should also be able to do a recompile > of his own package :-) Why do you think we are still discussing > "non-maintainer" uploads? > I don't know ;-) that's why I got into the discussion. I had thought that we decided to add point numbers to the "debian" release increment, so a non-maintainer upload of ae_962-17 would be numbered ae-962-17.1 allowing the maintainer to do a -18 upload without confusion. This is, however, a different issue from, "when do I change the version number", isn't it? Any binary package upload that differs by a single bit from the previous version should be provided with a new version number. At the very least, a change in the packages used to build said new package should result in new information in the change log, asside from the resultant changes to the binary. These are each sufficient to create a new version. What have I missed? Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
On Mon, 5 Jan 1998, Richard Braakman wrote:
> Dale Scheetz wrote:
> > The patch I intend to use comes directly from David. Any changes to that
> > patch need to be discussed before I will add them to the package.
>
> Can you post the patch to debian-devel? As far as I know it has not
> yet been made clear exactly which patch we're talking about.
>
I only did a cursory look at the patch you sent, but it looks similar to
the one I will be using.
Here is what David sent me...
diff -urN libc-5.4.38.orig/debian/changelog libc-5.4.38/debian/changelog
--- libc-5.4.38.orig/debian/changelog Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/changelogMon Dec 29 17:05:58 1997
@@ -1,3 +1,9 @@
+libc (5.4.38-0.2) unstable; urgency=low
+
+ * Build -dev and -dbg packages to make Scott Ellis happy.
+
+ -- David Engel <[EMAIL PROTECTED]> Mon, 29 Dec 1997 17:05:58 -0600
+
libc (5.4.38-0.1) unstable; urgency=high
* new upstream version (fixes #15340)
diff -urN libc-5.4.38.orig/debian/config.i386 libc-5.4.38/debian/config.i386
--- libc-5.4.38.orig/debian/config.i386 Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/config.i386 Mon Dec 29 17:14:31 1997
@@ -1,8 +1,8 @@
STATIC_SHARED=
MAKE=make
SPEED=fast
-HOST_ROOTDIR=/usr/i486-linuxlibc1
-HOST_BINDIR=/usr/i486-linuxlibc1/bin
+HOST_ROOTDIR=/usr
+HOST_BINDIR=/usr/bin
TARGET_ROOTDIR=/
TARGET_MACHINE=i486-linuxlibc1
TARGET_OS=linux
diff -urN libc-5.4.38.orig/debian/control libc-5.4.38/debian/control
--- libc-5.4.38.orig/debian/control Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/control Mon Dec 29 17:47:18 1997
@@ -12,8 +12,6 @@
These libraries are modified to make them work better in a libc6
environment.
PRE-DEPENDS: ldso (>=1.7.14-2)
-DEPENDS: libc6 (>=2.0.4-1)
-CONFLICTS: libc5-dev, wg15-locale, locales (<<2.0.4-1)
ARCHITECTURE: any
PACKAGE: libc5-altdev
@@ -24,7 +22,6 @@
libraries. This package can be used to build libc5-base binaries
even when the libc6-dev package is installed.
DEPENDS: libc5 (=${Source-Version})
-CONFLICTS: libc5-dev
ARCHITECTURE: any
PACKAGE: libc5-altdbg
@@ -35,5 +32,13 @@
This package can be used to debug libc5 even when the libc6-dev package
is installed.
DEPENDS: libc5-altdev (=${Source-Version})
-CONFLICTS: libc5-dev
+ARCHITECTURE: any
+
+PACKAGE: libc5-dev
+SECTION: oldlibs
+PRIORITY: standard
+DESCRIPTION: The Linux C library version 5 (dev files).
+ Includes libc headers, kernel headers (v2.0.29) and static
+ libraries.
+DEPENDS: libc5 (=${Source-Version})
ARCHITECTURE: any
diff -urN libc-5.4.38.orig/debian/control.hamm libc-5.4.38/debian/control.hamm
--- libc-5.4.38.orig/debian/control.hammMon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/control.hamm Mon Dec 29 20:22:07 1997
@@ -12,8 +12,6 @@
These libraries are modified to make them work better in a libc6
environment.
PRE-DEPENDS: ldso (>=1.7.14-2)
-DEPENDS: libc6 (>=2.0.4-1)
-CONFLICTS: libc5-dev, wg15-locale, locales (<<2.0.4-1)
ARCHITECTURE: any
PACKAGE: libc5-altdev
@@ -24,7 +22,6 @@
libraries. This package can be used to build libc5-base binaries
even when the libc6-dev package is installed.
DEPENDS: libc5 (=${Source-Version})
-CONFLICTS: libc5-dev
ARCHITECTURE: any
PACKAGE: libc5-altdbg
@@ -35,5 +32,13 @@
This package can be used to debug libc5 even when the libc6-dev package
is installed.
DEPENDS: libc5-altdev (=${Source-Version})
-CONFLICTS: libc5-dev
+ARCHITECTURE: any
+
+PACKAGE: libc5-dev
+SECTION: oldlibs
+PRIORITY: standard
+DESCRIPTION: The Linux C library version 5 (dev files).
+ Includes libc headers, kernel headers (v2.0.29) and static
+ libraries.
+DEPENDS: libc5 (=${Source-Version})
ARCHITECTURE: any
diff -urN libc-5.4.38.orig/debian/rules libc-5.4.38/debian/rules
--- libc-5.4.38.orig/debian/rules Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/rulesMon Dec 29 17:05:12 1997
@@ -103,8 +103,8 @@
mv dev-tmp/usr/lib/libg.a dev-tmp/usr/lib/libc_p.a dbg-tmp/usr/lib
install -d alt-tmp/usr/$(aa)-linuxlibc1
install -d altdbg-tmp/usr/$(aa)-linuxlibc1
- mv dev-tmp/usr/* alt-tmp/usr/$(aa)-linuxlibc1
- mv dbg-tmp/usr/* altdbg-tmp/usr/$(aa)-linuxlibc1
+ cp -a dev-tmp/usr/* alt-tmp/usr/$(aa)-linuxlibc1
+ cp -a dbg-tmp/usr/* altdbg-tmp/usr/$(aa)-linuxlibc1
#
install -d run-tmp/usr/doc/$(p)
ifeq ($(dist),bo)
@@ -188,7 +188,7 @@
dpkg-name -o -s .. locale-tmp.deb
touch binary-locale
-binary-hamm: build debian/utmp-conv binary-arch binary-alt
+binary-hamm: build debian/utmp-conv binary-arch binary-alt binary-dev
binary-bo: binary-arch binary-locale binary-pic binary-dev
Later,
Dwarf
--
_-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED]
Re: What's Debian's /usr/src policy
On Mon, 5 Jan 1998, Ian Jackson wrote:
> I think that /usr/src should the be domain of the local admin.
>
> I don't think kernel-{header,source}-x.xx.deb should exist, really,
> because I don't think source code should be distributed as .deb files
> anyway. So I'm not unhappy about making a policy decision that leaves
> kernel-{header,source} with nowhere good to go.
I never understood why the kernel source was made into a .deb package. It
doesn't make sense to me. I also don't see any point in "managing" a
binary package of the kernel either. The system doesn't gain anything by
having dpkg know which kernel binaries are installed either. The binary
thus installed still needs to be configured for lilo or loadlin or grub,
so what's the point?
The short form...I agree with Ian here. We need to rethink how this should
work. For instance, I keep my kernel sources in /usr/local/src/linux and
never install the kernel packages unless required by circumstance.
>
> Why does libc6 depend on kernel-header ?
I don't know either, but it is on the top of my list of things I need to
understand as the new maintainer. It was my understanding that the way we
deal with kernel headers was supposed to free the c library from the
headers. I don't know that anything has changed in that reguard. I'll let
you know what I find asap.
Waiting is,
Dwarf
--
_-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On 6 Jan 1998, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Dale Scheetz) wrote on 05.01.98 in <[EMAIL PROTECTED]>:
>
> > On Mon, 5 Jan 1998, Ian Jackson wrote:
> >
> > > I think that /usr/src should the be domain of the local admin.
> > >
> > > I don't think kernel-{header,source}-x.xx.deb should exist, really,
> > > because I don't think source code should be distributed as .deb files
> > > anyway. So I'm not unhappy about making a policy decision that leaves
> > > kernel-{header,source} with nowhere good to go.
> >
> > I never understood why the kernel source was made into a .deb package. It
> > doesn't make sense to me. I also don't see any point in "managing" a
> > binary package of the kernel either. The system doesn't gain anything by
> > having dpkg know which kernel binaries are installed either. The binary
> > thus installed still needs to be configured for lilo or loadlin or grub,
> > so what's the point?
>
> Well, handling kernels with kernel-package is _a_lot_ easier than doing it
> by hand. I've done both, and I don't want to go back, ever.
I'm sorry, but my experience has been very different. I too have tried
both. Maybe my timing has been poor, but both times I tried there was a
mismatch between the kernel-package package and the kernel-source package
and after much futsing around resulted in failure.
Kernel source should be provided the way we provide source for all other
packages. You should be able to unpack it with dpkg-source -x and run
dpkg-buildpackage and build a kernel to your spec and construct a .deb
package from that result. (Note, I have no real problem with a
kernel-binary package, although personally I would have no use for it, I
can understand others point of view in wishing to "manage" their kernels
with dpkg)
>
> > > Why does libc6 depend on kernel-header ?
> >
> > I don't know either, but it is on the top of my list of things I need to
> > understand as the new maintainer. It was my understanding that the way we
> > deal with kernel headers was supposed to free the c library from the
> > headers. I don't know that anything has changed in that reguard. I'll let
> > you know what I find asap.
>
> I think our main problem here is that people (including both you and Ian)
> don't keep on top of debian-private and debian-devel.
I can't speak for Ian here, but I am a constant reader and participant on
both these lists. Your implication is both unfair and has nothing to do
with the technical discussion.
>I can't count the
> times this has been explained already, and I get very, very tired of it.
>
I am sorry for your exaustion. I am capable of counting, but what is the
point. The reason this keeps coming up is that, so far, all explanations
have been inadequate.
> libc6 depends on a specific version of kernel-headers to avoid including
> what is in that package as a diff. Nothing more, nothing less.
>
This exaplanation is inadequate as well. While shrinking the size of a
diff file helps the developer who pays by the byte/minute for access, it
creates a problem for the user which is not necessary. Forcing the
coupling of two packages via depends when the two packages are only used
together makes installation and upgrades one step more complex than is
necessary in a way that adds to package bloat when it isn't necessary.
(BTW it's libc6-dev that is coupled to kenrel-headers)
Still unconvinced,
Dwarf
--
_-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On Tue, 6 Jan 1998, Hamish Moffatt wrote: > On Mon, Jan 05, 1998 at 05:48:27PM -0500, Dale Scheetz wrote: > > I never understood why the kernel source was made into a .deb package. It > > Because it's something we expect people will want to recompile, > so we should make it readily available to them. A proper source package (.diff, .dsc, and orig.tar.gz) is smaller, and the user can get the orig.tar.gz from other sources, making the download from Debian trivial. How is this less "readily available"? > > > doesn't make sense to me. I also don't see any point in "managing" a > > binary package of the kernel either. The system doesn't gain anything by > > having dpkg know which kernel binaries are installed either. The binary > > thus installed still needs to be configured for lilo or loadlin or grub, > > so what's the point? > > I think it does gain something; it is much easier to have multiple > versions around. If I compile a new 2.1 kernel and find that > it is not too good (like 2.1.76 seems to have broken sound > for me so I went back to 2.1.72), I can just reinstall the old > one with dpkg. I don't need to edit my lilo config, play with > symlinks in / etc. > When I try a new kernel and it doesn't work, I only have to edit lilo.config an run lilo to get back to the old one (actually I always leave hooks in lilo to get back to the "old" kernel). No package installation is required. I will also never feel comfortable with an automatic process editing my lilo.config file. I am set up to boot several linux partitions as well as a dos partition and a loop-root system. I am much happier editing that beast myself thankyou ;-) Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: please upgrade your packages to current standards
On Tue, 6 Jan 1998, Richard Braakman wrote: > Do we want all packages to include the Section and Priority fields? Probably. > > If so, then I think it is far more effective to change dpkg's default > behaviour so that it does include these fields, rather than requiring > an explicit flag -isp. > Dpkg can't put them in if the information is not available in the control file. > However, I don't know the history behind this. What is the reason for > not including Section and Priority by default? > I believe that if you put section and priority fields in the "package" section of the control file, dpkg puts them into the control file for the package. How would dpkg be able to do this by default without knowing all the section and priority values for all packages? These were thought to be unnecessary (from the developers point of view) because the installer on master (from the overrides file) inserts the correct values into the packages and contents file dispite what the control file might say. With my "user" hat on, I like having the package contain these fields, as I typically use mc to dive into a new .deb file to see what it contains. The INFO file thus provided is more informative if it contains section and priority information. As a developer, I have already begun to put these fields into my packages. The feedback I get from the installer is useful if we disagree on location because I can then discuss it. This allows packages to be "relocated" if there is a place where users are more likely to look. Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On 6 Jan 1998, Rob Browning wrote: > Dale Scheetz <[EMAIL PROTECTED]> writes: > > > I will also never feel comfortable with an automatic process editing my > > lilo.config file. I am set up to boot several linux partitions as well as > > a dos partition and a loop-root system. I am much happier editing that > > beast myself thankyou ;-) > > Dale, I think you must misunderstand how kernel-package works. It > never touches your lilo.conf file. You just have to have entries > pointing to /vmlinuz and /vmlinux.old, and then it just runs lilo in > the postinst. All of kernel-package's work wrt lilo is confined to > updating the /vmlinuz and /vmlinuz-old pointers. Which means that it will not work at all with my configuration. My lilo.conf calls out kernels explicitly from /boot where I can keep as many, or as few kernel images as I please, file system size permitting. > > I think other people have sufficiently covered the other advantages of > kernel-package, but I'll add that your suggested solution of just > using kernel-source doesn't work if you want to use *today's* kernel > today. I don't see why not? Simply take the debian diffs and apply them against *today's* kernel and you are off and running. The kernel file organization hasn't changed in ages. (I hope that doesn't mean that someone will change it simply because it is old and stable ;-) > > Also, I've witnessed someone else, who doesn't want to use > kernel-package (which is fine) leave their system unbootable by > forgetting to run lilo after a manual install. That's impossible if > you use the .debs. > Nothing is impossible ;-) This is clearly a "different strokes" issue. I'm sure there will be two sides to this discussion for the indefinite future. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: please upgrade your packages to current standards
On Wed, 7 Jan 1998, Richard Braakman wrote: > Dale Scheetz wrote: > > On Tue, 6 Jan 1998, Richard Braakman wrote: > > > Do we want all packages to include the Section and Priority fields? > > > > Probably. > > > > > > If so, then I think it is far more effective to change dpkg's default > > > behaviour so that it does include these fields, rather than requiring > > > an explicit flag -isp. > > > > > Dpkg can't put them in if the information is not available in the control > > file. > > But it doesn't put them in, even if the information is in the control > file, unless you give it the -isp flag. You are correct. I was confused...the gmp2 package includes these fields in the "package" paragraph of the master control file, and they are also in the packages control file. Other packages of mine, like diff only have these fields in the "source" paragraph, and they don't appear in the package. I mistakenly assumed that this was the only difference, but the gmp2 package, on closer inspection, does use the -isp flag with gencontrol, so that was the "real" reason. I believe that if these fields are provided in the "package" paragraph, that dpkg should automatically include them in the control fields for the package. On the other hand, what's 4 characters in the rules file cost? Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1998-01-07
On Wed, 7 Jan 1998, Richard Braakman wrote: > This is a list of packages in the main distribution that need work to > be fully libc6-based. I base it on the Packages file at my local mirror, > so it may be a day or two out of date. If you have questions about why > a particular package is on the list, or if you think there is an error, > don't hesitate to contact me. > > Dale Scheetz <[EMAIL PROTECTED]>: > imap-4-4-4 > Memory says that someone else took over this package...but I can't remember who. I'll look over my archives and see if I can figure it out. If you remember who you are ;-) let me know how it's going, or something. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On Wed, 7 Jan 1998, Turbo Fredriksson wrote: > On Tue, 6 Jan 1998, Dale Scheetz wrote: > > > I am set up to boot several linux partitions as well as > > a dos partition and a loop-root system. I am much happier editing that > > beast myself thankyou ;-) > > A loop-root? > With a small patch to the kernel and some modification of the loop device code, you can create a file-system-in-a-file. Using the loop device the internal file system can be mounted as the root file system for the kernel. These patches were never adopted by the kernel, and it is getting harder and harder to apply them, so I currently use a patched 2.0.27 kernel to boot that system. I provide this monstrosity as "Drop in Debian", configured to provide a platform on a DOS machine sufficient to building a custom kernel. The concept is easily expandable to take over whatever disk space you have available ;-) The one I boot with lilo is on an ext2 partition (another beauty of the imbeded file system, it can be coppied to almost any other file system). Interesting point: on an ext2 file system, no care need be taken. On a DOS file system the file system must be un-fragmented (using dfrag) before the DiD installation will work properly. The funny part of this is that it doesn't matter whether you do the dfrag before you copy the file system, or afterwards, it still works. Without it you get file system errors. This was an interesting concept when I first ran into it, but the need for it is slowly going away. I keep the one file system around for testing purposes, as it's easy to make a back up copy of the system, do testing...destroy the file system completely, and recover to the initial state by simply copying the backup file over the broken one. Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: please upgrade your packages to current standards
On Wed, 7 Jan 1998, Richard Braakman wrote: > Dale Scheetz wrote: > > > I believe that if these fields are provided in the "package" paragraph, > > that dpkg should automatically include them in the control fields for the > > package. > > So do I. I don't see any reason why it should not. > > > On the other hand, what's 4 characters in the rules file cost? > > Well... I can think of a couple of costs :-) > > - All maintainers have to go check their rules files and add this flag. This is a good thing. I encourage everyone to periodically look at the rules file for each of your packages. I keep a check list of these sorts of issues that I go over when I make a pass at my packages. Admittedly just because I do it this way doesn't mean it's the best way for everyone. (or even for me ;-) > - Inevitably, many will forget or won't notice, so someone will have > to spend time filing bug reports and chasing after maintainers. Sounds like a lot of exercise (with all that chasing) which is something I could use more of ;-) > (Consider how long it's taking to get the changelog and copyright > files named right in all packages) It is interesting that you choose this example. I saw that as one of the most positive uses of the bug tracking system for the year 1997! All funnies aside, the bug tracking system is *the* method for resolving such issues, whether the bug report is against dpkg or the packages that fail to provide fields is another matter. I would say that if you submit a bug against dpkg *and* all packages that don't provide it, it is even money as to which solution will be implemented first, but closure will eventually happen. > - It will be one more thing that new maintainers can get wrong about > a package. We should have a list ;-) While I admit that unnecessary complication causes unecessary error. This is all "pretty well" documented, and as changes happen (like new policy) the documentation should be made to properly track those changes. (we are actually doing a much better job in this arena than we have historically and this causes a problem in itself) As a "not so new" maintainer, the recend changes in the documentation have made it harder for me to keep track of "what the current policy" actually is. I read the packaging guidelines from cover to cover when they first came out, and used that information to convert my packages to the new source format. I found that task quite straight forward, at the time, and still find package construction to be a very clean process (without any helpers thankyou...). Only by watching discussions like this, on the lists, and making an "action item list" from those discussions, can I hope to keep my packages "up to date". The fact that I fall behind, and miss things on the lists (dispite my best attempts) makes me more and more reliant on the bug tracking system to keep me in line on these issues. *** What we need first is a policy statement on the issue (policy statements should not declare implimentation details unless absolutely necessary) so that bugs can be filed against dpkg and packages that don't already supply the new policy. Looking back over the last statement, I find that I have fallen into "the policy" trap myself. That is, it is a trap to use policy to dictate bug reports. I heard someone say recently that all bug reports should quote the paragraphs in the policy document that qualify/quatify the bug. The implication here is that the only valid bug report is one based on our policy statements, which completely ignores "brokenness" issues, as well as other reasons for bug reports. I would clarify the statement with "only if the bug is addressed by Debian Policy..." Given that, I guess the quickest approach would be to file a bug against dpkg and begin policy discussions. That should give most of us time to impliment the new policy before it is declared ;-) and those of us who don't get to it can recieve bug reports. If the dpkg maintainer agrees that it should get fixed soon and has the time to work on it, we may even see dpkg deal with the problem seamlessly. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: loop-root (was What's Debian's /usr/src policy)
On Wed, 7 Jan 1998, Adam P. Harris wrote: > > [You (Dale Scheetz)] > >On Wed, 7 Jan 1998, Turbo Fredriksson wrote: > >> A loop-root? > > >With a small patch to the kernel and some modification of the loop device > >code, you can create a file-system-in-a-file. > > You can do this already in stock debian (rex and hamm) with > mount -o loop -t > > Why do you need to patch the kernel for this? So that the kernel can perform this mount process for it's root file system. It includes recognition of the kernel parameter "loop=" and configuration entries for enabling/disabling the feature. > > >Using the loop device > >the internal file system can be mounted as the root file system for the > >kernel. These patches were never adopted by the kernel, and it is getting > >harder and harder to apply them, so I currently use a patched 2.0.27 > >kernel to boot that system. > > Why do you have to patch the kernel at all? I already have this > funcationality w/ initrd. Again, this is on an upatched 2.0.30 and 2.0.32 > kernels. > This process moves the file system into ramdisk, limiting the size of the root file system, although there is also the possibility of mounting such a file on that minimal ramdisk using the mount command you referenced, it still requires some ramdisk. The loop-root doesn't. > BTW, I use it on my custom-rolled boot floppies for debian booting off a > floppy for a laptop which runs an initrd w/ cardmgr on it so I could get > PCMCIA subsystem up and play with NFS-mounting root. I have a little make > file which makes a pretty complete but small initrd file system (using > mount -o loop) complete w/ shared libs etc, even ash. It all works, at > least to the extent that NFS-root works well at all (which is not much but > I haven't gotten around to pestering Joost about it). > This is exactly what initrd is intended to allow. > Alternatively you could use the ramdisk and just mount root in the same > basic fashion (although initrd is a little different -- not much really). > See above. > >The one I boot with lilo is on an ext2 partition (another beauty of the > >imbeded file system, it can be coppied to almost any other file system). > >Interesting point: on an ext2 file system, no care need be taken. On a DOS > >file system the file system must be un-fragmented (using dfrag) before the > >DiD installation will work properly. The funny part of this is that it > >doesn't matter whether you do the dfrag before you copy the file system, > >or afterwards, it still works. Without it you get file system errors. > > Never noticed this issue on my 'mount -o loop' and initrd scheme. Using > SYSLINUX to boot I think. > Only happens on a DOS file system, and, depending on the degree of fragmentation of the partition, doesn't always happen there. You probably aren't supporting such a system on a DOS partition. Luck, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian 2.0 release requirements
On Wed, 7 Jan 1998, Christian Schwarz wrote: > All applications registered to menus > > The menu package included in the Debian distribution stores > information about which applications are installed on the system > and provides this data for X11 window managers or text-based menu > programs like pdmenu. With that, the user always has up-to-date > application menus, no matter which packages are installed or which > menu program is used. > This one is new to me...I have been waiting for the menu system to stabalize. I guess this means that it has? Is there a description in the Policy Manual? More important is there a good example of how to impliment this and will it make it into the Programmers Manual? Thanks, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
custom bo problems
I have been trying to create a "more up to date" bo custom disk and have run into a snag. I added the .32 kerenel from hamm to the packages and installed the kernel and its modules on the rescue and drivers disks. When I go to install, the resc and drv disks seem to get loaded ok, but when I go to configure the drivers modconf says there are no modules. (I did tar up the lib/modules directories just like what was there) Is there something special I need to tell modconf to make it recognize the new modules? Thanks in advance, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian logo license still not resolved
year from the date of issue to distribute any pre-existing > inventory of a physical medium (such as a book or CD, or > advertising that has already been printed) containing the logo. > 5.3. You must not have been given notice (on or before the date of > issue) by SPI that this automatic licence is not available to you. > > 6. Indemnity > In the event of a legal dispute between you and SPI, you agree to > indemnify SPI against any legal fees and penalties. > > If the rights granted by this license are not appropriate for your > product, you are encouraged to contact SPI to negotiate an individual > license. > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > > Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide"_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copying hard links.
On Tue, 7 Apr 1998, Roman Hodek wrote: > > > I just tried to use tar to copy one of my CDs with hard links back onto > > the hard disk. I did a cd to that archive, and ran: > > > > tar -c /cdrom | tar -xv > > > > Which created seperate inodes for the file and its hard link, blowing the > > 600 meg up to about 900 meg. This is the same result as with cp -a. Have I > > left something out? > > Does the iso9660 fs actually support hard links?? Ok, it supports > sharing data between files simply by mapping the same blocks, but it > doesn't tell the user about this fact. I guess tar simply can't see > that there are hard links... > I just checked with ls -i, and the inodes are not the same for the file in binary-i386 and its msdos file. This probably explains why none of the utilities recognize them as hard links. (they were definitly hard links on the archive that I built the CD from) It seems that ISO9660 deals with this differntly, unless it is a bug in mkisofs? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Aiding the constitutional procedure [was Re: Automation of the constitutional procedure]
On Wed, 8 Apr 1998, James A.Treacy wrote: > This seemed a natural and orderly extension of implementing the > constitution. If Ian feels that this is unacceptable for some > reason, I will make a formal amendment to the constitution > stating that it be allowed. > While I agree with the merrits of your previous arguments, I don't see what this has to do with the constitution. The secretary has "powers" which allow the secretary to execute that office. I would prefer that such issues be left of to the secretary to decide. If there is a need for automated processes, the secretary only needs to decide that it is necessary. The constitution should be a minimal document. If we specify every possible action by each officer and member, the document will get very large, and even more confusing than it is now. I would suggest that when an officer is given the power to execute their office, that is all the constitution need declare. It is then the responsibility of the office holder to define how the office will be administered. Giving detailed descriptions of what is "the right way" to do this task is, in the long run, counter productive. Remember the KISS principle. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NPR piece on Linux
I just got a call from a friend who said they had just heard that NPR was doing a piece on Linux. It should be on right after the news, so I hope this gets through the mail server pretty fast ;-) Later, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: egcs and libc6-dev
On Wed, 8 Apr 1998, Nuno Ferreira wrote: > Is there any reason for libc6-dev to depend on gcc and not on any > c-compiler ? > As it is now I can't keep egcs as my only compiler without breaking > dependencies. Either libc6-dev should depend on c-compiler or egcs provide > gcc. Am I missing something here?? Several somethings. Most important: it is still difficult to get egcs and gcc to reside on the same machine in a friendly manner (some directories and files are in the same place, some are not) Secon most important: gcc is the compiler that currently builds the distribution. While egcs currently seems to have better C++ support than gcc does at the moment, development proceeds on both, but until they can work together better, using them both is a problem. When either of these compilers can be used to build the distribution without large problems, then the advance to using "c-compiler" as a virtual package will become possible. If you really want egcs on your machine and don't want gcc, you can probably safely force the installation of libc6-dev (or egcs, which ever gets the complaint) This is currently to much of a can of worms to allow the change in libc6-dev at this point. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NPR piece on Linux
OK, it has played here in the East. Those of you out west still have some time to find a radio ;-) I think it is the second piece on "All Things Considered" after the news. This was a very good presentation for a public forumn. They pointed to all the right facts; talked about Linux clusters outperforming supercomputers, along with the fact that nothing M$ produces come close to the perfomance. They let Linus have a lot of personal air time, and he said all the right things (of course). Even Richard S. got a spoken line or two. I was impressed by the factual quality of the presentation. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies package
On Thu, 9 Apr 1998, Nathan E Norman wrote: > Hello, > > We have a ton of older PS/2 MCA machines around here, many with ESDI > disks, others with the IBM SCSI HBA. Neither ESDI nor the IBM HBA are > supported by the current rescue disks. > > So, in a not quite right state of mind, I decided I would make some boot > floppies so that my coworkers, and anyone else with PS/2s out there > could make use of my work rather than hack through the installs (the > usual method) > > However, the boot-floppies system has got me confused. I'm not a > Makefile wizard, so digging in there is a bit tough. The documentation > is otherwise quite sparse (it says "Edit the variables in the Makefile" > :) > > Here's the problem ... I need to use a special kernel image. How do I > tell boot-floppies to use it? If I give it the path to my kernel-image > package, it bombs out saying "I don't know how to make > which is required by linux ..." which isn't too > meaningful to me. Doesn't it just want to unpack the kernel-image deb? > I'm confused. > > I really don't need to remake the entire boot-disk set, just the rescue > disk and the drivers disk. Someone want to slap me and set me straight > here? > If all you need to do is put a different kernel on the rescue floppy (which is what it sounds like) simply take the delivered image, mount it, and copy the kernel image from your custom package (the vmlinuz file) to the file "linux" on the mounted image. You can either dd the image to a floppy, mount the floppy (msdos) and copy the kernel, or you can mount the image file with one of the loop devices and do the replacement to the image file. Any future copies of that image file will have the new kernel. HTH, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies package
On Thu, 9 Apr 1998, Nathan E Norman wrote: > On Thu, 9 Apr 1998, Dale Scheetz wrote: > > : On Thu, 9 Apr 1998, Nathan E Norman wrote: > : > : > Hello, > : > > [ snip ] > : If all you need to do is put a different kernel on the rescue floppy > : (which is what it sounds like) simply take the delivered image, mount it, > : and copy the kernel image from your custom package (the vmlinuz file) to > : the file "linux" on the mounted image. > : > : You can either dd the image to a floppy, mount the floppy (msdos) and copy > : the kernel, or you can mount the image file with one of the loop devices > : and do the replacement to the image file. Any future copies of that image > : file will have the new kernel. > > Yes, I know this. However, what people have been asking for is an image > of the rescue disk, not a new kernel for the disk (it is difficult to > run rdev.sh if you have no Linux system handy) The paragraph you cut out would do that. If you need modules added you must unpack the root fs and add them. If you mount resc1440.bin on a loop device, you can treat it just like any other file system (BTW this is the way the boot-floppies package builds the image in the first place), replacing the kernel or the root file system > > Furthermore, it might become necessary to change the available modules > (I honestly don't know whether this is the case), and I don't believe > the rescue disk has device files for ESDI disks. They are /dev/ed[ab], > correct? Vincent Renardias says the 1.3 boot disks support MCA (they > do) and ESDI (I never found /dev/ed[ab] devices). No Debian boot disk > supports IBM MCA/SCSI afaik. > The SCSI drivers are usually "built-in" to the kernel, so this is just another kernel issue. > Finally, I'd really like to *know* how to build these things! Why is it > so opaque? Building the root file system is a non-trivial problem. The boot-floppies package builds everything that you find in a disks-i386 directory, so it is a bit complex. The cryptic instructions that you indicated previously are an indication of the place to tailor the package to your system. If memory serves, there are two paths defined in the top of the make file. One is the path to the kernel image (note: not a kernel package...I think), while the other is the path to your archive (used to built the root fs) Also, I don't believe that there are any modules installed on the root fs of the rescue disk. It is assumed that any other drivers will be installed from the drivers disk. This disk just contains a tarball of the modules directories. For my last custom CD I rebuilt the rescue and drivers disks to use the 2.0.33 kernel. This was simply a matter of replacing the drivers disk tarball with one built from the 2.0.33 kernel modules directories, and replacing the kernel image on the rescue floppy with the kernel image from the 2.0.33 kernel. I did both of these things to the image files (resc1440.bin, resc1200.bin, drv1440.bin, and drv1200.bin) which could then be used by the installer to build rescue and drivers disks. I don't see where you gain any needed functionality by doing this job with the boot-floppies package. In addition, you stand the chance of building an unusable root file system if the archive you build it from is different from the one used to build the original. As you don't need anything changed in the root fs (as far as I can tell) why take the chance of making it non-functional? Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Number of Maintainers
On Fri, 10 Apr 1998, Remco Blaakmeer wrote: > On 9 Apr 1998, Jim Pick wrote: > > > > > Brian Bassett <[EMAIL PROTECTED]> writes: > > > > > After both Manoj Srivastava and Bob Hilliard pointed out to me the faults > > > in using the Maintainers file for determining the number of maintainers, I > > > have decided to use the Debian PGP keyring. After deleting duplicate > > > keys, > > > the keyring says that there are 313 developers, making Q 8.85 and K 5. > > > > > > Brian > > > > You know what would be cool - if the www.debian.org homepage had a > > running count of the number of maintainers! > > > > That's Debian's biggest selling point, as far as I'm concerned. > > What happens with a public key if a maintainer orphans all his/her > packages and leaves the project? Is it kept in the keyring or is it > removed? If it isn't removed the numbers would be too high, IMO. > But it also leaves out testers, who provide no pgp keys. So the number could be too low ;-) Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Sat, 11 Apr 1998, Brian White wrote: > I was thinking "project/experimental" would be better, but I don't think > that goes out on many CDs. > It would if that directory were inside the main distribution tree, and it would be obvious what it contained. I think it would be a good solution. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages which are links to bo
On 17 Apr 1998, Mark W. Eichin wrote: > > > How about just using "cp -r ..." to make the image you're going to > > Or even mkisofs -f... > Neither of which work when the symlinks in question have nothing to point to, which was, I believe, the original problem, wasn't it? Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intent to package flip
On Sat, 18 Apr 1998, James R. Van Zandt wrote: > Here are the author's description and copyright. I have questions > about each. > > > This program converts text file between MS-DOS and **IX format. It > > works under System V, 4.3BSD, Ultrix, and MS-DOS/Turbo C. It detects > > binary files in a nearly foolproof way and leaves them alone unless you > > override this. It will also leave files alone that are already in the > > right format. User interrupts are handled gracefully and no garbage or > > corrupted files left behind. An MS-DOS binary will eventually appear > > in comp.binaries.ibm.pc. > > > > Rahul Dhesi <[EMAIL PROTECTED]> > > I have used this program for several years, and like it better than > "todos" and "fromdos" which are currently part of the sysutils > package. The automatic detection of binary files is *very* handy. I > am willing to make an independent package. However, should it instead > be incorporated into sysutils? > > The included manual page includes this copyright/license statement. > > > COPYRIGHT > >Both this documentation and flip are Copyright 1989 Rahul > >Dhesi, all rights reserved. Permission is granted to copy, > >use, and distribute for any commercial or noncommercial > >purpose in accordance with the requirements of version 1.0 > >of the GNU General Public license. > > > >Note: This software has not been endorsed by the Free > >Software Foundation, the creator of the GNU license, and I > >am not affiliated with that organization. > > It claims both "all rights reserved" and the GNU GPL. Can this be > included in the Debian main distribution as is, or shall I try to get > the author to clarify it (assuming he can be located after all this > time)? > The "all rights reserved" is standard issue for a Copyright. The GPL is a License agreement. Many authors write complex license agreements rather than use the GPL because they are afraid of loosing their Copyright. They are mistaken about this. These two items are separate. It is, in fact, the "all rights reserved" provided by the copyright that provides the "authority" to issue the License Agreement. This looks like DFSG compliant software to me, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 18 Apr 1998, James Troup wrote: > Hi, > > Santiago approached us (pgp-update) about splitting the debian-keyring > from doc-debian because a) the keyring tar ball is currently 256Kb > (36% of doc-debian's installed size) and growing (it may eventually > double in size when I get round to adding a debian-keyring.gpg) and b) > the keyring is updated much more frequently than doc-debian needs to > be (doc-debian wasn't updated for 7 months at one point). > > So we intend to create a debian-keyring package which will be uploaded > weekly (if there are no changes, there'll be no upload, but given the > last couple of months I don't anticipate that RSN). It'll be > maintained by "Igor Grobman and James Troup <[EMAIL PROTECTED]>". > I know this is controversial, but quite frankly, I don't care. The > current ``policy'' was invented by Christian with zero consultation > (he ``thought it was already policy''[1]) and until it's ratified by > the developers I will ignore it as much as I ignored the bogus > no-ldconfig FUD in the packaging manual prior to 2.4.0.1. > > Personally I think this package could go into hamm since it is a) not > really new but is a derivative of a package already in hamm, b) Arch: > all, c) very simple, it's hard to imagine release-critical errors one > could make in packaging it. But if Brian disagrees I won't argue the > point and it'll go to slink. > > Any objections? (To the package itself, only please; take any > comments about the multiple-maintainership to debian-policy) > As to the package: Go for it! As for the Policy violation: Go for it! I've said this before, and I know that some disagree, policy is a set of guidelines, not a straight jacket. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: acct: process accounting and 2.1.96
On Sun, 19 Apr 1998, Austin Donnelly wrote: > The latest development linux kernels have a fairly substantially > changed "struct acct" defined in acct.h. > > Currently: > > libc5: > sys/acct.h just includes linux/acct.h (2.0.32 version) > > libc6: > sys/acct.h is a new file, but it defines a structure which > happens to be the same as linux/acct.h (2.0.32 version). > > With 2.1.xx, linux/acct.h changes incompatibly - the structure is > larger, the command name comes at the end (not the start), and there > are some additional fields. Remember, 2.1.xx kernels are development, not release. > > The question is then "how do we migrate to the new format?" > When we migrate to the 2.2.xx kernels libc6 will migrate to new header files and will reflect the changes. > Incidentally, simply rebuilding the acct package against the new > header files is a little tricky, since the ./configure script uses > sys/acct.h in preference to linux/acct.h > The libc6 built for 2.2.xx kernels will built a compatible sys/acct.h header for your package build. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On Sun, 19 Apr 1998, Christian Schwarz wrote: > It's up to you which guidelines you want to follow--but if you want to > maintain packages for our distribution, you'll have to follow our > guidelines! Our policy applies to all packages in the distribution. Any > package failing current policy in a severe way will be removed from the > distribution. > Then you will need to remove libc6, as the loader is not stripped, as dictated by policy. If I strip it, as policy demands, it will not work. Policy statements that fail to provide an adequate exception mechanism are totally broken. We have several "work arounds" for this policy, and the "not yet authorized" package in question will not be the first that desires, or requires, more than one maintainer. I have yet to hear a good technical reason for restricting package maintainance to a single person. Yes, there are several accounting issues that keep coming up, but those are for the individuals actually implimenting a multi-maintainer package to resolve between them. Personally, I find this dictatorial attitude about Policy as potentially more dangerous than no policy at all. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On Mon, 20 Apr 1998, Christian Schwarz wrote: > > [I reduced the list of recipients.] > > On Sun, 19 Apr 1998, Dale Scheetz wrote: > > > On Sun, 19 Apr 1998, Christian Schwarz wrote: > > > > > It's up to you which guidelines you want to follow--but if you want to > > > maintain packages for our distribution, you'll have to follow our > > > guidelines! Our policy applies to all packages in the distribution. Any Your use of the word guidelines here is confusing considering the position you are taking here. My understanding of a guideline is a "suggested direction" or an "indication of the best method". I have never heard guidelines used as "something that must be followed to the letter". > > > package failing current policy in a severe way will be removed from the > > > distribution. > > > > > Then you will need to remove libc6, as the loader is not stripped, as > > dictated by policy. If I strip it, as policy demands, it will not work. > > I said `failing [...] in a severe way'. I didn't think that I got any chance to make any decissions about the "severity" of my violation. It is very clear in the policy statement that this is a violation. This statement only makes me more confused. It is ok not to strip a binary (this you say isn't severe), but not ok for two people to jointly maintain a package? Where exactly is this sliding scale described in policy? > > > Policy statements that fail to provide an adequate exception mechanism are > > totally broken. > > > > We have several "work arounds" for this policy, and the "not yet > > authorized" package in question will not be the first that desires, or > > requires, more than one maintainer. > > > > I have yet to hear a good technical reason for restricting package > > maintainance to a single person. Yes, there are several accounting issues > > that keep coming up, but those are for the individuals actually > > implimenting a multi-maintainer package to resolve between them. > > > > Personally, I find this dictatorial attitude about Policy as potentially > > more dangerous than no policy at all. > > Please read my message again more carefully. I only objected to the way > you treat policy. > My objections are the same. I object to the way that you treat policy. > The reason for our policy is not part of _this_ discussion--it is But such reasons should be made clear in the documentation that demands the behavior. > discussed on debian-policy in another thread. The only thing that counts > in this discussion is that it's *not* up to the maintainer to decide > whether he/she wants to follow policy or not. > Well, spank me with a switch! If I am being asked to check my brains at the door, then I will just need to find another place to hang out. This attitude you are projecting is not a cooperative one and fails to create the feeling of cooperation that is absolutely necessary for this project. > If you're intrested in discussing pros and cons of section 2.3.2, please > join the discussion on debian-policy. > Even if I were so interested, I have no time for the things I must do, much less something that is being dealt with in this fashion. If you need a better excuse than this, just chalk it up to your "friendly" attitude. Aside from your attitude about dual maintainer packages, you expressed resistance to there even being such a package split. Is this one of the dictatorial powers you now have? I always thought it was up to the developers whether a package is built or not. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/bin/sh has no man page.
/bin/sh is provided by bash, but doesn't come with its own man page. How does one determine the differences between sh and bash? Is there some documentation that I have missed? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Paging Dan Quinlan
I have been getting bounced mail from the testing mailing list sent to Dan Quinlan. Can anyone verify that he has indeed left the project, or give me a new address for him? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with ae and xterm
Since ae has been converted to slang I have been having many problems with the keybindings for ae. When it was compiled against ncurses, the terminfo config files worked fine with entries like: .cursor_up $(kcuu1) Which the termcap equivalent should be: .cursor_up $(ku) Except it doesn't work. With this entry in the ae.rc file, pressing the up arrow produces ^[[A on the screen. Replacing this with: .cursor_up^[[A causes the up arrow key to work (in both the console and an xterm) The same problem occurs witht the function keys as well. Putting the keycode into the ae.rc file allows them to work on the console, but they don't work in an xterm. This is where is gets even more bizzare. Checking the keybindings for the function keys, the xterm defines F1 as ^[OP, but when I put that keycode into the F1 entry, all I get when pressing F1 is the characters ^[OP get echoed to the screen. There are other problems in an xterm, like the fact that the screen is black and the letters are white, with no cursor appearing on the screen. Outside of the function key problems, ae has never behaved this badly in an xterm. Many of these difficulties appear to be involved with the slang library. In addition the ^M problem also seems to be a slang problem. While there is a bad declaration of nel in the terminfo files, changing this doesn't seem to fix the problem (the current nel is defined to be ^M^J, which is the DOS version of a ). It appears that slang is making this happen. I have tried to contact the slang maintainer, Chris Fearnley, but have recieved no reply. Anyone know where he is? The hardest part of this package has been to try to deal with the problems of an xterm, without compiling ae as an X compatible program (something which it was not originally designed to do) >From my point of view, this editor is the fallback editor for the installation, and as such, was not expected to be used in an xterm. However, there are several shops that wish to manage these machines remotely from an xterm using ae, so the problem remains...what should be done about this problem? My biggest problem right now is that I can't see any way for a non-X-aware program to control its own keybindings when run in an xterm. Can anyone provide a functional approach to this problem? Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Paging Dan Quinlan
This whole thing is even stranger than that. [EMAIL PROTECTED] is not on the distribution list for debian-testing. In fact there are no addresses to that domain in the list. I have no idea why murphy is trying to send these e-mails in the first place, much less why they are causing bounces. On another (possibly unrelated) issue, apparently the bellsouth ISP starts bouncing mail from domains that send too many emails to their customers. The bounce is such that the murphy server resends confirmation mail, but doesn't inform me that the events have occured. It seems, from other interactions with spam filters on servers, that mail that does not arrive at its destination, due to the intervention of a spam filter, fail to bounce mail back to the originator. I have had several customers "go missing" and get back to me through other avenues. In both cases the cause was a spam filter at the ISP hosting the customer. Among other things, this has added to my conviction that there aren't any technical solutions to social problems. That is, all technical solutions have social side effects of the same order as the problem being solved. The above example is a case in point. On Fri, 24 Apr 1998 [EMAIL PROTECTED] wrote: > On Thu, Apr 23, 1998 at 11:58:57AM -0400, Dale Scheetz wrote: > > I have been getting bounced mail from the testing mailing list sent to Dan > > Quinlan. Can anyone verify that he has indeed left the project, or give me > > a new address for him? > > http://www.pathname.com/fhs/ still has a mailto [EMAIL PROTECTED] . > > penguin ray 8:58 ~> mx pathname.com > pathname.comMX 10 proton.pathname.com > pathname.comMX 200 freya.yggdrasil.com > penguin ray 8:58 ~> telnet proton.pathname.com 25 > Trying 204.145.147.37... > Connected to proton.pathname.com. > Escape character is '^]'. > 220-proton Smail-3.2 (#2 1996-Nov-26) ready at Fri, 24 Apr 1998 00:00:06 > -0700 (PDT) > 220 ESMTP supported > EXPN quinlan > 250 "|IFS=' '&& exec /usr/bin/procmail -f- || exit 75 quinlan" > QUIT > 221 proton closing connection > > So as far as I can tell, [EMAIL PROTECTED] should work. > > HTH, > Ray > -- > Cyberspace, a final frontier. These are the voyages of my messages, > on a lightspeed mission to explore strange new systems and to boldly go > where no data has gone before. > > Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first proposal for a new maintainer policy
On 28 Apr 1998, Manoj Srivastava wrote: > I prefer the codification of rules that have to be followed > and putting them out in the open, rather than continuing to depend on > the judgement of a few good people in perpetuity. Some have called my > view fascist. > > Codification of laws and rules is not fascism; on the > contrary, it has served the masses more often than now. (Tha Magna > Carta, and various and sundry constitutions around the world). It all > started with Hammurabi codifying the laws, and limiting the power of > the technical committee (I mean, the kings). > The Documents you site are sets of rules that "limit" the power of government over its people, and are certainly not fascist. The Policy Statement is a set of rules for the behavior of developers, set down by the "ruling body", sometimes referred to as "the government". When those rules are viewed as more important than the people participating, that view is a Fascist one. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first proposal for a new maintainer policy
On 29 Apr 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> The Policy Statement is a set of rules for the behavior of > Dale> developers, set down by the "ruling body", sometimes referred to > Dale> as "the government". When those rules are viewed as more > Dale> important than the people participating, that view is a Fascist > Dale> one. > > Please elucidate hw the laws of the united states, canada, the > united kindom, or indeed, any european union country (pardon > for missing your country here) does not fit the same criterion. The Constitution of the United States speaks of the freedoms of the individual and the responsibilities of the government. Many of the amendments further expound on the individual freedoms a citizen has from oppression by the powerful. > > If I wish to go out and help myself to the extra ``petty'' > cash lying around in banks, I shall soon find whether the laws of the > land are considered more important than the people. > Those laws are for the protection of individuals from those more powerful groups who would deprive them of "life, liberty, and ..." > I guess the ANSI C standard is fascist too. Hmm. > If you are an individual composed of C code then it is ;-) > manoj > amused > Is invoking hascism the same as invoking hitler in a discussion? I don't think so, but please define hascism anyway ;-) > -- > "When I was a boy I was told that anybody could become president; I'm > beginning to believe it." Clarence Darrow When I was in High School we learned that the Russian people voted in a democratic election where there was only one candidate for President provided on the ballot. Having already learned that our democracy was a two party system providing two candidates for the ballot, it has always seemed to me that the Russian system was more honest. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: on forming a new Linux Distribution
On Thu, 30 Apr 1998, Stephen Carpenter wrote: > I dunno...I think ee and ae are both pretty damned easy and mindless :)(ae is > sooo mindless I have noticed it is putting CR in my text documents) As it turns out the DOS CR is coming from slang and is being worked on. Ae's .rc files are currently broken as well, from the transition to slang. Most of the details have been worked out, although I am still looking for a reasonable way to deside whether ae is running in an xterm or the console. (trolling for ideas on this one at every opportunity ;-) Look for a much cleaner operation of ae in the next release...the vi stuff is even working again! I have gotten a lot of good help on this problem, and I want to take the time here to thank everone who contributed info and fixes. If I haven't thanked you in person, it is only because I am moving too fast and you fell through the cracks. Many thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Thu, 30 Apr 1998, Santiago Vila wrote: > -BEGIN PGP SIGNED MESSAGE- > > I have just read Bug #14355, in which Ian Jackson said about qmail-src: > > This package has no reason to exist and should be withdrawn. We > distribute source as .dsc/.diff.gz/.orig.tar.gz. > > Well, this package exists for two reasons: > > 1) Because license does not allow to distribute a binary. > 2) Because there is not an easy method for downloading a source package > by using dselect or existing tools. > > To solve 1), we would have to change the license, but we can't because we > obviously do not own the copyright... > > To solve 2), we can either: > > a) Modify dselect/dpkg so that it allows retrieving and unpacking source > packages as well as binary packages. > > b) Allow .deb "source" packages like qmail-src, as an exception for the > rule "we distribute source as .dsc/.diff.gz/.orig.tar.gz" for non-free > packages. > > Since a) is clearly not going to be done for hamm, I don't see really a > reason why -src packages should be "forbidden". > > Ian, why do you still think that qmail-src should not exist? > Are you the only one? > I agree with Ian. The .deb file format is expressly for the distribution of configured executables (binaries for short). Using this format for source distribution is simply asking for trouble. Maybe we need a tarball that contains .dsc, .changes, .diff, and .orig.tar.gz all rolled up in one .src file, known to all the necessary programs, but to me this isn't necessary. For almost two years now we have distributed source packages as a collection of checksum authenticated files with a pgp signed changes file containing them. These four files: .dsc, .changes, .diff, and .orig.tar.gz comprise the Debian Source Format, as described in the significant documentation. We do it this way for both DFSG Free as well as for contrib and non-free software, so why make an exeption in this case? Retrieval of source from archives is usually done "by hand" but any such bulk retrieval should be easy to manage with a script. I take the lack of a script to indicate the current relative lack of need. Anyone is welcome to prove me wrong by writing such a script ;-) Although few agree with me, I still feel that packaging kernel source in .deb format was/is a mistake. The kernel-package-builder package doesn't benefit from this packaging style, as far as I can tell and it makes the kernel more perculiar than it need be. Another benefit of this source format that the .deb does not provide is the one time only download of orig.tar.gz. Until the upstream version changes, one can keep up with the Debian package by only needing to download the .diff and .dsc files (typically many orders smaller) to create a source tree that will build the current version of the Debian package. Keep source in Source Format and use the .deb files for what they were intended, the distribution of "binary" components. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Thu, 30 Apr 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > I agree with Ian. The .deb file format is expressly for the distribution > > of configured executables (binaries for short). Using this format for > > source distribution is simply asking for trouble. > > Um... so does this mean we have to retract the kernel-source packages? Wouldn't hurt my feelings any to have the kernel source packaged just like every other package, so a dpkg-buildpackage on the Debian source tree would build a kernel binary package, just like the one found on the boot disks. I'm not the kernel maintainer, so I have little to say about how that gets done. > > Also, note that a variety of other packages include source, examples > include: samba, ipx, modutils, netcat, xephem, ncurses3.4, mgetty, > freetype1, cgilib. > Which has absolutely nothing to do with this discusion. You could just as well say that scripts are also delivered in this way, and they are source as well. What we are talking about here is "repackaging" the source tree into a .deb file. Very undesirable as it defeats all the good points of the current source package system. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Thu, 30 Apr 1998, Santiago Vila wrote: > > We do it this way for both DFSG Free as well as for contrib and non-free > > software, so why make an exeption in this case? > > Because we want to make easier the retrieving of *certain* source files. > As easy as it is currently to retrieve binary .deb files. How does it make it easier to force the downloader to eat the orig.tar.gz file every time a small change is made to the package. The source file format was designed to provide the capability of obtaining source from other medium, download a diff and dsc file, and build the new source tree. How does it make it easier to be forced to eat that source tree every time, and then not get control over where it goes or how it is unpacked. Where do these .deb files unpack the source when they are installed? How does the user get what he/she expects? I can see why this "seems" to be such a simple solution...all the tools are here and well known...the problem is that non is a "hammer". Trying to use the binary package for source is simply...gross. When I distribute non-free programs on CD, it is very easy to include the source on the same directory tree, so I don't really see the gain of bundling it all up in a .deb file, and there are good reasons for not doins so, although you seem unreceptive to them. > > > Retrieval of source from archives is usually done "by hand" but any such > > bulk retrieval should be easy to manage with a script. I take the lack of > > a script to indicate the current relative lack of need. Anyone is welcome > > to prove me wrong by writing such a script ;-) > > My point is that the functionality is already built-in in dpkg itself and > we would not have to reinvent the wheel just for this particular case. > The functionality for both binary and source package management is already built into dpkg. No wheel inventing is necessary. I believe that you are confusing dselect's ftp method with dpkg features. I'd much rather see Apt capable of fetching source components for a package as easily as it does the binary ones, than to see package source begin to migrate into the binary packaging system. > > Although few agree with me, I still feel that packaging kernel source in > > .deb format was/is a mistake. The kernel-package-builder package doesn't > > benefit from this packaging style, as far as I can tell and it makes the > > kernel more perculiar than it need be. > > > > Another benefit of this source format that the .deb does not provide is > > the one time only download of orig.tar.gz. Until the upstream version > > changes, one can keep up with the Debian package by only needing to > > download the .diff and .dsc files (typically many orders smaller) to > > create a source tree that will build the current version of the Debian > > package. > > Ok, then I will make two packages. One for the .orig.tar.gz file and > another one for the .diff.gz and the .dsc files. This way only the second > one will have to be downloaded for each new release. > What is the point! They are already properly packaged in the source format. > > Keep source in Source Format and use the .deb files for what they were > > intended, the distribution of "binary" components. > > I *will* keep the source in source format. > > I will just create another .deb binary containing the source. > > The .deb files were intended to be the binary package format of a free > Unix-clone distribution, Debian. If binaries are not allowed, the .deb > binary format is certainly not suitable for its distribution and we > can perfectly live with an exception. > This is a rather circular set of logic. If binary distribution is not allowed, how does that make the binary packaging system the right place for the source? If this package does not allow the distribution of binaries, then we should distribute the package in Source Format. That is the clearest way to satisfy the license. Making a "pseudo" binary package is not appropriate, however, creating a package that will "automatically" retrieve and build a Debian Source Package would not only be acceptable, but very useful in other situations not directly related to non-free distribution limitations. One of our "unwritten" policies is to apply the principle of least surprise wherever applicable. Most reasonable folks expect to find the source in the source section, packaged like other source, in a consistent and reliable fashion. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, 30 Apr 1998, Marcus Brinkmann wrote: > 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. > 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. 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. While policy only states that the upstream changlog will be named changelog, I see the policy of "least surprise" as allowing me to include a link for ChangeLog so that those who are expecting that will find it. A strict reading of the Policy Statement might not lead others to this conclusion, but I don't see that as broken. I am willing to let those more interested in the location of comas etc. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Thu, 30 Apr 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > What we are talking about here is "repackaging" the source tree into a > > .deb file. Very undesirable as it defeats all the good points of the > > current source package system. > > Yet our current source package system needs work. It doesn't give much > of a clue what's needed to compile the source, for instance. Nor does it > integrate well with our package management tools (not even Apt will > bring down source and compile it). > > I think we should fix these problems and live with the current mishmash > until then. > While I agree that we could use better source management tools, I don't think the way to resolve that need is by using the binary package management tools. As to source dependency problems, it is my understanding that all the packages in the main distribution can be built using only packages from main. Given that that doesn't tell you which packages those are, and that a "standard" installation is supposed to give you "all the normal stuff" it should be sufficient to name non-standard dependencies in the source README file. There is no current declared method for this, and that makes implimentation difficult, specially when most developers have what they need for their packages and don't typically think about the problem any further than that. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> Then you will need to remove libc6, as the loader is not > Dale> stripped, as dictated by policy. If I strip it, as policy > Dale> demands, it will not work. > > Have you reported this as a bug againt the policy manuals > then? Is policy being changed with regards to this? > No, because as a guideline it is correct. This has been my point all along. Policy is a guideline, which points to a preferred path of development and proceedures. When those guidelines fail to produce the desired results exception is taken and the "right thing" is done anyway. If policy is not going to allow such exceptions then the concept of Policy is broken. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > The policy is the only standard we have for the distribution; > and standards not followed are sometimes worse than no standards at > all. (This is one of my pet peeves with miscrosoft). > While I could disagree with the other "personal opinions" you have expressed, they were expressed as your personal opinions, and I am willing to leave it at that, but the above statement is simply and completely false. Policy is not in my opinion a standard. We DO have important standards that we follow with varying degrees of success, and it is these standards and our attempts to follow them that have made Debian the useful, well integrated, system that it has been for much longer than Policy has existed. Policy was developed as a tool to aid new developers in understanding the many details of package building and system integration as practiced by the Debian development group. This came about to deal with the large influx of developers that the group has experienced in the last several years. Since that time every attempt has been made to elevate policy to some super godhood of unquestioned excellence. This is an attitude I don't agree with. Even the Policy Tzar agrees that Policy is a Guideline, he just takes the word to have a stiffer meaning than most reasonable folks. Look! We aren't talking about whether or not it is appropriate to violate update-alternatives, or some other technical integration issue. My complaint comes from having to spend valuable time fending off arguments over whether ChangeLog is equivalent to changelog as specified in the Policy manual, or other issues that are of a strictly typographical nature. For me dual maintainer packages falls under the later and, as has been pointed out already, this is not the first package to violate this "broken" policy All I have ever suggested is that policy statements can not be absolute in all cases, and this fact has not yet been recognized by those who dictate policy to the rest of us. Civil disobedience is the only option I have the time or energy for. I will continue to object to the dictatorial nature with which these edicts of the Policy group are being implimented. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> No, because as a guideline it is correct. This has been my point > Dale> all along. Policy is a guideline, which points to a preferred > Dale> path of development and proceedures. When those guidelines fail > Dale> to produce the desired results exception is taken and the "right > Dale> thing" is done anyway. If policy is not going to allow such > Dale> exceptions then the concept of Policy is broken. > > I have already expressed my disagreement with the sentiment > that the Policy document is merely a guideline; I see it as a > standards document for the Debian distribution. So the policy is more > than just the preferred path; it is a set of rules to be followed by > packages in the Debian distribution. > > I agree that there there well may be exceptions to the > individual directives in the Policy; in which case I think the > exceptions (when known) should be noted in the policy. This has the > added side effect of helping clarify the directive itself, and to > determine the scope, and it shall help to determine whether an > exception to the policy should apply to ones own package. Every policy item should have both a rule for its exception, as well as a clear definition of the "severity" that may be assigned to it. This helps with those trying to decide how the policy item effects their particular package, and provides suggestions on how to prioritize bugs reported against that policy item. > > People have been recently railing at the policy manager for > taking unilateral decisions; but any package manager flouting the > policy is doing exactly the same. No one is infallible. I would much > rather have any exception discussed and added to the Policy manual, > rather than undermine the Policy document by condoning violations. > You speak of "flouting" policy with reguard to maintainers who are simply trying to "do the right thing" in the face of an intractible policy statement. Why is there advantage in depicting your fellow maintainers as potentially spoiled and flippant brats? > By the way, I do not think I am alone in regarding the Policy > as a standards document; a quick (informal) poll on IRC showed a > wider accord (for what it counts for). > Folks with time on their hands tend to support measures that control the group for the betterment of all without reguard to the desirablility of such controls by those who have it imposed upon them. (sorry for the tangled sentance) Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-CD exceeds 650 MB -- any solution?
On Mon, 20 Apr 1998, Heiko Schlittermann wrote:
> Hello,
>
> the contents of the hamm binary archive exceeds the magic 650 MB
> limit. Is there any progress in making dselect/dpkg aware of this?
Is this still true if you don't count non-free, and remove the source from
contrib (and put it on the source disk)?
>
> Or is the current solution to split
>
> hamm/hamm
> and
> hamm/{contrib,non-free}
>
I would be more in favor of splitting off optional and extra packages onto
succeeding CDs. All of the packages that have priority standard and higher
should fit, with source, on one CD. As the optional and extra packages
continue to increase in population the overflow simply moves onto another
CD, keeping source with binary. I think this gives us two full CDs and a
third that may be only partially full, allowing room for "add ons".
> ??
>
> What are the plans for the official CD?
>
TBD as far as I can tell. Ian asked about it a while back, but I don't
remember any follow through.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> On 20 Apr 1998, Manoj Srivastava wrote: > >> The policy is the only standard we have for the distribution; and > >> standards not followed are sometimes worse than no standards at > >> all. (This is one of my pet peeves with miscrosoft). > >> > Dale> While I could disagree with the other "personal opinions" you > Dale> have expressed, they were expressed as your personal opinions, > Dale> and I am willing to leave it at that, but the above statement is > Dale> simply and completely false. > > Oh, so you categorically state that that stement is false? I > see. Well, I still stand by it. Without the ww policy, and others > like it, we would not have such a well knit distribution. Stand by anything you choose. The policy statement, while it declares other standards as policy does not therefore acquire the status of a standard. You completely ignore a whole raft of other "Debian" standards as well, like the DFSG, among others. The www policy is a new "standard" being designed for Debian. It will take some time before we can declare that this standard is responsible for much of anything, let alone the current "well knit distribution". > > Dale> Policy is not in my opinion a standard. We DO have important > Dale> standards that we follow with varying degrees of success, and it > Dale> is these standards and our attempts to follow them that have > Dale> made Debian the useful, well integrated, system that it has been > Dale> for much longer than Policy has existed. > > When do you think policy was started? I have a feeling that > policy was written not very long after Debian become a > multi-maintainer distribution (yes, there was the golden age > when there was just one debian maintainer). As we are brandishing > opinions here., I think I hold to mine that Policy is integral to > the cohesiveness of Debian. The Policy Group was begun about the same time as the QA group, and testing, among others. Outside of Ian's original writing of the Programmer's guide et al, the current policy documents were created by this Policy Group. You can rewrite history all you wish Manoj, but you and I were both there and should be able to agree on what happened without all this posturing. > > Dale> Policy was developed as a tool to aid new developers in > Dale> understanding the many details of package building and system > Dale> integration as practiced by the Debian development group. This > Dale> came about to deal with the large influx of developers that the > Dale> group has experienced in the last several years. > > That it one of the side effects, yes. But the www-standard > (which is policy), the file system standard (which is also policy) > and various and sundry things in that document define the OS, and are > not simplifying things for the new developer (heh). > Memory says that the www-standard is, in fact, delineated in a seperate document that represents that standard. The same is true of the file system standards, the DFSG, ANSI C, POSIX, and others that I am certain to have forgotten to mention. Policy declares the distribution's intention to follow these standards in, what are sometimes, piecemeal fashion. While I would agree that it is Debian's policy to follow the FSSTD, the Policy Statement only declares particular areas of that standard that are implimented by Debian in a particular way. It has always been a guideline for the implimentation details as they are done by Debian. > Dale> Since that time every attempt has been made to elevate policy to > Dale> some super godhood of unquestioned excellence. > > Are you sure you are in a state of mind condusive to a debate? No, I find the debate boaring in the extreme (not to belittle your sparkling wit, and superior arguments ;-) > I am not sure I should waste my time talking to someone who is so > biased as to relegate an issue of standards-conformance to "super > godhood of unquestioned excellence." I expected better of you. > It is not standards-conformance that I have objected to. It is the dictatorial attitude about what is written in the Policy Statement. It is the deman that reasonable thought be executed on the alter of "defined standards", and the automatic assumtion that a developer is unable to come to reasonable decisions when confronted with policy that is unsuitable to the current problem. > Dale> This is an attitude I don't agree with. > > You have that right. There are things in the ANSI C standard > do not agree with too, and t
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > > Hmm. I agree about the exceptions, if any. The severity idea > sounds interesting, though I think it should be evaluated more > thoroughly. It may require the Policy document to be totally > re-evaluated; I would tend to think that policy should be most MUST > directives, with a very few SHOULDs thrown in. The problem is that the SHOULDs and MUSTs are currently subject to interpretation, and aren't clearly spelled out. Getting them clear is the only way for the information to be valuable and useful. > > >> People have been recently railing at the policy manager for taking > >> unilateral decisions; but any package manager flouting the policy > >> is doing exactly the same. No one is infallible. I would much > >> rather have any exception discussed and added to the Policy manual, > >> rather than undermine the Policy document by condoning violations. > >> > Dale> You speak of "flouting" policy with reguard to maintainers who > Dale> are simply trying to "do the right thing" in the face of an > Dale> intractible policy statement. Why is there advantage in > Dale> depicting your fellow maintainers as potentially spoiled and > Dale> flippant brats? > > You are the one putting value judgements on our fellow > developers. I can not control how you interpret messages. In absence > of a more explicit attack on my part, I think this is your problem. > We clearly see things differently here... > If policy is indeed broken, we should e fixing this. Have you > put in a word asking for policy to be changed vis a vis the stripping > issue? No, you chose to defy policy rather than ask for an exception > to be inserted. > Here the interpretation you present is, as you say, your problem. I did not choose to defy policy. I saw implicit in the policy statement that the requirement was only applicable if it didn't break something. The desire is to create a distribution that installs in the smallest disk space possible. I saw that requirement as being a smaller one than the functionality requirement, and thus "violated" the letter of the policy, while being certain that I was supporting the best product I could build. > Why do you say that the policy is intractable? Policy did > change wrt the ldconfig issue. It could have been faster, but the > whole debate was clouded by statements and counter statements for the > longest time. > Exactly. During that whole debate period we had maintainers who "flouted" policy by making their packages functional? I don't see it that way. > I think policy is intractable to a large extnet because people > tend to ``fix'' policy locally for their packages rather than getting > it fixed generally. My impression may not eb shared by other people. > We are again seeing this from very differnt perspectives. I see the intractibility as coming from statements that insist that what is writen in the Policy Statement can not be deviated from in the smallest degree. > >> By the way, I do not think I am alone in regarding the Policy as a > >> standards document; a quick (informal) poll on IRC showed a wider > >> accord (for what it counts for). > >> > Dale> Folks with time on their hands tend to support measures that > Dale> control the group for the betterment of all without reguard to > Dale> the desirablility of such controls by those who have it imposed > Dale> upon them. (sorry for the tangled sentance) > > So anyone who disagrees with your point of vierw has too much > time on their hands, and is busy poking their noses into other > peoples affairs while they atand martyrted by? This is hilarious. > Well, actually I was suggesting that folks that have the time to hang out on IRC have more time for idle chit chat than I do, and I'm jealous! My real point was that folks who make the rules often don't consider those who will be forced to live under them. I probably should make it clear that I have no evidence that this is the case here. I was making a generalization. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On Mon, 20 Apr 1998, Branden Robinson wrote: > On Mon, Apr 20, 1998 at 03:57:27PM -0400, Dale Scheetz wrote: > > On 20 Apr 1998, Manoj Srivastava wrote: > > > By the way, I do not think I am alone in regarding the Policy > > > as a standards document; a quick (informal) poll on IRC showed a > > > wider accord (for what it counts for). > > > > > Folks with time on their hands tend to support measures that control the > > group for the betterment of all without reguard to the desirablility of > > such controls by those who have it imposed upon them. (sorry for the > > tangled sentance) > > Dale, there are plenty of hard-working Debian folks who spend time in the > IRC channel. Richard Braakman, Manoj, Joey Schulze, Joey Hess, Jason > Gunthorpe, Ray "JHM" Dassen, Igor Grobmann... I know I'm forgetting several > -- no denigration of their hard work is intended. > > I think you are mischaracterizing the developers who utilize the IRC > channel, and it does not strengthen your argument. To what extent the > policy manual should be a "guideline", and to what extent it should be > a "standard", is an issue to which IRC has no relevance. > Thank you. That was the point I was so poorly trying to make. No denigration was intended (just a bit of jealousy at not having any spare time myself) Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On Mon, 20 Apr 1998, Christian Schwarz wrote: > > Also note, that I just sent a proposal of a new `maintainer policy' to > debian-policy. Everyone is invited to take part of the discussion. > As this issue appears to effect all maintainers, I would ask that the discusion be carried out on debian-devel so that all may participate. Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > > Dale> The desire is to create a distribution that installs in the > Dale> smallest disk space possible. I saw that requirement as being a > Dale> smaller one than the functionality requirement, and thus > Dale> "violated" the letter of the policy, while being certain that I > Dale> was supporting the best product I could build. > > Why did you not try to change the ``letter'' of the policy, so > that it would make things easier for people who may have a > similar situation in the future? You saw a flaw in the policy, you > choose rather than to mend this, to ignore policy and worked around > it, leaving policy broken, at least in some cases. I saw no flaw. I interpreted my behavior as being within policy. > > >> Why do you say that the policy is intractable? Policy did change > >> wrt the ldconfig issue. It could have been faster, but the whole > >> debate was clouded by statements and counter statements for the > >> longest time. > >> > Dale> Exactly. During that whole debate period we had maintainers who > Dale> "flouted" policy by making their packages functional? I don't > Dale> see it that way. > > No, policy can be broken, or unclear, or not yet > specified. While policy is being formulated, affected packages > may indeed do their own thing. What I do not like is statements like > "As far as breaking policy, Go right ahead." with no effort ebing > made to bring policy in conformace to correct behaviour. > Again, your interpretation is somewhat different than mine. I was supporting a request for an exemption to the single maintainer rule. As we already have packages that are maintained in this fashion, I saw no problem with another exemption. > Dale> We are again seeing this from very differnt perspectives. I see > Dale> the intractibility as coming from statements that insist that > Dale> what is writen in the Policy Statement can not be deviated from > Dale> in the smallest degree. > > If policy is right, that is a good thing. If policy is wrong, > it should be corrected. And then followed to the letter ;-) You > can't just say, well, we all know policy is broken, so there is no > point in following it. > It is my continuing feeling that no limited policy statement can ever be written to be "right" in every case that it is to be applied. What I am looking for is either an attitude or an explicit statement in the Policy Statement, that, under conditions of necessity, there exists the possibility of exemptions to any "rule" in the Policy Statement. Without this attitude we are going to continue to have these fruitless discussions. > Dale> My real point was that folks who make the rules often don't > Dale> consider those who will be forced to live under them. I probably > Dale> should make it clear that I have no evidence that this is the > Dale> case here. I was making a generalization. > > I try help make the rules. I am governed by the same > rules. This is not a case of bloated washington fat cats who are > totally out of touch with their constituency. We do not have rule > maker drones versus toiling developer here. We are all in the same > boat. Singing the ``internationale'' is not quite justified ;-) > This is one of those that I don't see anything to comment about... > Every bit of the policy applies to all my packages just as > much as it does to yours. Equality of application is always good. > > manoj > -- > Better than a thousand pointless words is one saying to the point on > hearing which one finds peace. 100 We seem to have exhausted the limit some time ago ;-) Peace, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
On 20 Apr 1998, Manoj Srivastava wrote: > Hi, > > Well, to take a different tack, what is the point of a policy > document at all when anyone can say "well, my package is an > exception and need not comply to policy."? If one may take that > stance, I see no point in having a policy document in the first > place. To take the same tack, what is the point of a policy document that is so rigid that noone can say "My package needs an exception to this policy."? If one may take this stance, I see no point in trying to build a distribution in the first place. > > manoj > Why have the rules in the first place? (As usual, my random sig > generator has come up with something apropos; though I disagree with > it) > -- > Sometime, you've gotta break the rules. This is the clearest statement defining our differences on this issue. I, of course, agree with the above statement ;-) Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first proposal for a new maintainer policy
for clarification. This is actually probably going to be shared between the Policy Group and the "Technical Committee", which is why I didn't include it outright. In addition, I would like to see policy items identified with some severity levels. Something like: criticalViolations of these policies will result in packages that either don't work, or cause another package to fail. cosmeticViolations of these policies create clutter or confusion organizational No description comes to mind, but a good example is the Single Maintainer rule for a package. Those items that fall into the last two catagories should always provide a set of guidlines (I mean principles) for deciding how to deal with variances not explicitly declared. The only problem I have with this catagorization is that it doesn't seem to have a place for the "stripped binaries" rule. I guess it falls under the area of "clutter" and should thus be "cosmetic", but the word inplies too little concern...maybe a catagory between cosmetic and critical? > > -- > "Government is not reason; it is not eloquence; it is force! It is a > dangerous servant and a terrible master." George Washington Which urges caution when either using or being used... Later, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Thu, 30 Apr 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > As to source dependency problems, it is my understanding that all the > > packages in the main distribution can be built using only packages from > > main. > > That's a lot of packages. I've used .deb packages which include source on > little dinky machines with only a couple hundred meg of hard drive. What is your point? The .deb packaging of source doesn't deal with source dependencies any better than the current source package. > > > Given that that doesn't tell you which packages those are, and that > > a "standard" installation is supposed to give you "all the normal stuff" > > it should be sufficient to name non-standard dependencies in the source > > README file. > > This is supposed to be an improvement over putting the source in a > .deb file? [Which, I remind you, can be taken apart using standard > unix tools, and which can also be supported through a README file.] > This was a description of what might be done with what we have. > > There is no current declared method for this, and that makes > > implimentation difficult, specially when most developers have what > > they need for their packages and don't typically think about the > > problem any further than that. > > Please don't blame the developers for not using a system which hasn't > been designed or implemented. That sort of thing is unecessarily > dogmatic. > I don't know where you got this from. I was under the impression that I was discusing what might be done with the current source package format. I see no blame intended in what I wrote. Why must all discusions of this type necessarily degenerate into name calling? Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On 1 May 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> While I agree with much of what you say about the need for > Dale> policy to be clear, I will continue to urge caution when being > Dale> dictatorial about policy. > > Dale, I think no one is trying to be dictatorial about > policy. When you say the policy MUST be followed to the letter, I can view that as nothing less than a dictatorial attitude. > Phillip said it best; policy is suppposed to be followed > unless it is wrong. If it is wrong, it is appreciated if you correct > it. I am a maintainer who chooses not to spend my time in the policy group, but prefers to spend what little time I have working on my package responsibilities. One of the things that has bothered me about your position on this matter, is that you seem to think that maintainers who don't get involved in the policy discussion are shurking their duties, while I don't. > Not everyone has the grasp of the subject as the person pointing > out the error of policy, so amending policy is really just being > co-operative. > I thought that was what the policy group was there for. I have alwasy assumed that this kind of work was their responsibility. As a developer, I use the policy statements to help me decide on particular issues of packaging. How is it that I am now the responsible party for fixing a policy that I don't see as broken? > > Why are you fighting this? The only thing I am fighting is the oppressive attitude that you have been expressing about the Policy Statement. > > Dale> For example, the "stripped binaries" rule in the policy > Dale> statement is fine with me. I don't see it as "broken" the way > Dale> Manoj has suggested, because we have an unwritten policy against > Dale> delivering broken packages. I see the unwritten policy as having > Dale> a higher priority than the "stripped binaries" policy as > Dale> written. > > You know that the stripped binary rule has exceptions. I did > not. So, why am I responsible for your ignorance? > Why not put a statement in the policy describing when the rule > does not hold? (Some would say not correcting policy is elitist and > hoarding knowledge). > I have no problem with the policy statement containing such statements. In fact I have argued on several occasions that policy needs to always have and explanation for its existance, and a priority level for dealing with conflicting policy statements. My only problem is when you make it my responsibility to "correct" the policy statement. > > Dale> While policy only states that the upstream changlog will be > Dale> named changelog, I see the policy of "least surprise" as > Dale> allowing me to include a link for ChangeLog so that those who > Dale> are expecting that will find it. A strict reading of the Policy > Dale> Statement might not lead others to this conclusion, but I don't > Dale> see that as broken. > > I think then it is definitely unclear, and an ambiguous policy > statement is a broken policy statement. > Then fix it, if you think it is broken, and stop chastizing me because we currently live with a less than perfect Policy Statement. From my point of view, I follow policy when I deliver a working unstripped binary instead of a broken stripped one. I also think that I have followed policy when I add a link that provides ChangeLog for those expecting it. If you don't think so, then fix it to your satisfaction. I will not object. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Hamm
On Fri, 1 May 1998, Brian White wrote: > > Brian, this is a useful list, but please sort it by Maintainer or by Package > > rather than by bug number: > > Several people have asked for this, but maintainers already get separate > reports about their packages and reports by package are available on > the web site, so I don't really understand the usefulness of presenting > it that way here. Is there something I'm missing? If your own bugs are scattered around in a list of several dozen, it is really easy to miss one. Grouping them together makes this less of a problem. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pine-src
On Fri, 1 May 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > What is your point? The .deb packaging of source doesn't deal with source > > dependencies any better than the current source package. > > Sure it does. You put the dependencies on the Depends: line of the > control file. You sure know how to make my skin crawl ;-) > > > > > There is no current declared method for this, and that makes > > > > implimentation difficult, specially when most developers have what > > > > they need for their packages and don't typically think about the > > > > problem any further than that. > > > > Please don't blame the developers for not using a system which hasn't > > > been designed or implemented. That sort of thing is unecessarily > > > dogmatic. > > > I don't know where you got this from. > > "... specially when most developers have what they need for their > packages and don't typically think about the problem further than that." > Simple statement of fact. Not intended to place blame in any direction. The point I guess I intended to make here was that for the maintainer of a package "source dependencies" are a non issue. They are resolved as you figure out how to build the package in the first place. My personal experience is that if I install a "standard" system (all packages with priority standard and above) I don't need anything else. I understand that there are several packages for which this is not true, so I'm not saying there is no problem. Just supplying perspective. > > I was under the impression that I was discusing what might be done > > with the current source package format. I see no blame intended > > in what I wrote. Why must all discusions of this type necessarily > > degenerate into name calling? > > Good question. > > I think part of the problem is ambiguity. Another part is > misunderstandings. [These sometimes overlap, and sometimes don't.] > Often the replies by the listener who has misunderstood the speaker begin the escalation of invective. I constantly fight my general tendancy to view the other guy as a jerk, when the most likely possibility is that I have simply missunderstood him. (note: this never seems to happen to me in such conversations with women, so I suspect its a guy thing ;-) It would help us all to remember that we are all working toward the goal of a superior Linux distribution. Everything else that happens along the way should be considered scenery (to be enjoyed where possible, but very little can be done to change it). With that as a starting point, it should be much easier to see that the other guy isn't an idiot. He is just someone like you who is trying to make Debian better. (even when he is clearly wrong ;-) I don't claim to be any better than the rest at actually behaving in that way, but I do work at it. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Coming to closure on ae...
I am very close to having all of the ae problems solved, thanks to Jim Minta for both taking over the slang package and for the fine suggestions and patches that he has supplied for ae. I'm down to the xterm .rc file problem, and I have an idea that I thought I would toss out for discusion. There doesn't seem to be a "reliable" method for determining whether or not you are in an xterm. Any method so far suggested has "natural" configuration situations that break the method. This leaves me with one solution that is only bearly functional. I would like to provide wrapper scripts (or symlinks...I haven't decided yet) that will run ae with the correct .rc file. So, if you are in an xterm, instead of calling for ae, you would execute xae instead. (Note that there would be an xvi .rc file for running the vi mode of ae in an xterm) The reason I feel compelled to ask is that I will be creating two new names: xvi and xae. The other difficulty with this scheme is that it is not automatic, so the user will need to be informed of the issue. I guess I could put a note in the help screen of ae to let folks know. Thoughts? Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coming to closure on ae...
On Sat, 2 May 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > The reason I feel compelled to ask is that I will be creating two new > > names: xvi and xae. > > xvi, intuitively, seems to refer to an x aware version of vi (elvis or > vim). How about xaevi? A bit bulky ;-) There is already a /bin/vi script that executes ae as vi, as a "least surprise" issue. When running "vi" in an xterm, the help screen would indicate the program to use instead, so I don't see any problems with "expectation". I'm also leaning toward aex and vix, as they will appear in the directory together with their nonx partners. On another part of the problem. I just tried to use a symlink to execute ae with the correct .rc file. I cd'd to the /bin directory (where ae resides) and typed: ln -s '/bin/ae -f /etc/aex.rc' xae and, while it seemed to build the link I desired (it looks good with ls -l) when I try to execute xae, bash tells me the file is not found. Any idea what I am doing wrong? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coming to closure on ae...
On Sat, 2 May 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > ln -s '/bin/ae -f /etc/aex.rc' xae > > > > and, while it seemed to build the link I desired (it looks good with ls > > -l) when I try to execute xae, bash tells me the file is not found. > > > > Any idea what I am doing wrong? > > That's only going to work if you have a directory in /bin named 'ae -f ', > which has a file named 'aex.rc' in its etc subdirectory. > > Basically, nothing cares what a symlink says, except that it be > a valid reference to a file. > I had heard somewhere that I could make a symlink that called the file with parameters. I take it from your comments above that this is not true? >From your comments it sounds like bash is reporting the file not found for xae, but the file it can't find is '/bin/ae -f /etc/aex.rc'? I can do the same thing in a shell script, but this looked simpler and easier to manage...oh well ;-) Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coming to closure on ae...
On Sat, 2 May 1998, Oliver Elphick wrote: > Dale Scheetz wrote:... > >There doesn't seem to be a "reliable" method for determining whether or > >not you are in an xterm. Any method so far suggested has "natural" > >configuration situations that break the method. > > When you start an xterm, TERM is set to xterm; why not test for that? > The trouble with using different executables is that they will only > get run when the user chooses. I have found ae popping up unexpectedly > after I have removed elvis. Because I didn't choose to load it, it came > up in its default state. When you remove the last vi alternative, ae is run by a script in /bin with the ae2vi.rc file. The current release is broken in this reguard, but the next one will be fixed to continue to emulate vi. > > If someone manages to get an xterm where TERM is set to something different, > it won't work, but it seems a bit unreasonable for anyone to do such > a thing. > Although the xterm does set itself up with TERM=xterm, there are any number of reasons for the TERM variable to be changed (vt100 comes to mind for various telnet targets), which makes this an unreliable way to deal with this. What would be wrong with having the "non-x" ae tell you in the help screen what you need to run to get xterm support? The need for this xterm support comes from folks who want to administer a base system remotely from a system using an xterm. This is a fairly restricted set of folks who should be "clued" enough to deal with the help message. Ya think? Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coming to closure on ae...
On Sat, 2 May 1998, Rev. Joseph Carter wrote: > On Sat, May 02, 1998 at 11:42:39PM +0200, Oliver Elphick wrote: > > >There doesn't seem to be a "reliable" method for determining whether or > > >not you are in an xterm. Any method so far suggested has "natural" > > >configuration situations that break the method. > > > > When you start an xterm, TERM is set to xterm; why not test for that? > > Test $DISPLAY, it's the Right Way to test for X. I see: in a console the environmental variable DISPLAY is not defined, but it will be in any X window. Sounds like it should work for ae's needs... Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
who info and /etc/utmp
The who info page indicates that who finds its data in /etc/utmp, but I have no such file and who works ok. The file I do have is /var/run/utmp, which I can only assume who knows about. Is the info page wrong? Should I submit a bug? Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: who info and /etc/utmp
On Sun, 3 May 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > Is the info page wrong? Should I submit a bug? > > Yes. > > Aside: on solaris it's /var/adm/utmp, on the bsd system I have access to > it's /var/run/utmp, I don't remember what system would have it in /etc/. Coherent System V Which is probably where the man page originated. Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20914: seyon package copyright (fwd)
On Mon, 4 May 1998, Raul Miller wrote: > Steve McIntyre <[EMAIL PROTECTED]> wrote: > > I'm happy that we can work with this license, as we distribute diffs. > > Thomas thinks otherwise. Thoughts? > > This license conflicts with point 3 of DFSG. We can't distribute > modified versions under the same terms as the original. > I understand your concern here, but there is no restriction against distributing modified binary, only modified source. It seems to me that we have accepted non-modified source as DFSG compliant as long as modified binaries are not restricted. The license makes specific statements about what you can do (as well as what you can,t) and yet does not explicitly declare modified binaries to be acceptable. Is this what is bothering you too, Raul? I tend to be as flexible as possible when reading such documents, which is not always the way to arrive at the "legal" requirements. I would be happier if the author made it clear what the rules are for modified binary distribution. If there is clarification of this issue, I don't have any difficulty viewing the license as DFSG compliant. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20914: seyon package copyright (fwd)
On Mon, 4 May 1998, Raul Miller wrote: > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > It seems to me that we have accepted non-modified source as DFSG compliant > > as long as modified binaries are not restricted. > > We allow exceptions to point 3, as long as point 4 is satisfied > (explicit permission to distribute software built from > modified sources). > Yes, the fact that there was no explicit permission to distribute modified binaries was what I found problematic as well. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coming to closure on ae...
On Tue, 5 May 1998, Martin Schulze wrote: > On Tue, May 05, 1998 at 04:48:28PM +0300, Carlos Barros wrote: > > On Wed, 6 May 1998, Anand Kumria wrote: > > > > There doesn't seem to be a "reliable" method for determining whether > > or > > > > not you are in an xterm. Any method so far suggested has "natural" > > > > configuration situations that break the method. > > > > > > How about just checking for the existance of the DISPLAY variable? > > > > > > > What about trying to connext to X server, and if an error, do it in > > terminal mode. > > Which would result in opening X connections when working on the > console. No, that's not funny, this already happened with urlview > here, not funny to wait for your browser/editor while it runs somewhere > on X. > That would be my expectation as well. As it turns out, thanks to some excellent help from Jim Mintha, I can now build an ae.rc file that works both in the console and in the xterm. I still have some details to work out, but the solution is complete at this point. I want to thank everyone who contributed ideas. You were all a great help to someone out in the middle of nowhere. Much appreciated. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The early days of Debian (was Re: ideas underlying policy)
You may find the first section of the Introduction to "The Debian Linux User's Guide" (found at www.linuxpress.com) of some interest. It is titled History, and was, for the most part, written by Ian Murdoch, so you can trust its accuracy. ;-) Luck, On Tue, 5 May 1998 [EMAIL PROTECTED] wrote: > On Tue, May 05, 1998 at 12:10:54AM -0500, Manoj Srivastava wrote: > > Actually, when Debian was formed it had only one developer, > > and no one could contribute packages, since that would have diluted > > the distributions tight integration. This bazaar thing has evolved. > > I remember Debian 0.04. Basically, it was what we'd nowadays term "base + > bootfloppies" - an minimalistic base system on which to build the > distribution. Even then, mailing lists were central to development, and > development was a group effort. > > On Tue, May 05, 1998 at 08:41:03AM -0400, Raul Miller wrote: > > My memory doesn't extend back that far, nor have I found any documentation > > on that period. > > I don't think there is much documentation of that period; the Debian mailing > list was actually a "Debian channel" on the Linux Activists server run by > arl. It wasn't officially archived. > > > I presume you're talking about Ian Murdock's original plans, in some > > sense. Can you elaborate a bit on what those original plans were, and why > > they changed to the present (GNU style) form? > > The original plans are laid down in the Debian Manifesto (doc-debian: > /usr/doc/debian/debian-manifesto). > > Ray > -- > Tevens ben ik van mening dat Nederland overdekt dient te worden. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#21969: debian-policy: needs clarification about Standards-Version
On 6 May 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> On 6 May 1998, Manoj Srivastava wrote: > > Dale> During our past discusion on these issues I made direct requests > Dale> for clarifying statements about priorities of policies. I > Dale> specifically asked to be kept on the cc list for any discusion > Dale> of the issues. > > I think at the moment most of the policy document, unless > other wise indicated, is a MUST directive. I KNOW that is what you believe. It is the point of view that I most reject from any you profess to hold. > > > Dale> Debian's policy has always been one that rejects non functional > Dale> binary packages. > > If policy, if followed, creates broken packages, we have a > problem. Only because you insist on your "broken" view of policy. > > Dale> Even you have been willing to admit that Policy > Dale> is broader than "The Policy Statement". > > I never said that. The policy document set, (currently a > a set that is referenced in or pointed to by the core 3 policy > documents) is all that I see as policy. > So, we ignore the DFSG, pay no attention to the "Debian Manifesto", and completely ignore anything in any of the faqs, HOWTOs, or other related documents. Policy makes no mention of ANSI, or POSIX and may not even make reference to the File System Standards (this one may actually be referenced, but I haven't looked at the Policy Statement in a while and can't be sure). Do we throw all this in the trash? NO! Of course not! Be reasonable... > Dale> Do you deny that it is our policy to deliver functional binary > Dale> packages? > > I fail to see this in policy, but that is because I think most > people would take it as given; I understand it is a critical goal. In > fact, this has to be added to the policy, if people do not find it as > an acceptable unspoken rule. You can't have it both ways. If it is taken "as given", then how do people "not fine it as an acceptable unspoken rule"? Does anyone in this group think that delivering broken executables is either implied or stated anywhere in Debian Policy? I suggest that your counter example is "the empty set" and quite useless. I can think of no one (not even you ;-) who would consider delivering broken binaries to be even mildly suggested anywhere in "The Policy of the Debian Development Team" (which, of course, includes "The Policy Statement"). > > Dale> Do you suggest that the "strip binaries" rule should > Dale> superceed this prime directive? > > No. The strip binaries rule, if it contravenes this primary > directive, is quite obviously broken. You can't say "following blah > would break stuss, so I shall ignore it for now. However, I do not > see blah as wrong [even though following blah would break my > package]". I just don't understand this line of reasoning. > Your "understanding" is based of false assumptions. Any reasonable person would read any portion of policy similar to the "stripped binary" rule in the same way that I do. If you wish to make it more explicit and state clearly that stripping binaries is only desirable if it results in functioning code, you should feel free to work within the policy group and change the document to be clearer. I'm only going to say this once more: If you think it's broken, YOU fix it. In any case, I have no interest in hearing about how broken you think it is. I understand your broken attitude, but seem completely unable to mend it. As you seem unswayable by "reasonable" arguments, I will cease trying. Later, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Hamm
On Wed, 6 May 1998, Brian White wrote: > > > Several people have asked for this, but maintainers already get separate > > > reports about their packages and reports by package are available on > > > the web site, so I don't really understand the usefulness of presenting > > > it that way here. Is there something I'm missing? > > > > If your own bugs are scattered around in a list of several dozen, it is > > really easy to miss one. Grouping them together makes this less of a > > problem. > > I guess this is the part I don't really understand. As a maintainer with > open bugs, you're already getting mail from "nag" about them directly so > why would you depend on this general mail intended for everybody else. Don't even get me started on the nags ;-) In any case they have nothing to do with this message. If this message is not intended to inform maintainers which of their bugs are considered critical to the release then you can stop sending it along with those nags. > > However, as Jason pointer out, there is no reason at all for it to be sorted > numerically (other than perhaps a touch of athetics) so I've changed it to > sort by package name. The new sorted list should come out Friday. > This is just fine with me, as I do (sometimes) know which packages are mine. Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#21969: debian-policy: needs clarification about Standards-Version
On 7 May 1998, Manoj Srivastava wrote: > Fine. But the moment any package ``ignores'' policy and > insists policy is not broken, so should not be fixed, I shall file > bugs against the package. Which I will happily reasign to Policy. > > As the technical committee would look at the policy, either > the package shall follow policy, or policy shall be mended. I have no > intention of giving up on this. > Good! You have my complete support to "fix" any problems you see in the Policy Statement. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Source distributions (was Re: Intent to package pine-src)
On 7 May 1998, Falk Hueffner wrote: > Brederlow <[EMAIL PROTECTED]> writes: > > > It would be a great idea to have source dependencies. I compile all > > sources on my debian mirror and most fail because of missing > > files. One then has to search the package and install that before > > compiling again. > > A very simple way to improve in this area would be if it was allowed > in the policy to add a "Depends:" line to the .dsc file with the same > format as for .debs. Very easy. Developers probably would start to use > it, since it makes compiling really much easier for other people. Some > time in the future this field would probably be made obligatory and > tools for source extraction could be extended to check them. > > Any opionions? Whithout meaning to sound too negative, I want to caution against such patch and fill design. Ian J. worked very hard (and was very successful in my opinion) to design the current source package format to manage the various problems of absorbing and using upstream sources. We should be careful to craft any "improvements" to that format in a consistant and smooth fashion. That said, I am strongly in favor of a source dependency scheme. It just needs to be workable. WRT your suggestion above, I don't think that developers can/should edit the .dsc file (its check sum is computed by dpkg and provided in the changes file for dinstall to verify the components). The correct place for this information is in the control file. This file has, at least, two paragraphs. One source paragraph, and, at least, one package paragraph (one for each binary package built from this source). Currently package depends are placed in the Package paragraph. The logical place for source depends field is in the Source paragraph. Then dpkg-buildpackage (and friends) could construct the proper .dsc file containing the details of the source dependencies. I see only one problem with source dependencies: How do you tell the difference between a dependency on a source package and the depencency on a binary package. I know that most problems are with the need for some binary program to allow the build to proceed, but sometimes these needs are for a source file to be present (and in the desired location). In addition it would be nice if we could come to terms with upstream source in multiple tarballs (libc6 comes like that as do many others). There are a number of ways in which the source package format could be improved, and I agree that source depends are pretty high on that list. I only wish to caution against trying easy hacks with the distribution without much more thought and consideration. We should all feel free to try such ideas out on our own machines just to see how they might work, but we need much more discusion before actually moving in a particular direction. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#21969: debian-policy: needs clarification about Standards-Version
On Thu, 7 May 1998, Oliver Elphick wrote: > Dale Scheetz wrote: > >On 7 May 1998, Manoj Srivastava wrote: > > > >> Fine. But the moment any package ``ignores'' policy and > >> insists policy is not broken, so should not be fixed, I shall file > >> bugs against the package. > > > >Which I will happily reasign to Policy. > > Hang on, Dale. Just think about this. > > A package ignores policy - the only good reason is that policy is > inappropriate to this particular package. > > In that case, the policy is inadequate - file a bug against policy, > requesting a better definition. > > > But if the package maintainer says that policy is _not_ broken, the > fault must be with the package. Not true. If the package maintainer says that policy is not broken and the bug report says that the package violates policy, I would suggest that the policy needs ammending to clarify the issue and would reassign the bug accordingly. > > > You are saying that you would reassign a bug to policy, while at the > same time denying that policy is broken? That does not make sense. > Sure! Hasn't it been clear from the discusion between Manoj and myself that we each take different interpretations from the same document. I say the document is adequate for me to make the decision that it is proper for particular binaries to be delivered unstripped. This is clear to me from the Policy that I understand. From Manoj's point of view this is very unclear and should be fixed. I have no problems clarifying the document for others, even when I think I understand it correctly. If I believe that I am following the "full" Policy (while appearing to violate a specific clause) I have no problem with Policy being made more specific, for those who don't see things the way I do. BTW, I believe that this is why Ian wants a "Technical Committee". These kinds of debates cry out for a third party arbitration technique. Luck, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Hamm
On Thu, 7 May 1998, Brian White wrote: > The message is intended to inform _others_ of the problems that exists > in order to encourage them to help solve those problems. When people > whine about "When is Hamm going to be released?" I can just point them > to this weekly message and ask them what they've done to help. > So this is strictly for your benfit? ;-) I don't know if you have looked at the list of bugs against libc6 lately, but I find this list of "critical release bugs" to be of great help in organizing my time to the best effect. Putting the list in package order can only aid me in that effort. Thank you for "fixing" the order of the list! I'm sure that those you wish to entice to help via this list will also find it much easier to determine where help is needed, as well as possible. Thanks, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Wed, 26 Jan 2005 03:20:34 +, Paul Brossier <[EMAIL PROTECTED]> wrote: > On Sun, 2005-01-23 at 19:35 -0500, Dale C. Scheetz wrote: > > With regards to GNOME panel icons. The "add to panel" option now no > > longer offers "launcher from menu" so now with the "custom launcer" > > you have to hunt for your icon. > > well yes, here it does at least. you can also drag and drop it from your > menu. Yes, that works here too, but doesn't that use the icon displayed in the menu entry? For Spider I conformed to the menu spec and made the icon 32x32 pixels in xpm format. The icon I would prefer to use on the desktop/panel is 114x154 pixels and gives a smoother lookeing icon. I'll have to experiment with violating the menu spec and seeing how it works... > > On Tue, 2005-01-25 at 18:17 -0500, Dale C. Scheetz wrote: > > It might be better to reserve /usr/share/pixmaps specifically for menu > > icons in xpm format and create /usr/share/icons for png gif and jpeg > > icon images. > > i don't think this is the right way to go. gnome and kde use the > freedesktop standard and look for their icons in /usr/share/pixmaps. I see your point. I was not aware of the other "specifications". One single location for icons makes great sense. > other applications using icons should seriously consider looking in > there if they want to find any icon. clever ones could prune redundant > icon according to their file format preference. > > you don't really want to use jpeg in a menu do you? > Naaah, I just included it for completeness, png is a much better format ;-) > > Is it worth while trying to get some general icon policy established or > > am I straigning at gnats? > > another manual does not seem required. but mentionning the use > of .desktop would be a worth addition to the menu manual. > Except that it has little to do with the menu specification. For those like me who went searching for "icon" in the docs it would be nice to have a section with that title that points at the menu spec and the desktop spec and any other useful help with icon managment. > see http://standards.freedesktop.org/desktop-entry-spec/latest/ > This is very useful. Thank you! BTW, DSL (Damn Small Linux, a Debian based live cd distro) uses its own desktop icon format in a .lnk file in the .xdesktop directory for that user. I'm still left with a question: How do I, as a package maintainer, provide these .desktop files so the user either automatically or by some simple choice gets the icon on their desktop? Waiting is, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On 3 Jun 1998, Manoj Srivastava wrote: > Hi, > >>"Philip" == Philip Hands <[EMAIL PROTECTED]> writes: > > Philip> No, because democracy is inefficient in our case. > > Inefficient or not, if it is the only thing that works ... > As Philip and others have pointed out, that is as feable an argument as has ever been made. I simply doesn't "work for Debian". If you look at the percentage of the list traffic taken up with the "How Shall We Organize Orselves" type threads, as compared with the percentage of "What do we need to DO to GET HAMM OUT THE DOOR?" (and YES there is a need to yell about this), and you will see that we are currently "wasting" large quantities of Debian Bandwidth doing "pure politics" and little else. We must recognise two things: 1. Debian functions as a "Goal Oriented Anarchy". (Bruce called it "Herding Cats") 2. The only reason it is functional is that all the cats have the same goals (for the most part). The best way to achieve goals in this environment is to discuss the goals, not the best way to get everyone to work toward them. If the goals are well thought out (read well discussed) we must rely on everyone doing their part toward those goals. Whenever we divert our attention from these tasks we loose ground. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On 3 Jun 1998, Manoj Srivastava wrote: > Hi, > >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Dale> We must recognise two things: > > Dale>1. Debian functions as a "Goal Oriented Anarchy". > Dale>(Bruce called it "Herding Cats") > > Dale>2. The only reason it is functional is that all the cats have > the > Dale> same goals (for the most part). > > It has gotten to the point that the cats have to have a > process to recognize the goals. The constitution provides the > process. The constitution does not "provide" a process, it defines one. It is the developers in this group, working together, who create "process". It is primarily this mailing list that "provides" access to that process. > > Also, it is easy to define fuzzy goals: Defining fuzzy goals is not the best way to approach this problem, so why do you wish to waste time in this fashion? > a) we need hamm out the door now > b) we neeed to release more often, and on schedule > (I like guys proposal of an updated stable pool that can be > tested continuuls, frozen, and released fast -- since there are > never any release critical bugs in the stable pool, the current > delay does not occur) > c) we need to cater to unattended installs/ replication in compute > farms > (Ians proposal of a question asking spec was a good > start. Linuxconfig and COAS are also promising) > d) We eed to get a better front end than dselect > APT is coming along > e) We need to do a size-required-for-installation thing > > . > > n) make debian the best free distribution in the whole darned world > I always thought this was #1 (or 'a)' if you insist) > There. Goals galore. If you want more goals, just ask. I can > create goals by the minute, no problems. Are we satisfied now? > Hardly. For goals are nothing unless they can be fleshed out. Goals > by themselves are vapourware. Hense the need for "discussion", a key word you seem to have forgotten. > > Since people want to discuss goals, let us get this over and > done with. Email me goals, and I promise to have a 100 by the Such discussions are never over ;-) > weekend. Then maybe we can get off and try and actually *DO* > something, like design and implementation, rather than sit around > talking goals. > Design and implimentation follow goals, not the other way around. A discussion requires setting goals and determining just what is necessary from each of us to make these goals attainable. Waiting is, Dwarf -- _-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#2042: -help
-help --help
Bug#2042: less-290-5
Sorry about the first message on this bug, I was trying to figure out how to submit one and accidently submitted the gaff instead. This report should have said: Running kernel 1.3.43 in a 1.0 ELF system; less-290-5 has been patched for the /proc filesystem, except that when you less a proc file, less eats the first character of the report. Thanks, Dwarf aka Dale Scheetz
m4 rebuilt as ELF
I have rebuilt the m4 package as ELF (per Ian J.'s request) and placed the binary package into ftp.debian.org//debian/private/project/Incoming. I haven't figured out how to create a .changes file yet (any pointers would be appreciated) but it should look something like this: Package: m4 Priority: standard Section: devel Maintainer: Ian Jackson <[EMAIL PROTECTED]> Version: 1.4 Revision: 2 Description: GNU m4 - a macro processing language YHS, Dwarf
