HD TV as Monitor
I have a Samsung 42 HD TV. It has a connector for a computer monitor input, and I have been trying to get a computer hooked up to use it as a monitor with little luck. If the machine runs Windows it will use the monitor correctly as a display. If I run Damn Small it will display, but the bottom portion of the screen is below the bottom of the TV screen. Ubuntu, Knoppix, and Debian all produce Mode Not Supported messages on the TV but produce no display. If I try to use the Debian Install disk to create a new system, the boot up stuff displays fine, but when it gets to the first installation screen the text is diagonally ripped and unreadable. On one of my laptops, even in windows there is no display. (I assume that the graphics card in that machine doesn't support the screen modes necessary. On the machine where windows works, I assume the graphics card is capable, and I only need a functional MODE line in the config file. At work we use wide screen TVs as monitors in meetings where groups need to view the screen, but then we only have Windows machines there... Does anyone have any idea what the mode line should look like for these devices? I also want to take this time to thank you all for the great advances that Debian has made since I retired from the group the hardware detection and automated update processes are truly wonderful! And, thank you for keeping Spider in the distribution, I really appreciate it! Please CC me on all responses as I am not currently signed up to this mailing list. Luck, Dwarf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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: Discussion - non-free software removal
On Mon, 25 Nov 2002, Branden Robinson wrote:
On Mon, Nov 25, 2002 at 11:22:42AM -0800, Adam McKenna wrote:
What you seem to be implying is that there is something wrong with the
desire to preserve the way things are now (regardless of the
motivation). Is this your position?
There is not necessarily anything wrong with it. However, I cannot find
Preserve the Way Things Are Now in Debian's list of committments in
its Social Contract with the Free Software Community.
No, but the subject of debate is clearly called out in that document.
At this point in time I don't see any gain to keeping, or removing
non-free. In the past I saw this as an example of what we considered
non-free (I mean, get a grip. Whatever is there is freely available in
lots of other places on the net. It is the DFSG alone that declares such
software anathema. {and then takes it all back in the non-free clause...})
Of all the things that confuse me, this was not one of them, although I
understand some folks confusion. We have a definition of Software
Freedom in the DFSG, and example code for what constitutes non-free in
the designated section called out in that very same document. Makes sense
to me, but offends the sensabilities of others.
So someone feels unfulfilled no matter which way the decission turns.
Maybe we should all give up and go back to working on software ;-)
Waiting is,
Dwarf
--
_-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_-
_-_-
_- aka Dale Scheetz Phone: 1 (850) 656-9769 _-
_- Flexible Software 11000 McCrackin Road _-
_- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_-
_-_-
_-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_-
available at: http://www.polaris.net/~dwarf/
Debian based CD based distros
It appears that Debian is finally being used in the ways that we have been wishing for since before Bruce was DPL. YES, there are now some very impressive Debian-based distributions available from several sources. The first one I was shown by my neighbor is called Knoppix 3.1 and is produced by a German group. As a result it comes up in German, but there is a simple fix that will boot it in English (boot: knoppix lang=us) that only requires you to know that the equal sign is a shift 0. This CD boot up on any Intel machine, recongizes the hardware, negotiates an IP address, and provides a very well crafted KDE desktop. Also included are three pieces of FREE music. The software recognizes the sound card in most hardware, and only a few clicks of the mouse are required to play some cool sounds that are distributed under what looks like a DFSG compliant license (modification a distribution are both permitted} if you consider a wave file adequate source for music. While that was pretty impressive, my neighbor showed me bb which is an ascii art demo program with full sound and impressive ascii artistic displays. Open Office is also provided, which allows you to boot this CD up on an M$ machine without any impact on the file system, and edit Word and Excell documents on that machine without having to suffer the hangs and other failures I see every day at work. More than that, I will be using this CD when I need to work at the local library, and don't wish to leave any tracks on their machine. (Several libraries are worried in this day of terrorism driven government that their hardware might be confiscated to preserve evidence of terrorist activities [more likely to provide free hardware for the local constabulary], and this CD could allow them to run esentially diskless systems. Either a floppy or a zip drive could be provided by the user to carry away desired information, leaving the libraries hardware void of any interesting information, with no more reason for its confiscation...) The other CD I have seen is provided by CheapBytes, and is simply called DemoLinux 3.01. I haven't figured out who produces it, but it is very similar to the Knoppix CD except that it does not include the free music that Knoppix does. The main reason I mention these two excellent Debian spin-offs is that they both do a remoarkable on-the-fly hardware configuration for X and everything is wonderfully integrated and ready-to-use to a much greater extent that Debian is by itself. Those folks working on installation and configuration of the system could learn a lot from studying these CDs, not that we need to deliver a CD based release, but that we need a much quieter and more user friendly installation. While SUSE uses proprietary code to provide a very hands-off installation, with great hardware detection and no-info X configuration, there are things that can be learned from this product as well. SUSE is soo nicely integrated that I have begun recommending it for installation as Work Station replacements for perviously Windows based shops. The learnign curve for the user is miniscule, as everything is layed out in a familiar fashion and Open Office (also provided) provides the look and feel of the older office suite from M$ which they are already familiar with. (and the $49 one time purchase price beates the $200 per seat that my office pays for the priviledge of using Windblows) I still recommend Debian for server applications. It is still more powerful and complete that the professional package that SUSE provides, but maybe that is only because I understand Debian configuration better than I do SUSE ;-) For those of you who have not seen Knoppix or DemoLinux, I highly recommend you take a look at them, you will be very proud of the use Debian has been put to by these distros. (Give me a ping if you need a Knoppix CD. I'll be glad to toast one for you...) Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Non-Intel package uploads by maintainer
Since I have access to both Intel and Sparc hardware, it would be possible for me to upload both the i386 version and the Sparc version of the binary packages when I build a new release. Is there any reason not to do this? It seems that it might speed up the autobuild process, specially when it is a library like libgmp3 which other packages depend upon for their builds... The only problem I can see is in the construction of the dsc file. I get one built on the Intel and another one built on the Sparc. Must I do two uploads or is there a way to merge the two dsc files? TIA, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
On Tue, 9 Apr 2002, Branden Robinson wrote: On Tue, Apr 09, 2002 at 02:03:11PM -0400, Dale Scheetz wrote: The history section in my book, which is declared invarient in the license, was written by Ian M. and has no technical bearing on the rest of the book's content, but has every reason to be protected from modification. These particular words have a value that must be protected. I'll put you down as being in favor of eternal copyright, then. Give me a break. I've never said that, and your suggestion that what I said implies I believe your suggestion is ... stupid. This is exactly the kind of distraction by misdirection that I so greatly detest. The Congress shall have the power to PROMOTE THE PROGRESS OF SCIENCE AND USEFUL ARTS, by securing for LIMITED TIMES to authors and inventors the exclusive right to their respective writings and discoveries; And in 10 or 15 years the historic material in my book, (not to mention the technical content ;-) will not matter one way or another. If there _is_ any historical significance to this content, other forces will protect it. (Emphasis added.) What a tragedy that the value of all works published before 1926 has been irrevocably lost because we're not protecting them anymore. Well, the fact is that those old works are protected specifically because they have survived. The Declaration of Independance needs no copyright to protect it. (However, I've been greatly disturbed by the interpretation our present government places on certain phrases found there...) The real problem with most of those pre-26 books is that I can't find them in print today... I actually agree with you, (If I haven't made a stupid assumption based on your initial statement ;-) eternal copyright doesn't stimulate creativity. Just look at the new and interesting stories being told by Hollywood about everyone from Mr. I. Crane, to Peter Pan. All possible by the expiration of those copyrights on the original books. While I'm not sure that M. Mouse should be owned by anyone but Uncle Walt, I understand the fear of the current copyright holder, given that I am in direct contact with the spirit of the original Mr. Disney. He has some very clear ideas about the uses of this icon, and they would not set well with the current owner. Maybe I should find a lawyer and argue in court that the original copyright holder should be given back control of his intelectual property... Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
On Wed, 10 Apr 2002, Richard Braakman wrote: On Tue, Apr 09, 2002 at 02:03:11PM -0400, Dale Scheetz wrote: The freedom of expression of the author is what is being protected by this clause. The freedom to express opinion without having those statements twisted into something completely different is one of the reasons for the creation of the copyright in the first place. A version of the GFDL that allowed deletion but not modification of such sections would be perfectly acceptable to me. I would have no problem with that either. However, I'm left with the current license as the one that come closest to my needs... On the other hand, this would give a publisher the power to silence some statements in favor of others, but then, from my experience, publishers have this power without copyright control, as they hold the power to put those words on paper or not. With internet distribution, (currently the state of my book ;-) this power is somewhat diluted. At least for those who know can find the original text. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upload rejected: md5sum for .orig.tar.gz doesn't match .dsc
This happened to me on my first upload of libgmp3_4.0.1. At first I thought it was a breakage caused by this library, but eventually resolved the problem by upgrading ssh. (I use scp to do uploads to auric) The tarball was being corrupted by ssh during the transfer. HTH, On Wed, 10 Apr 2002, Daniel Kobras wrote: On Wed, Apr 10, 2002 at 10:37:35AM +0200, Joost van Baal wrote: Your package upload (cl-imho, manpages-de, tiger) was rejected due to a mismatch in the original source md5sum. I saw this in auric:/org/ftp.debian.org/incoming/REJECT/*.reason . The package I maintain (lire) was rejected for the same reason. I have absolutely no idea how this was caused, or how to fix it. Most likely this is caused by different timestamps in the tarballs. It happens to me occasionally when I cvs-buildpackage on a machine where the .orig.tar.gz is not present and thus rebuilt from a new CVS checkout. Just apt-get source the tarball from the archive and dpkg-buildpackage with it. Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
On Mon, 8 Apr 2002, Joseph Carter wrote: On Mon, Apr 08, 2002 at 09:53:54AM -0500, Jeff Licquia wrote: DFSG stand for Debian Free Software Guidelines. Yes, and since Debian is 100% Free Software, that applies to everything in Debian. Documentation isn't software. Neither are conffiles, icons, etc. So, if we're to be true to our creed, here's what we have to do: Ahh, but icons which fail the DFSG have been declared non-free in the past. So we have (still more) precedent for applying the DFSG to non-software. The point being made, which everyone is so carfully ignoring is the word Software in the title. These are software guidelines, nothing more. They don't even define the whole of Debian, just the software. The differences are obvious. While my book is written in LaTeX, and the image file (ps or pdf) is constructed from these source files via the use of Make, it is very different from what we call software. The difference is in the target. The output of the LaTeX compiler is intended to be viewed by a human being, who, hopefully, has the capability of not following written instructions or ignoring contrary philosophies. The output of the C compiler is intended for a specific CPU, and all instructions are forced upon that CPU with no choice over which it will execute and which it will ignore (thank goodness for that ;-) My freedom is enhanced by being able to make those instructions for the CPU be just what I want them to be. (This machine IS after all my slave) My modification needs extend over the complete work as defined by the source, and we can all see just why this should be. The history section in my book, which is declared invarient in the license, was written by Ian M. and has no technical bearing on the rest of the book's content, but has every reason to be protected from modification. These particular words have a value that must be protected. The front and back cover text may be used to give credit to someone who provided substantial financial support during the time of the works production. Without requiring such credit, other publishers could benefit from the work without giving the proper credit. None of these issues force behavior on the reader, like code does for the CPU. So no freedoms are being infringed upon by forcing the text to remain unchanged. The freedom of expression of the author is what is being protected by this clause. The freedom to express opinion without having those statements twisted into something completely different is one of the reasons for the creation of the copyright in the first place. If you insist on judging documentation against the same standard as software, the results are always going to be wrong. Just to contradict my previous statement: The GPL allows (demands) two invarient sections of the original source; the copyright statement, and the license statement. Requiring these sections to be invarient does not make the license non-free. These sections are, in fact, necessarily invarient if the author's and the user's rights are to be protected. Allowing non-technical content to be made invarient does nothing to restrict the freedom to modify the parts of the document that are a technical description. Using my book as an example, there have been many patches submitted either for spelling or content. I have included all those that were correct ;-) I have never seen the book published with changes that were not made by me, so it isn't clear to me just what the pressing modification requirement is in the first place... Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
On Sun, 7 Apr 2002, Manoj Srivastava wrote: Well, since there are these other issues being raised (specificcally, the concern that GFDL may not meet the DFSG [I happen to disagree with that statement, for what that counts for]), we should wait for the dust to settle down before moving things into an area designated for common, free, licenses, don't you think? Well, if you insist ;-) Actually, on more reflection, (asside from whether or not the GNU Free Documentation License is Free) the whole purpose of the common license area was to reduce the file space consumed by multiple copies of the same license. Thus if two packages use the license it is cost effective to place a copy into the common area. With respect to the freeness of this license. It would be a real shame for Debian to declare this a non-free license, as much of the GNU documentation currently making the move to this license would have to go into non-free... Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
On Sun, 7 Apr 2002, Branden Robinson wrote: On Sun, Apr 07, 2002 at 02:36:28PM -0400, Dale Scheetz wrote: 3. I placed my book under this license with the express understanding that it was considered free. Now I'm hearing noise that this is a non-free license. While I disagree, that is often irrelevant. 4. If we still have no free documentation license. I'm not sure how we can make demands for good documentation. As usual, this issue has been beaten to death on a list you don't read. Please review the archives of debian-legal for the past several months. In a nutshell: 1) The current version of the GNU FDL is uncontroversially DFSG-free if there are no Cover Texts and no Invariant Sections. Note that your license notice is supposed to indicate the presence or absence of Cover Texts and Invariant Sections. 2) The Open Publication License (OPL), is also uncontroversially DFSG-free when none of the license options are exercised. So, in fact, both of these licenses are non-free, as they contain clauses that can be used, and will be considered non-free. I find it ... foolish to declare a license to be free IFF some clauses of the license are not exercised. Using this language, any proprietary license becomes free as long as none of the proprietary sections are inforced by the author... The license is a complete text. It is either free or it isn't. Selective editing creates a new license that may or may not actually exist. If this is the kind of logic that is being used on the -legal mailing list, I'm glad not to expose myself to such nonsense. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
On Sat, 6 Apr 2002, Manoj Srivastava wrote: Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale There are an ever growing number of packages that make use of Dale the GNU Free Documentation License. Isn't it about time to put Dale a copy of this license into the common reference area? Depends. Would you say that at least 1% of Debian packages use a license before it be deemed ``common''? How many packages use this license, then? I can't answer any of your questions ;-) What I do know is: 1. The GFDL is a published license of the FSF, intended for use by documentation. 2. The documentation provided by gmp-4.0.1 is now GFDL. This indicates a move by GNU to use this license more broadly. 3. I placed my book under this license with the express understanding that it was considered free. Now I'm hearing noise that this is a non-free license. While I disagree, that is often irrelevant. 4. If we still have no free documentation license. I'm not sure how we can make demands for good documentation. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
On Sat, 6 Apr 2002, Joseph Carter wrote: On Sat, Apr 06, 2002 at 05:57:43PM -0500, Dale Scheetz wrote: There are an ever growing number of packages that make use of the GNU Free Documentation License. Isn't it about time to put a copy of this license into the common reference area? Who should I talk to about this? Why put a blatantly non-free license in the common licenses directory? You clearly have an opinion on this issue ;-) I suppose this stems from the invarient section clause in the GFDL? While this declaration is broader than the same feature in the GPL, I don't see the problem. The GPL allows the license and the copyright statements to be both required, and invarient. The GFDL simply recognizes that documents often have historical, philosophical, or political statements that should, yes need, to be protected from modification. These sections, such as the history section of my book, writen by Ian M., deserve protection if truely free speech is to continue to be protected. The technical material can then be left modifiable as is needed and useful to such matherial. What would be a more suitable Free Documentation License in your view? Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
There are an ever growing number of packages that make use of the GNU Free Documentation License. Isn't it about time to put a copy of this license into the common reference area? Who should I talk to about this? Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quake 2 sources GPL'd
I'm willing to accept the quake2-engine in non-us as long as it is available somewhere with a maintainer to bounce issues off of. I suspect that myself and Ben excluded everyone else will accept it going into contrib... I've downloaded just about everything there is at ftp.idsoftware.com and the docs are correct, there is no completely functioning edit tool for building game data files. There has been talk on this thread about someone trying to get it together to build such and editor/datastructure but nothing is known to have come of it. I'd love some starting points to begin a search for just what _was_ accomplished. As I see it, there needs to be a datastructure definition before there can be an adequate game editor, so there are two major jobs that need coordination with predefined lack of overlap (clean room...) I can do either one of these jobs with some help, but I'd rather work on the editor group if there were an adequate spec... I've e-mailed Jamie Wilkinson (who said he was working on a .deb) and offered my services to help get a totally free game on the table. I haven't heard back yet, but it is the holidays ;-) Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Quake 2 sources GPL'd
On Mon, 24 Dec 2001, Branden Robinson wrote: On Mon, Dec 24, 2001 at 11:50:11AM -0500, Dale Scheetz wrote: I'm willing to accept the quake2-engine in non-us as long as it is Eh? non-us? Did the Supreme Court just uphold COPA and declare Quake2 harmful to minors or something? Translation (For Branden): I don't care where you decide to put it as long as I can download a package and talk to its maintainer. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Quake 2 sources GPL'd
On Sun, 23 Dec 2001, Peter Makholm wrote: Dale Scheetz [EMAIL PROTECTED] writes: But I wouldn't dream of trying to do such a thing without a game engine to test it on. How else to you test what you built? Why would you ever build a game without an engine to run it on? How is preventing you from installing quake from contrib or in any other way? The only thing I think people has said is that as long as there doesn't exists frre levels Quake should go into contrib and not into main. My point was that I have a valid use for the code even though there exists no free game data. I need the game engine to create a game. Thus it is useful even when no game exists. My apt-get is set up to follow main, contrib, and non-free. I only worry that a package exists before I try to download it. Apt-get install quake2 fails to find any package in woody. And what do I download for game building tools? So far I'm stumped ;-) Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Quake 2 sources GPL'd
On Sun, 23 Dec 2001, Hamish Moffatt wrote: On Sat, Dec 22, 2001 at 01:42:41PM -0500, Ben Collins wrote: blimpo:~# gcc gcc: No input files You have to write or get code for gcc. Should we deliver a hello.c with gcc to meet those same requirements? You do realize that there are You might be surprised to learn that we actually ship quite a bit of C source code in Debian suitable for use with gcc. Not to mention the source code for gcc itself ;-) Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Quake 2 sources GPL'd
If there are tools available for building game levels, I'd certainly build at least one level... But I wouldn't dream of trying to do such a thing without a game engine to test it on. How else to you test what you built? Why would you ever build a game without an engine to run it on? Lets not get the chiken/egg problem so screwed up we can't ever have chicken _or_ eggs! I need access to a game server/engine way before I begin to write game territory. Free Quake II! On Sat, 22 Dec 2001, Branden Robinson wrote: On Fri, Dec 21, 2001 at 11:57:21PM -0800, Thomas Bushnell, BSG wrote: If the only practical use of the engine is to run non-free levels from id, then it belongs in contrib. But that's obviously not the case. A game engine, especially one coded in large part by a luminary in the fieldlike John Carmack, is interesting and useful (to programmers) in its own right. We wouldn't stick a Free compiler or interpreter for some new-fangled programming language in contrib simply because no Free programs written in that language were yet packaged for Debian. I would, however, be tempted to mark such an engine as Priority extra until Free game levels were packaged for Debian, so that Debian's many non-programming users would not get their hopes up at being able to play the game in Debian as distributed. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
OT: new use of Open Source
I just heard an analyst on the radio use the term Open Source to refer to intelligence information that could be made public! This struck me as proof that this movement has penetrated the general public more than I suspected. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Potato to Woody upgrade problem
On Mon, 24 Sep 2001, Noah L. Meyerhans wrote: On Mon, Sep 24, 2001 at 11:53:38AM -0400, Dale Scheetz wrote: I copied XF86Config from my old Woody system into the newly upgraded system and, while startx works just fine, wdm starts up but doesn't start the server, or log any messages in /var/log/wdm.log. (the log file exists, but is empty) (current version of wdm is: 1.20-11.2) What's in /etc/X11/default-display-manager and /etc/X11/wdm/Xservers? There is no file /etc/X11/default-display-manager. What should it contain? /etc/X11/wdm/Xservers has the one uncommented line: :0 local /usr/bin/X11/X vt7 -deferglyphs 16 Thanks, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Potato to Woody upgrade problem
On Mon, 24 Sep 2001, Noah L. Meyerhans wrote: On Mon, Sep 24, 2001 at 11:53:38AM -0400, Dale Scheetz wrote: I copied XF86Config from my old Woody system into the newly upgraded system and, while startx works just fine, wdm starts up but doesn't start the server, or log any messages in /var/log/wdm.log. (the log file exists, but is empty) (current version of wdm is: 1.20-11.2) What's in /etc/X11/default-display-manager and /etc/X11/wdm/Xservers? Sorry, my last report was bogus. I was looking at the old Woody setup ;-( On the installation in question the Xservers file has everything commented out. The default-display-manager file contains the line: /usr/bin/X11/wdm I put the correct line into the Xservers file and wdm comes up as expected! Thanks! (what process should have put this in?) Now I seem to have some font problems. Netscape seems to be OK, but the GIMP comes up with [] [] [] [] [] in place of the hint text. The title bars are OK but any filled in text is just [] repeated. Any hints? Thanks for the pointers, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Potato to Woody upgrade problem
I was gifted with a 2 gig SCSI drive, so the first thing I tried was installing a system. I installed Potato from a set of CheapBytes CDs, but did not set up X at that time. Then I upgraded over PPP to the latest Woody archives. The automatic X setup failed, but then I've never had that work for me. I copied XF86Config from my old Woody system into the newly upgraded system and, while startx works just fine, wdm starts up but doesn't start the server, or log any messages in /var/log/wdm.log. (the log file exists, but is empty) (current version of wdm is: 1.20-11.2) With no clues from the log file, I'm stumped. Anyone have any idea what I'm missing? (I have config files in /etc/X11 as well as a link in /usr/X11R6/lib/X11...) BTW, dist-upgrade failed, suggesting the -f, which I did. It actually took 3 cycles of dist-upgrade followed by -f before I got a clean setup. I also had to go over the dpkg -l listing and clean up the remaining rc statused packages. At this point, all packages are ii so I have a clean system where wdm isn't working... When I recently upgraded my older, working X system, the resulting upgrade worked fine to start the server, but I now have the gnome preferences icon on my desktop configured to look for the preferences program in the wrong place. (the program is in the new location while the icon still looks in the old place) Any ideas how to fix the icon? TIA, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Need historical data
I've been doing some historical research on Debian, and find that although I'm the biggest pack-rat I know, I'm missing some important data. What I need are the Maintainers files from the 2.1 and 2.2 releases. I could also make use of the overrides files from these releases If you happen to have any of these files, please feel free to e-mail them to me. Thanks in advance, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: [FLAME WARNING] Linux Standards Base and Debian
On Wed, 9 May 2001, Marcus Brinkmann wrote:
On Tue, May 08, 2001 at 10:07:57PM -0400, Ben Collins wrote:
I agree. The LSB should contrast/compare features of both and come up
with a superset of both (possibly favoring ones implementation over the
other). Most importantly, the metadata format needs to be standardized.
That is the key component. If that is standard, then the binary format
means very little (since a simple converter can be created just like
alien).
I think it makes more sense for the LSB to define an intersection of
required features, and use only that for their stuff. Then other people can
easily implement this minimal interface or convert to/from it.
In fact this is what was done. RPM supports an infinite number of
installation scripts. Some of these scripts are run from triggers. No
other Package Format does this. LSB will limit the number of scripts to
match the structure of .deb files, as I understand things.
The LSB doesn't need the full power of a complex packaging system, and it is
unlikely they would get it right without really using it.
The LSB will never specify a packaging system. I will restrict itself to
only the package format including a binary component format {sorry Ben ;-}
Luck,
Dwarf
--
_-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_-
_-_-
_- aka Dale Scheetz Phone: 1 (850) 656-9769 _-
_- Flexible Software 11000 McCrackin Road _-
_- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_-
_-_-
_-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_-
available at: http://www.polaris.net/~dwarf/
Re: Bug#96224: libgmp3: Move documentation in the -dev package
On 6 May 2001, Christian Marillat wrote: DS == Dale Scheetz [EMAIL PROTECTED] writes: [...] DS I can be convinced on either count. How would you feel about my presenting DS this issue to the developers at large, with you and I agreeing to follow DS the concensus of the group? Go ahead. DS At this point that seems a waste of time ... I've had a nights sleep on DS it, and I'm currently leaning toward the extreme solution. So I forward this myself. DS Arguments: DS 1. It's been like this forever... DS 2. No one (with the exception of Christian) has ever asked that it be DS moved, and several requests have been made for additional documentation. DS 3. The documentation is development in nature, and should go into the -dev DS package. DS 4. The info, demos, and docs sections are about as large as the libraries DS themselves. Removing them from the runtime is a 50% savings. 5. You can't build demos source if the -dev package isn't installed. So, the demo code is not really to be built, but is just for study. If you really want to build it, you are obviously going to need the devel package. I guess the docs could suggest -dev. 6. Example files should be installed in /usr/lib/package/examples According to the Debian Policy chapter 13.7 This doesn't determine what package it goes in... DS Conclusion: DS While the principle of least surprise is important, it should not be DS used to stifle progress. Moving the docs and demos out of the runtime DS package is a significant bloat reduction. Moving them into -dev is not. DS Making a third package -doc, containing the info, doc, and demo sections DS now found in the runtime package makes the most sense. Thus a DS non-development system can still have complete documentation when needed DS without either the runtime or the -dev packages installed. (screw 'em if DS they can't find it ;-) My conclusion: You can't build demos source if the -dev package isn't installed. And the info documentation is *really* for developper. This package contain libraries, so an end user don't need to know how to program this library. YOU think the info docs are only for developers. I think anyone could wish to read and understand them. I'm not sure I understand your last sentance. What does the fact that the runtime contains libraries have to do with programming the library? More to the point, what did you find wrong with my solution? Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Bug#96224: libgmp3: Move documentation in the -dev package
On 7 May 2001, Christian Marillat wrote: SMR == Steve M Robbins [EMAIL PROTECTED] writes: SMR Hi Christian Dale, Hi, [...] SMR If Dale has agreed to do move the docs (either to -dev or to -doc), SMR that seems to me to answer the bug report. I don't understand what SMR question Christian's posting to -devel is supposed to raise. Dale said in his conclusion : DS now found in the runtime package makes the most sense. Thus a DS non-development system can still have complete documentation when needed DS without either the runtime or the -dev packages installed. (screw 'em if DS they can't find it ;-) So, asside from screw 'em what's wrong with this statement? Putting the docs in a separate package means that you can choose to read the docs without installing either the runtime or the -dev packages. You are also free to install any combination of the three that suites your needs. As the runtime and the docs packages are both about the same size, I saw no reason to bulk up the -dev package with unnecessary cruft. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Bug#96224: libgmp3: Move documentation in the -dev package
On 7 May 2001, Christian Marillat wrote: DS == Dale Scheetz [EMAIL PROTECTED] writes: [...] DS More to the point, what did you find wrong with my solution? This is Monday syndrome, I've misread you post :-( Well, I hope things have gotten better ;-) I agree with your solution. Great! One point, I think you made, was that the demos should really go in /usr/share/lib/libgmp3/demos. As these are not really useful components of this packages, and mostly intended as examples of how you might use the library to write code, I'm not certain this policy applies. If you still think they should move into this location, please drop me a bug report so I don't forget it next weekend when I can next work on the package again. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: problems with atari800
Thanks to all for the fine pointers. I'm still unable to obtain any ROMs for the emulator. I guess I could ask on debian-user, and see if anyone has some copies they'd be willing to share. Anyone have any idea what the chances are of getting Atari to release some of this stuff into the public domain? Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
problems with atari800
I've been working on getting the newest atari800 code to build for Debian, and I've run into some problems. (Well, yes, I'm having some compilation problems as well, but this isn't about those...) There are several sites that are pretty critical to the proper opperation of this package that I can't get to at all. I've been having problems with my new 2.2.19 kernel and mozilla's proper behavior, however this behavior is also seen when running 2.2.17, like I am using now. Also, on a clean running kernel and netscape I get consistantly poor results. http://atari800.atari.org/ is listed as the canonical source for all things atari, but a ping of this address simply hangs. On the other hand: http://www.signus.demon.co.uk/david/atari/atari.html is even more important as it is the repository of all the various machine ROM images needed to make the emulator do something useful. If I ping www.signus.demon.co.uk I get an immediate unknown host error. I _can_ ping other sites with no particular problem. If my local network configuration is fragged, it is a very subtle situation, and not likely anything I intentionally set up ;-) Even once I can compile the current release, I'm not happy doing all this work, only to be unable to make it work to any good purpose when complete. Can anyone verify the existance/non-existance of these sites? The site that _does_ work for me is: ftp://ftp.sophics.cz/pub/Atari800 and you can pick up the source for 1.0.6 (the latest version) that includes several other links in materials found in the DOC subdirectory. I'm not sure whether I can trust my browser (or ping) to tell me the truth, as I currently have my Sparc in such a state that I can't ping out the ppp connections ;-( so it wouldn't surprise me to find something subtly broken on my main intel machine as well... And I know from extensive testing that an NFS enabled 2.2.19 kernel will royally fragg mozilla's ability to make certain kinds of connections. These symptoms go away when the previous kernel is booted. So at this point I don't feel like I can trust anything I know about my system, or what it's doing to me this time. Does any of this make any sense at all? Are the above sites really unavailable? Help, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Solution found, was Re: New X problems...
Well, since I usually want to know what's happening (as well as having a functioning system) I did some investigating last night, and found that, after 'make mrproper', menuconfig shows that the NFS file system is enabled by default. With this option enabled, the errors occur in X. Without this option X works fine. I have no use for NFS, so it isn't a problem, but this could really suck on system that want to use NFS. I haven't tried making NFS as a module, but I suspect the bug is still there, whatever it is. Thanks for all the help, On Sat, 28 Apr 2001, Josip Rodin wrote: On Fri, Apr 27, 2001 at 12:19:03AM -0400, Dale Scheetz wrote: David, from your comments below, you seem to be using kpkg, while I use make. I got my 2.2.19 source from ftp.kernel.org, and, after a bit of unusual bother untarring it, did 'make mrproper ; make menuconfig'. At this point I had to go get ncurses4-dev ... somehow it failed to upgrade last time... Anyway, I usually work through every option in the config menu. I like the menuconfig option because it is easy to go back and forth between various areas of configuration. You should probably try copying the .config file that you used with 2.2.17 into the directory where you unpacked 2.2.19, and then run make oldconfig. It looks like make config, but it'll skip over already answered questions and ask you any new ones. After that is done, you can still run make menuconfig and prune whatever you think may be bloat. However, if you unpacked the new kernel in the same directory and already did make mrproper, it probably removed the .config file... -- Digital Electronic Being Intended for Assassination and Nullification Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: New X problems...
Yes, I have no NFS, I have no NFS today... sung to yes we have no bannanas ;-) Ah, the joys of living under an IT department. I hear tales from my son all the time. He works in development and has to defeat a lot of IT stuff that keeps finding its way onto his machine every time he docks it at work. (Better him than me ;-) My xterm and bash windows come up just fine (don't crash like yours), but they don't have any content. No prompt, no cursor, nothing but black. With mozilla I could log into http://www.linuxbase.org/spec/ just fine, but I couldn't download anything. The dialog box for choosing an alternate file name and saving it, comes up just fine, but when you click on OK, it reports Connection refused ... After bumping into never before seen problems with an installation attempt (I have other issues I'd like to resolve as well as this one) I did the more obvious thing, and reverted to my previous 2.2.17 kernel. Everything works peachy keen fine! David, from your comments below, you seem to be using kpkg, while I use make. I got my 2.2.19 source from ftp.kernel.org, and, after a bit of unusual bother untarring it, did 'make mrproper ; make menuconfig'. At this point I had to go get ncurses4-dev ... somehow it failed to upgrade last time... Anyway, I usually work through every option in the config menu. I like the menuconfig option because it is easy to go back and forth between various areas of configuration. I make as much as I can with modules (keeping only enough to boot with as built in), and these days almost always have to go back at least once to trim some fat out so I can get a zImage. (this appears to be just a perverse bit of stubbornness on my part ;-) So it looks like I need to go back and look at some of that fat I trimmed and see what happens with a less anorexic kernel. I was just hoping that someone would see the symptoms, and say Oh, those things depend upon bla-bla-bla so that's where the problem is. But I guess I'll just have to put in the time... David, see additional comments below: On Thu, 26 Apr 2001, David A. Greene wrote: Dale Scheetz wrote: Now, when I bring up and xterm or a bash window, I get no cursor and no keystrokes appear in the window. I'm also having very flaky problems with I have had problems with this as well. I tracked it down to NFS/amd not working properly. This has been a problem on my laptop for about a year now but NFS is not so critical that I've had time to go fix the problem. It seems odd, though, that maps provided by our IT department don't work on my woody laptop, but work on other machines on the network (running potato). I'm guessing this is a configuration problem on my end, though. In any event, disabling amd solved it for me. I don't use NFS myself, but from what others have said it is not the most robust system because of various issues. YMMV Hmm...After re-reading your message, I think I misunderstood you. My problem is that the terminal session hangs (nothing is displayed at all, and no, there are no references to NFS mounts in my startup files). It sounds like you're having strictly input problems. Well, we may actually have the same problem for different reasons. It sounds like your symptoms match mine, although I'm not sure I'd use the word hangs, as I can close the window. There is just nothing in the window, and not action at the keyboard changes that... Switching kernels fixes it for me, so this isn't an X config issue. mozilla not being able to get into simple web pages and download material. (I'm trying to get the current LSB spec) Now _this_ I just recently (i.e. today) started seeing more often. My laptop (Dell Latitude CPx/J) has always had problems with the Vortex card after a BIOS resume. For one thing, the routes take forever to come back (i.e. 'route' hangs for a minute or more before being able to resolve to DNS). Today, however, I saw something new. I dist-upgraded testing and rebooted with a freshly-compiled 2.2.17 (no configuration changes, just a kpkg --revision change so it doesn't conflict with the standard packages). After a BIOS suspend/resume cycle, the network was extremely flaky. As usual, route took forever. Once I was able to ping a host, I left it running and used mozilla to access the network through both the WWW and IMAP clients. In both cases, as soon as mozilla took any action, the network was lost and the pings stopped going through. It sounds like you have a combination of complex local net that you must get out of, and possibly some flakey hardware. You also may not have power management properly configured in your kernel. Strangely enough, I just now resumed the machine again and everything seems fine. In general, the Vortex/Cardbus/SOMETHING has always been very flaky for me, but today was the first time I could _consistently_ bring the network down. Until I suspended/resumed again, of course. :( Sounds more and more like
I screwed up a bug closing
I recently uploaded a new version of libgmp3 that finally fixed bug number 93661, but I got a typo in the changelog resulting in an attempt to close bug number 93361 instead, which appears to have succeeded, closing this bug against the gltron. Can I just reopen that report, or is it going to be more complicated than that? (boy, I just don't seem to be able to do anything right the first time, lately...) Sorry for causing trouble, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Adam Heath wrote: On Wed, 25 Apr 2001, Dale Scheetz wrote: On Wed, 25 Apr 2001, Wichert Akkerman wrote: Previously Dale Scheetz wrote: Then you break things for no good reason. These module builders you speak of should be using the same headers as glibc. Absolutely definitely not. Userland is different from kernelspace, and headers need not match at all. Feel free to search debian-devel or linux-kernel archives where that has been discussed way too often already. Kernel modules exist in kernelspace, not userland. Building them against any other headers than those used by glibc does nothing to improve the stability or usefulness of Debian. Ah, self-contradictory statement. A kernel-module must be built with the EXACT SAME environment as the kernel being run. This means they need an EXACT match of headers. The ones that are included with glibc are generic, and will NEVER match the running kernel(even across kernel versions, let alone flavors). Dale, get a clue about kernel module building. You are completely wrong on this. You're right, I'm an idiot. I have no idea what I was thinking... I also don't know why I got diverted from the issue of bloat. The idea of flavours seems to go beyond the version connectedness required by kernel drivers. We have always delivered a kernel-header package for each version of the kernel that we deliver. What is there about the modules problem that suggests there should be even more flavours? The difference in architectures is a simple symlink to the proper asm routines. What else needs to be tailored that can't be handled in postinst. The last thing we need in this distribution is more packages... Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
New X problems...
I finally get my X system back into working order, find out I have memory problems with my kernel and upgraded to the 2.2.19. Now, when I bring up and xterm or a bash window, I get no cursor and no keystrokes appear in the window. I'm also having very flaky problems with mozilla not being able to get into simple web pages and download material. (I'm trying to get the current LSB spec) At this point I can't tell whether this has something to do with my new kernel, or is caused by something else. I'm pretty sure that once I got things working the last time, I used an xterm with no problems, so my suspicions lie heavily with the new kernel. Anyone have any ideas? Thanks, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Packages not making it into testing
+ atari800 uploaded 125 days ago, out of date by 115 days! depends on svgalibg1 on m68k; svgalib isn't supported on anything but i386 (aiui) I've been working on the newest upstream source for this package for several weeks (actual working time is much smaller ;-) and will have something finished in the next several. I'm not sure what the solution is for m68k... Anyway, there isn't much good can be done with an NMU, so folks should just be patient. Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: There two discussions here: 1. The number of kernel flavours. 2. The need for kernel-headers for each flavour. I was talking about 2. The whole purpose of kernel-headers is to provide one, most stable, kernel interface for the distro to build against. The idea was that, by choosing the kernel to compile against you have the best chance of things working correctly on other kernels. Creating a kernel-header for each flavour completely ignores and defeates the reason that kernel-headers exist! As to point 1, the only reason I can see to have different kernels is to have one for installation (which can boot from various devices) and possibly another more moduled build for a running system, but I have to agree with the opposition when I say that delivering a couple of different image files is far less impact than a large number of source packages. Why not just one source package that does something like make mrproper during the postinstall so that the headers are set up correctly for the particular architecture it is installed upon. This satisfies both header and source needs. Herbert, you need to stop behaving like your namesake from Star Trek, and begin to listen to the overwhelming position of your fellow developers. Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: On Wed, Apr 25, 2001 at 08:18:00AM -0400, Dale Scheetz wrote: The whole purpose of kernel-headers is to provide one, most stable, kernel interface for the distro to build against. The idea was that, by choosing the kernel to compile against you have the best chance of things working correctly on other kernels. That is the raison d'etre for kernel-headers. However, the new per-image kernel-headers exist solely for the benefit of module builders. Then you break things for no good reason. These module builders you speak of should be using the same headers as glibc. Creating a kernel-header for each flavour completely ignores and defeates the reason that kernel-headers exist! Huh? There is still a kernel-headers package for the glibc maintainer to use. In fact, it's exactly the same as before. And when some other library gets built with one of your other headers? This is the sole reason for the existance of kernel-headers. Your continued insistance that doing something else is good for someone else ignores these reasons and is fundamentally a broken concept. Strut all you want, but your just plain wrong. Waiting is, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Herbert Xu wrote: On Wed, Apr 25, 2001 at 08:54:33AM -0400, Dale Scheetz wrote: On Wed, 25 Apr 2001, Herbert Xu wrote: That is the raison d'etre for kernel-headers. However, the new per-image kernel-headers exist solely for the benefit of module builders. Then you break things for no good reason. These module builders you speak of should be using the same headers as glibc. Hmm, I think you better refresh your theory about kernel modules. Right back at you... Huh? There is still a kernel-headers package for the glibc maintainer to use. In fact, it's exactly the same as before. And when some other library gets built with one of your other headers? Which other library uses kernel headers? They better stop or they probably won't compile at all with 2.4. This doesn't reduce the damage hole you are creating. This is the sole reason for the existance of kernel-headers. Your continued insistance that doing something else is good for someone else ignores these reasons and is fundamentally a broken concept. Dale, I expected you to have a better understanding of this since you used to maintain glibc. It is true that the plain kernel-headers exist solely/mainly for the purpose of building glibc. However, it has nothing to do with the new flavoured kernel-headers. These should/will not be used to build glibc. They exist so that kernel modules with correct checksums can be easily built. Well, first of all, my contribution to glibc development was that of the little boy with his finger in the dyke trying to stem the oncoming tide. I held the package after David dropped it, until Joel took it over. None of this is relevant to the current discussion. Please explain to me just how multiple header packages makes additional module creation more safe/useful/correct. Most of the third party module vendors (like VMware for instance) generate their needed modules at installation time, against the kernel source on the target machine. If all of this effort and bother is to make third party, binary only, module provider's lives better, I don't see how this accomplishes that. You give more than one choice and my karma provides the most wrong one in the group. You continue to demand good reasons not to do what you want, and ignoring all reasons provided. My question is: Just how does this bloat improve the packages in main? That is our goal, and supporting the needs of proprietary vendors in this fashion doesn't help those users who need non-free software. Until you can answer my question reasonably, I will continue to be opposed to your proposal. Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: kernel-{image,headers} package bloat
On Wed, 25 Apr 2001, Wichert Akkerman wrote: Previously Dale Scheetz wrote: Then you break things for no good reason. These module builders you speak of should be using the same headers as glibc. Absolutely definitely not. Userland is different from kernelspace, and headers need not match at all. Feel free to search debian-devel or linux-kernel archives where that has been discussed way too often already. Kernel modules exist in kernelspace, not userland. Building them against any other headers than those used by glibc does nothing to improve the stability or usefulness of Debian. We don't try to control the version or configuration of the kernel on working Debian systems. We only control the kernel provided for installation. Trying to provide the special kernel feature needed by some perculiar third party module, by providing a wide variety of flavours in kernel-headers, is a philosophically broken point of view at the very lease, and technically redundant to boot. These statements are obviously based on my personal point of view, and I've always been opposed to the kernel source in .deb format, but if we're going to do it that way, then use the package manager tools to configure this source on the target machine, providing proper compilation headers for the installation architecture. Personally I have no use for even the .dsc, .diff, and .tar.gz source, but acquire all my kernel source from the source. Which reminds me, thanks for the pointer to the new 2.2.19 kernel, seems to have fixed all my problems. It even recognizes all 128 meg of memory without need of the mem= argument to LILO! (which is just as well because I couldn't seem to get the syntax right anyway ;-) I just barely got this one to squeeze into a zImage, so it doesn't seem to matter that I'm strongly opposed to bloat. It happens anyway... Personally, I can't imagine why Herbert wants to put more packages on his management plate in the first place, much less why he thinks its good for the rest of us. I'm doing my best to get rid of the useless, dangling packages in my hands! Luck, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Strange problems...
I have a resonably new motherboard with 128 meg of memory. My swap space is 100 meg. I just got a slew of messages at the console like: VM: do_try_to_free_pages failed for WindowMaker... VM: do_try_to_free_pages failed for WindowMaker... VM: do_try_to_free_pages failed for WindowMaker... VM: do_try_to_free_pages failed for acroread... VM: do_try_to_free_pages failed for acroread... and even gpm complained when I tried to highlight the above text. Anyone have any ideas? A Noid, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Re: Strange problems...
On Tue, 24 Apr 2001, Wichert Akkerman wrote: Previously Dale Scheetz wrote: Anyone have any ideas? 1. figure out what uses insane amount of memory and apply kill and/or rm So, this is a common response from a system that has exhaused both swap and real memory? Any good candidates in a standard system? I don't do anything now that I haven't done for years, so it's probably one of those new features of Debian, right? ;-) I couldn't get top to run while the event was occuring, and afterwards everything looked ok ... hmmm, I do seem to have a problem here. Mem: reports 64K with about 62K in use. So how come the whole 128 meg is not being recognized? (it shows up on the memory test at boot) 2. buy more memory Gag me with a spoon! For the last 5 years I've lived with a 32 meg machine and never had problems. In recent years, however, I've noticed that it gets harder and harder to shoehorn a zImage kernel into the required size. Things get much worse and I just might have to become interested in something more like BSD ;-) I upgraded my machine to this, for me, gigantic size because VMware will not run without at least 100 meg. (Hmmm, it's shut down, but it still has all kinds of drivers installed %#^@) This is the most recent addition to my toolset, but it has been shut down for days, and was not running durring the event (unless there is more magic here than I thought ;-) 3. upgrade to a 2.2.19 kernel I should probably do that anyway... Is there something specific that was fixed between .17 and .19 that would bear on my problem? Thanks, Dwarf -- _-_-_-_-_- Author of Dwarf's Guide to Debian GNU/Linux _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/
Obsolete software in /usr/local
I run several ancient programs, by housing them in /usr/local/bin, with the libraries they need (which are no longer provided in Debian) situated in /usr/local/lib. In previous systems, right up to potato, this worked fine. I just finished building a woody system, so I can get my packages up to date, and all these programs stopped working because the needed library was not found. If I copy the /usr/local/lib contents to /lib everything works fine, suggesting that ldconfig no longer traverses /usr/local/lib for the libraries found there. Is this what is going on ... why ... and what do I do to correct the problem? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Obsolete software in /usr/local
On Fri, 5 Jan 2001, Ben Armstrong wrote: On Fri, Jan 05, 2001 at 01:31:42PM -0400, Ben Armstrong wrote: Changes in version 1.9.2: Removed /usr/local/lib from the default /etc/ld.so.conf for Debian (Bug#8181). oops, except that mod is *ancient*. way before potato. dunno why this would change between potato and woody. Well, my current potato partition (which runs fine against the /usr/local partition) is a release by release upgrade from Bo thru Potato. I probably got the chance to say Don't change my config file! somewhere during the upgrade. My current woody partition, was constructed from scratch from Potato CDs and then dist-upgraded using apt-get from the woody archives. If this changed pre-potato then this explanation makes sense, as it is the woody partition that will not run that same /usr/local partition. Thanks for all the help from everyone. I'm still fulfilling holiday responsibilities and will be out of touch until Sunday morning. After that I get to work on my packages some ;-) Thanks again guys! 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Alternatives to ftp.debian.org
With all that is going on with ftp.debian.org, I just tried to check there for alternative mirror sites and it's gone bye-bye. So, I checked the web page, but the only primary site listed is ftp.debian.org. The secondary sites are said to have restrictions, but just what those are for any given server aren't clear. I've reset sources.list on my sparc to point to http://us.debian.org, on the assumption that I can probably use that site effectively. Is there any better way to pick a useful ftp site for upgrading? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Need a gateway guru
I'm looking for someone to help me add a section to my newest Debian book (which will be released under the GFDL BTW) that covers gateway configuration. My primary problem is that I know next to nothing about how this is accomplished, which makes it pretty hard to write about it ;-) Some of the steps are obvious, but I'm not at all clear on how to accomplish the routing correctly, nor any of the other details. I have a LAN and a machine to make the PPP connection, so I have an adequate test bench. (one of the machines on the LAN is Win98, so I even have some diversity ;-) The only payment I can make is your name on the credits page, and my many thanks. If that is sufficient, please let me know so we can get started. I'm trying to finish writing by next week, so time is short... 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Strange messages...
Since my last upgrade to potato I've been getting a lot of messages like the following: DEBUG: --Relation pg_rules-- DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec. DEBUG: --Relation pg_views-- DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec. DEBUG: --Relation pg_tables-- DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec. DEBUG: --Relation pg_indexes-- DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec. There doesn't seem to be any real information here. Can anyone tell me what is triggering these messages? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Strange messages...
On Wed, 30 Aug 2000, Jules Bean wrote: Well, they're from Postgres, I can tell you that much. OK... Probably you have one of the debug trace options on in your postgres config files (in /etc/postgresql). I have? ;-) I looked in /etc/postgresql and found several files, none of which set any debug options. pg_hba.conf Mostly comments except for a two line declaration that local host is trusted. pg_ident.conf Completely comments postgresql.env Incorporates postmaster.init into script and then assigns and exports several paths, two of which do not exist on my machine. postmaster.init Asside from a small block of code that determines POSTGRES_HOME and a line setting PGDATESTYLE to ISO, this file is all comments as well. So it looks like this is somehow hard coded in the binary? I guess I could just remove the package ... I installed it for educational purposes, and then never got to class ;-) 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Strange messages...
On Wed, 30 Aug 2000, Ashley Clark wrote: They are courtesy of PostgreSQL, the behaviour of the config file has changed between two of the versions. You can add PGDEBUG=0 to your /etc/postgresql/postmaster.init file and they will disappear. Cool! 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Ian Jackson, please get me the hell off your blacklist.
On Sat, 1 Apr 2000, Craig Sanders wrote: On Fri, Mar 31, 2000 at 11:08:53PM -0500, Branden Robinson wrote: On Fri, Mar 31, 2000 at 11:18:47PM +1000, Craig Sanders wrote: your right to free speech does not include the right to force anyone else to listen. Then this principle must apply universally. I reserve the right to ignore bug reports for any reason I choose, then. of course you have that right. any volunteer always has the right to abandon the responsibilities that they have freely chosen to accept. I believe the discussion is about speech, not volunteer responsibilities. Speech implies a listener, otherwise we would never have discussions about trees falling in the forest unobserved. Speech without a listener is failed communication. That is exactly what we are seeing here. No single party to the conversation can fix the problem. Both parties must participate in the communication of ideas or there can be no exchange. Both parties getting to have their say, and everything continuing as before, is not communication. Freedom is a wonderful concept, until it is used to bludgeon someone else into doing things your way, against their own better judgement. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Danger, Branden Robinson! Danger!
On Thu, 16 Mar 2000, Paul Slootman wrote: On Mon 13 Mar 2000, Stephen Zander wrote: Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Only 6000? We must be getting lazy. 6000 is way too Joseph easy. Better try for 8000. Now one ever thought the Dow would break 10k: took 'em 10yrs to get from 3k to there. I'm sure we can do it in 2yrs (which is about when woody will be out, right? :)) I still think we should be honest and report the number of source packages, not binary packages; e.g. I find the following all parts of We can report both... Overrides covers the binary packages and Sorces covers the source packages, right? just one package: glibc-doc i18ndata libc6 libc6-dev locales It _is_ useful to be able to install these separate parts, of course... I've been working on a selective source building script, so I know just what you mean. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Call for sponsors/mentors
The new maintainer team has been working very hard to resolve a working application procedure. At this point, although we still don't have all the details of the identification process completely resolved, it has become necessary to start working applicants through the process, in order to work out the fine details and find any kinks. In order to do this in a semi-controlled fashion, we are inviting all sponsors/mentors to submit their candidates to the application process. If you are currently sponsoring a prospective maintainer, please contact Dale Scheetz [EMAIL PROTECTED] for Application Manager assignment. While we are looking to bench test the complete process, the major area of interest is the identification process. We currently agree that any official picture ID (passport, driver's license, etc), digitized and signed with the applicants key is adequate identification if the key has been signed by a current Debian member. It is the other circumstances that are less certain. If your applicant can provide such identification, they will move through the application process more quickly, however our interest is going to be in the applicants who can not provide these items. We want all applicants, no matter what their ID documentation, as this will give us some idea of just how complex this problem will be in actual practice. So, when you contact Dwarf, include some indication of the type of ID documents your applicant can provide. If any of this documentation is available in digitized form, include that image as an attachment to the contact e-mail. This will speed up the process. Thank you for your attention to these matters. I am looking forward to hearing from all the sponsors and mentors out there, as we are all looking forward to a working new maintainer process. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
New Maintainer Status Report
Wichert requested that I make a report on the progress being made by the New Maintainer Team. So here is what we have been up to: Taketoshi Sano has been getting down to work on the web page for the New Maintainer Corner, and it sounds like he will be ready, whenever we get our materials completed. Oliver Elphick has offered to put together the DBMS back end to support the web pages data input and data display components. It sounds like the interface will be PHP. Darren Benham agreed to do something with an Applicant's FAQ, to cover the bases of what to do if the application process fails, and who to contact if your normal contact goes away. I expect this to grow to contain details that aren't available in any of our other documents. This will also be incorporated into the web pages. At this point we have an Applicant's Checklist, and are working on the detailed descriptions of each of the 12 steps outlined in that list. We are currently about half way through the list, but the last half is somewhat simpler than the first, so we should be able to complete the process description by the end of this week, assuming I can find the time to write up the details. As soon as we have a complete set of operating procedures set down, we will run a test case through the process to shake out any issues we missed in our debate. Once we have a proof of concept working, we will begin on the backlog of folks who have been waiting patiently, working with a sponsor, in preparation for the reopening. As soon as all the particulars are available on the web pages, we will be ready to accept new applications. It is our hope that this will all come together within the next one to two weeks, but this depends as much on luck as on the efforts we are making to come to closure. If you can't wait for the web pages to be opened, in order to find out what kind of process we have constructed, feel free to subscribe to nm-discuss by sending a message to: [EMAIL PROTECTED] with subscribe in the subject line, or you can go to the web page at: http://cipsa.physik.uni-freiburg.de/mailman/listinfo/nm-discuss where you can subscribe, or just look over the mailing list archives to see what has been going on. All the traffic on nm-admin is cc'd to this list, so you get all the work postings plus all the comments made outside the group of Application Managers. Wish us luck, as I hope to make a Grand Re-opening announcement as my next report. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
NEW New Maintainer mailing lists
Thanks to Lars Steinke [EMAIL PROTECTED], the new maintainer team's Application Managers now have a mailing list, and can begin the work that they volunteered for. While this mailing list is private, and only the Application Managers may post there, all posting to this private list will be CC'd to the public list: [EMAIL PROTECTED] To subscribe to this list send a subscribe message to: [EMAIL PROTECTED] The Applications Managers will monitor this public list and will, from time to time, incorporate the useful ideas proposed there. So, if you only want to see how things are going, or actually have some ideas to contribute, feel free to subscribe to nm-discuss. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: couple of nits/warnings
On Tue, 5 Oct 1999, Bdale Garbee wrote: In article [EMAIL PROTECTED] you wrote: tar -zxf control.tar.gz control ./control You can also use tar -zxf control.tar.gz *control which does not produce an error, and extracts either one. This is the fix I supplied for lintian when the tar upstream changed the way pathname whacking happens in tar... which our tools depended on. Given that we know what's in a control.tar.gz, the wildcard is not problematic. slaps palm to forehead and mutters I should have guessed Yep, in this special case that is equivalent. Thanks! I'm very happy to get rid of two error messages per package ;-) 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
permission denied on owned files
Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: --begin paste- $ user build $ pwd /Debian/build $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 -rw-rw-r-- 1 buildbuild 59 Oct 5 15:53 build.list -rw-rw-r-- 1 buildbuild1153 Oct 6 09:47 buildpkgs.log drw-rw-r-- 2 buildbuild1024 Sep 19 12:06 lists drw-rw-r-- 2 buildbuild1024 Oct 5 16:04 logs -rw-rw-r-- 1 buildbuild 131 Sep 20 06:54 oldbuild.list -rw-rw-r-- 1 buildbuild 63 Oct 1 11:12 prebuild.list -rw-rw-r-- 1 buildbuild 193 Oct 2 18:09 prebuild1.list drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild $ cd logs sh: cd: logs: Permission denied $ ls -l ../ total 4 drwxrwxr-x 7 buildbuild1024 Oct 5 15:56 build drwxr-xr-x 2 root root 1024 Sep 19 10:52 dists drwxr-xr-x 2 root root 1024 Sep 16 06:50 lost+found drwxr-xr-x 5 root root 1024 Oct 4 20:03 pkgwork $ --end paste--- Since I couldn't get into them as the build user, I took a look as su and found: $ su Password: dwarf:/Debian/build# ls -l sbuild total 2699 -rw-rw-r-- 1 buildbuild 442398 Oct 6 09:47 tk8.2_8.2.0-3.diff.gz -rw-rw-r-- 1 buildbuild 623 Oct 6 09:47 tk8.2_8.2.0-3.dsc -rw-rw-r-- 1 buildbuild 2305473 Oct 6 09:47 tk8.2_8.2.0.orig.tar.gz So, where do I look to figure out why I am not allowed access to these files/directories? TIA, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: permission denied on owned files
On 6 Oct 1999, Ruud de Rooij wrote: Dale Scheetz [EMAIL PROTECTED] writes: Something else strange just happened during an autobuild pass. All of the subdirectories in my build tree have suddenly become inaccessable to the build user, who owns all the files and directories. Here is what I get: $ cd sbuild sh: cd: sbuild: Permission denied $ ls -l total 9 drw-rw-r-- 2 buildbuild1024 Oct 6 09:47 sbuild So, where do I look to figure out why I am not allowed access to these files/directories? In order to access a directory you must have execute permission (the x-bit) on it. Thanks, I don't know why I didn't see that...(i.e. I knew that! ;-) Now the only thing I don't understand is how it got that way in the first place. This is the directory where the script unpacks and builds the source files. It has been working just fine up until I tried to build tk8.2 and dpkg-source failed to unpack the source. After that point, the script returned permission denied when it tried to create a log file in the parent directory. It seems that all of the directories owned by build are now without execute permissions. I'm using dpkg 1.4.1.9, and David Engle (the tk maintainer) suggestes that the several versions of dpkg that he has tried unpack the source just fine. Somehow, when dpkg-source fails, the directories have their execute permissions removed? Actually the effects are broader than that. All of the files in the working directory have their execute permission bits set true, so it looks like the operation simply toggled all execute permission bits that it had access to. At least this isn't as bad as the last time I had such a failure (much data was eaten by Zule on that night, I can tell you ;-) Thanks for the feedback. It looks like I need to find a better version of dpkg. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
couple of nits/warnings
As you may know, I have been working on a script to build selected subsets of the distribution from source, to be used for constructing single CD releases of ED (Essential Debian). With the correction of my faulty grep|awk filter I have been able to build more complex lists of packages (and can even build gcc on a slink system) when I started seeing a previously unseen failure in my script. The line that extracts the control file from the archives with a tar command was failing, telling me that control was not in the archives. A bit of exprimentation showed that the tar in slink can only find control while the tar in potato can only find ./control. (this from the same tarball both times) I resolved the problem with the following line: tar -zxf control.tar.gz control ./control which gives an error every time, but extracts the control file every time as well...such is life ;-) The man page (I believe in both cases, but I could be wrong) says that the file name must be given exactly as displayed by the list option. This would suggest that both versions should accept ./control, as that is what is printed to the screen when tar lists the contents. So this is a bug fix in the new release...(I can't really tell from the changelog without looking up a fair list of bug reports...sorry, I'm lazy ;-) After all that complex lead-in, my question is quite simple. Since ./control and control are semanticly identical, why is a distinction being made? I understand that in every other example of this rule there is reason to apply it, to distinguish between files with the same base name but different paths, but that is not the case here. The second nit has to do with the way that dpkg assigns permissions to the package files it creates. I'm not certain why, but I sort of expected the files to be 664, not the 644 that it produces. If group projects are to be managable, shouldn't members of the group have write permission on these files? Is this an artifact of the way we do users and groups (giving the user his own personal group with the same ID)? This brings up another point relating to inter system compatibility. I did some very minor beta testing for Caldera (please don't throw tomatoes ;-) and, as a result, they were very generous in gifting me with a boxed copy of their new release. I have a laptop with a finiky graphics card, and Caldera was able to make it work in a reasonably high graphics mode, (something that I haven't been able to get the slink xfree to do at the same resolution) so I installed it on my second system partition, and immediately ran into problems with the way I wished to configure my systems (nothing particularly new here ;-) On machines (like my development box) where I wish to run two or more version of the distribution, I have several partitions for the root system, and several partitions for particular (non-unique) components of the file system. One of these is my home directories. home has its own partition that gets mounted on /home by each of the various systems I may be running. (this has been a bit tricky, having to propogate the passwd files onto new systems from old, but it works pretty well) So far I have been able to make this work because they have all been Debian systems. When I added /home to fstab on the Caldera system, I naturaly lost all access to the system. dwarf on the Debian system has the uid:gid of 1000:1000, while on the Caldera system dwarf has 500:100. It felt safe to change the user number on the Caldera system to 1000, but I didn't want to change the group ID (corresponds to the group users) for fear of breaking something on the Caldera system. This allowed me to login (which I hadn't been able to do before) but I still could not access my files. While I later realized that I could probably just add dwarf to the dwarf group (ID 1000) on the Caldera system and it would probably work, I decided to separate the two systems /usr partitions, putting the Caldera /usr on the same root as the system, and leaving the Debian configuration the way it is. Is there a better way to integrate these two systems than the one I worked out? Sorry this went so long, I thought I only had two points to make ;-) 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Need a developer contact in Colorado Springs area
My son just moved to Colorado Springs (booo! not that there is anything wrong with Colorado Springs except the distance ;-( and while, over the past several years, I have had no luck in getting him interested in Linux, since he has moved, he has expressed an interest in learning to build programs in a Linux environment. (go figure ;-) He is primarily interested in building a point of sale system, and sees the unnecessary limitations he faces in the M$ environment as finally being a problem. I suspect, being in a new town, he could use someone of similar programming interests to brainstorm with as well. He is proficient in both C and C++, so he probably just needs to be pointed to where things are in a Debian system, and he will be off and running. If there is anyone in the area who would be interested in making this contact, please contact me in private e-mail and I'll provide the necessary information. In addition, I would ask that whoever takes on this task please try to convince him to port his mill game to Linux, so I can package it for the distribution. Thanks for your time, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: couple of nits/warnings
On Tue, 5 Oct 1999, Dale Scheetz wrote: The second nit has to do with the way that dpkg assigns permissions to the package files it creates. I'm not certain why, but I sort of expected the files to be 664, not the 644 that it produces. If group projects are to be managable, shouldn't members of the group have write permission on these files? Is this an artifact of the way we do users and groups (giving the user his own personal group with the same ID)? I just figured out what this is all about. It turns out that the directory I was buiding them in had no group write premission, hense dpkg rightfully left it off. Once I changed the directory to have write permission for groups everything is as expected. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Is this a bug in grep, or is it me...
I am trying to grep the override file for the section for debhelper. I am using the whole word option (-w), but this is what I get: $ grep -w debhelper override.potato debhelper optionaldevel hello-debhelper optionaldevel In the man page, under the -w option, it says that, in order to match, the string must be either at the beginning of the line, or preceeded by a non-word contituent character, which it declares as letters, digits, and the underscore. The hyphon at the ned of hello in hello-debhelper isn't any of these, but grep declares it to match anyway! Is this something to do with the form of my expression? Any information will be greatfully appreciated, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Is this a bug in grep, or is it me...
On 1 Oct 1999, Ben Pfaff wrote:
Dale Scheetz [EMAIL PROTECTED] writes:
$ grep -w debhelper override.potato
debhelper optionaldevel
hello-debhelper optionaldevel
In the man page, under the -w option, it says that, in order to match, the
string must be either at the beginning of the line, or preceeded by a
non-word contituent character, which it declares as letters, digits, and
the underscore.
No, it says that those are word constituent characters.
That's what I meant...
The hyphon at the ned of hello in hello-debhelper isn't any of these,
but grep declares it to match anyway! Is this something to do with the
form of my expression?
It's preceded by a character that isn't a letter, digit or underscore:
a hyphen.
Which confused me as to why it was being included in the word.
So a search string is defined as any characters delimited by blank, tab,
or newline, but because the hyphon is not considered a word constituent
character, debhelper is considered a whole word within the string
hello-debhelper?
While this seems to be working with two definitions of what is a word (the
parser considers hello-debhelper as one word while the expression
analysis considers it two words), I can accept that this is the true state
of affairs.
This leaves me with the unresolved problem of distinguishing between the
two package names.
I just read through the grep manpage (again) looking for something that
will enforce an exact match, when I realised that I can simply skip this
step and do the selection in awk (which I was using before to peel off the
section name from the grep output), so the right command is:
awk -v name=debhelper ' name == $1 { print $3 } ' override.potato
which produced the single line:
devel
rather than:
grep -w debhelper override.potato |awk '{ print $3 }'
which produced the two line ouput:
devel
devel
Thanks for the education, problem-set can be a real killer.
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
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Hosed potato/main/Packages...
On 30 Sep 1999, Michael Alan Dorman wrote: Philippe Troin [EMAIL PROTECTED] writes: Yeah, just uploaded some new packages which fix the typo. I just hand-edited my available file. :-) Maybe it should be trapped by dinstall I tend to agree. I wonder how that can be done using the tools themselves, so we don't end up with implementations that differ. If the installing programs go belly up because of typos in individual packages, it is the responsibility of the build program to validate those critical fields. Validating the control file (like the changelog is validated during the source build) before the build is the right place to do this. On the other hand, it could be argured that dselect and apt should not fail so miserably over a single package with a minor flaw. (There should be some fairly simple recoverey logic for these error cases...like mark the package a broken and go on with those parts of the install that don't depend on that particular package) In slink, if you include dhttp in the install, without first installing the packages that dhttp pre-depends upon, dselect will roll over and play dead before it tries to install any packages. It should probably just mark dhttp as a failed attempt, and go on with the rest of the packages. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: mtools
On Tue, 28 Sep 1999, David Weinehall wrote: On Tue, 28 Sep 1999, Dale Scheetz wrote: [snip] Guys, guys, guys... This is a discussion that was had quite a while ago, and which lead to the creation of xlib6. The whole point was that it was unnecessary glut to include a console version _and_ an X aware version of packages like emacs (and others), when a small library could provide all that was necessary to make a single program both console and X compatible. xfree86-common is simply a recent way to remove the architectural independent pieces from xlib6 and provide them in an independent fashion. This is ok with me for stuff like emacs (eventhough I'd really become aggressive if someone removed the vim-tty package.), but when it comes to mtools, it's only one single file; a daemon (floppyd, if I'm not all wrong) that needs xlib6g. It'd be simple to extract this daemon from mtools and create an extra package with just this file, and make this file recommended by mtools, and make mtools required by the extra-package. So now you have two packages one without an xlib6 dependency, that requires an extra-package with _does_ depend on xlib6. Pushing the dependency away by one package, doesn't make it disappear. The point is, that when you install mtools, it is only taking advantage of a Debian space saving feature when it links to xlib6. The depends is there, on the very odd chance that you have not yet had to install this miniscule library for other packages that use it as well. If you have installed a standard system, you already have it. If you are trying to create a trimmed down system, you will most likely need it anyway, unless you trim X completely out of your system. Debian isn't designed only to meet those limited circumstances. It was decided that this small penalty in space for the minimal library generates more flexibility with less cost than what you suggest (i.e. creating x and non-x packages to meet the X users requirements). Even in the trimmed down system the penalty is small. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: mtools
On Tue, 28 Sep 1999, Brian Servis wrote: *- On 28 Sep, Josip Rodin wrote about Re: mtools On Tue, Sep 28, 1999 at 07:13:58AM -0700, Joseph Carter wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. Better to fork off another package, which would include X support, and leave the original package X-free. What about the [x]emacs packages. I would hate to see forks of all those things on the mirrors. Maybe a Suggests or Recommends would be better than a Depends. Guys, guys, guys... This is a discussion that was had quite a while ago, and which lead to the creation of xlib6. The whole point was that it was unnecessary glut to include a console version _and_ an X aware version of packages like emacs (and others), when a small library could provide all that was necessary to make a single program both console and X compatible. xfree86-common is simply a recent way to remove the architectural independent pieces from xlib6 and provide them in an independent fashion. You cannot simply reduce the dependency to a lower level, like Recommends, or Suggests, as the program, linked against xlib6 will have unsatisfied references, if the library is not installed. While it may seem a bit insensitive to force these two packages on everyone. It seems a better situation than requiring you to load two complete versions of emacs just to get console _and_ X aware editors. The fact that this impacts every application that would be useful in an X environment, makes insisting that everyone install xlib6 a very good thing. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: problems with the perl5 packages
On 23 Sep 1999, Michael Alan Dorman wrote: Dale Scheetz [EMAIL PROTECTED] writes: This brings up another issue. Both perl-5.004 and perl-5.005 provide perl5, but it was my understanding that these two versions were substantially different, at least during installation I got a long story about how I would need to convert databases to the new perl version. That difference relates _exclusively_ to the change from using berkeley db 1.85 to db 2.X, and the differences between those two version are indeed substantial. Of course, this change could affect any piece of software---sendmail, for intance, could have run into this same problem, or postfix, or any number of other packages that use berkeley db. This is not, I repeat, NOT a perl issue, per se. It was my understanding that this was, in fact, the reason for constructing the package names so that they could both be installed at the same time, yet they both claim to be perl5! You know, Dale, I find your attitude towards, and comments about, perl quite annoying. Your understanding is deeply flawed, you apparently haven't bothered to expend any actual effort to understand the state of the language, yet you spent a week last month spewing FUD about perl's instability as a language, and now you produce this petulant complaint because reality doesn't confirm to your uninformed ideas of the state of things. You know, Michael, I find your attitude towards me a bit annoying as well. The fact that you did not understand the point I was trying to make in my previous posting about perl and package managment is not too surprising. Almost no one got my point, which was nothing to do with whether perl is a good thing or not, but whether it was a proper tool for package integration. I still think that an extensible language is _not_ a good candidate for building integration tools, but that has nothing to do with the current questions I have been asking. Those points have/had nothing to do with my current questions, so why am I a clueless idiot, and folks like Branden are just developers asking questions? This last thread of mine has zero perl bashing content as far as I can tell. Not one to holde a grudge, though, I will attempt to spell it out for you as clearly as I know how. For more complete information, might I commend you to the archives of the debian-perl mailing list, as well as, perhaps, the perl documentation itself. To begin from the beginning: Perl is an extensible language. There are two kinds of extensions to perl, those written exclusively in perl code, and ones that also include dynamically loaded C code (usually called XS code for various reasons). Source code compatability for pure perl extensions has been excellent throughout the development cycle of perl 5.X---in fact, going back to perl4 and earlier. For instance, the 'mirror' script that has been used all over the internet for the last several years was actually written for perl4, and, unless it's been changed in the last year, _still runs under perl4_. However, binary compatability is occasionally (reluctantly---and usually reversibly, at the time you compile perl) broken when needed---as was the case with perl 5.005's introductions of threads. So, we arrive at a situation where perl5.004 and 5.004 are binary incompatible for the purpose of loading modules containing XS code, but are perfectly compatible for the purpose of loading pure perl-coded modules. So pure perl-coded modules are quite logically set to depend on perl5, a virtual package that is provided by both interpreters, in order to provide maximum utility for those who, perhaps for reasons of berkeley db compatability, choose to continue running 5.004, while modules including XS code are made dependent upon the particular version of perl they were compiled against, in order to be sure to avoid any binary incompatabilities. Capice? Klar? Yes, and it even speaks to some of my confusion ;-) So, pure perl modules only need depend upon perl5, while other packages may need to specify a particular version of perl5. So, why are there packages with depends lines that include both perl5 and a particular version, like perl-5.005? Can I suppose that that package misunderstands its dependencies? Are there any circumstances where perl-5.004 is compatible with earlier version like perl-4? I ask this because of mirror, which seems to work ok with any of the perl version, even though the old version specifically depends upon perl, and the new version specifically depends upon perl5. I was mainly confused that none of the new versions provide perl. I can only assume that this is because perl-5.004 is not backward compatible with the previous version? Thanks for the clarification, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software
problems with the perl5 packages
Well, in recovering my system, it became necessary to install dpkg-dev, who's current version requires perl5. I chose to upgrade to perl-5.005, but while installing perl-5.005-base I was forced to use --auto-deconfigure on several packages that depended upon perl. When the smoke cleared, after installing the complete perl-5.005 package, I could not re-configure either libnet-perl, or mirror, both of which depend upon perl. After looking over things, both perl-5.004 and perl-5.005 replace perl and provide perl5, but neither of them provide perl! Shouldn't perl-5.005 provide perl? Or should mirror depend upon perl5? If both of these packages have the correct dependencies, where do I get a version of perl that provides perl, that will install beside perl-5.005? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: problems with the perl5 packages
On 23 Sep 1999, Michael Alan Dorman wrote: Dale Scheetz [EMAIL PROTECTED] writes: not re-configure either libnet-perl, or mirror, both of which depend upon perl. This is incorrect. Current versions of libnet-perl do not require perl. But the versions in slink _do_, and it is these packages that are still, legitimately, on my system when the perl upgrade happens. Nothing indicated that I should upgrade those packages. We seem to have mixed feelings about supporting incremental upgrades. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: problems with the perl5 packages
On Thu, 23 Sep 1999, Raphael Hertzog wrote: Le Thu, Sep 23, 1999 at 05:24:32PM +, Dale Scheetz écrivait: After looking over things, both perl-5.004 and perl-5.005 replace perl and provide perl5, but neither of them provide perl! This has been done so voluntary. And perl-5.005-base conflicts with perl ... you should upgrade your packages that depends on perl. At least on i386, no package does depend on perl (all packages depend either on perl5 or perl-5.005). This brings up another issue. Both perl-5.004 and perl-5.005 provide perl5, but it was my understanding that these two versions were substantially different, at least during installation I got a long story about how I would need to convert databases to the new perl version. It was my understanding that this was, in fact, the reason for constructing the package names so that they could both be installed at the same time, yet they both claim to be perl5! 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Which gcc builds potato?
OK, I have recovered to a slink system, and I'm ready to upgrade it to potato, which raises the above question. There are two gcc versions available in the archives. Which one is being used to build the system? Will either work? The libraries are pretty self explanitory, with the exception of ncurses, which I assume is to be version 4 from what is found in base? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Which gcc builds potato?
On Tue, 21 Sep 1999, Ben Collins wrote: On Tue, Sep 21, 1999 at 10:19:48AM +, Dale Scheetz wrote: OK, I have recovered to a slink system, and I'm ready to upgrade it to potato, which raises the above question. There are two gcc versions available in the archives. Which one is being used to build the system? Will either work? The libraries are pretty self explanitory, with the exception of ncurses, which I assume is to be version 4 from what is found in base? Waiting is, gcc272 is not to be used at all for building sparc packages, I wish it would just die right out of the distribution personally :) gcc_2.95.2-0pre1 is what is suggested (and required if you don't want to get bit in the ass by dumb compiler errors). Thanks, although the question was for Intel based builds, it is good to know about sparc requirements as well. So, what, if anything, is being built with egcs? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Which gcc builds potato?
On 21 Sep 1999, Ruud de Rooij wrote: Dale Scheetz [EMAIL PROTECTED] writes: So, what, if anything, is being built with egcs? Nothing, since egcs does not exist in the distribution anymore. Well, egcs 1.1.2-2 is still in my source archives, so someone must be using it. egcs64 is currently being used to build Ultra kernels, so I figured the 32 bit egcs was being used for some purpose as well. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
problems autobuilding perl-5.004
I've built a shell script that runs from a list, extracts source from the archives, builds the source, and installs the binary packages into a target CD archives. I have been able to build several packages with this script, but when I got to perl-5.004 the build dies in the configure stage with the following error message: Say 'sh Configure' not 'sh Configure' make: *** [config.stamp] Error 1 However, dpkg-buildpackage fails to return the error and the script continues along its merry way, failing to find packages to install, etc... If I cd to the proper directory, and execute dpkg-buildpackage from the bash prompt, everything builds ok. If I execute the same command line in my shell script, I get the above error message. I have tried various shell environments with no change (bash, ash, and sh) to the results. Anyone have any idea what's going on? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Hosed system during package build
This is a first for me! As you may have noted from earlier postings, I have been working on a source build process for distribution construction. During the build of one of the source packages, the system went away. Upon rebooting the system, I got told that there was no console device, so I rebooted to my emergency slink system. (My normal development system is on hda1, with hda2 for swap, and hda3 for the slink system) /dev contained the empty directory /pty, and a |init* file. Recovering /dev from hda3 just brought up further errors: /etc/init.d and /etc/resolv.conf are gone, but most of /etc is still there. /bin is completely gone, as is /boot, although the system will still boot on either the hda3 kernel or the hda1 kernel (both of which reside in /dev/hda1/boot), so although the file system doesn't seem to know about these files, they are still there for LILO to use. Worse yet, my whole /Debian partition is wiped clean, so I will have to recover from original source and hope I haven't lost too much work. Before I rebuild this system and recover, I would like to understand just what happened, so I don't do that again. It is pretty hard to understand how a script failure in the middle of a source extraction process (which is what seemed to happen just before the lockup), could cause such pinpoint failures as those seen above. Why did /bin go away, but only parts of /etc? Why did /boot and /bin go away entirely, but /dev only got most of its contents removed? I'm going to take my time recovering from this, as there are things still on hda1 that I am likely to want saved. Any helpful hints about how to keep such things from happening in the future would be greatfully appreciated. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Hosed system during package build
On Thu, 16 Sep 1999, Ben Collins wrote: On Thu, Sep 16, 1999 at 04:38:56PM +, Dale Scheetz wrote: This is a first for me! As you may have noted from earlier postings, I have been working on a source build process for distribution construction. During the build of one of the source packages, the system went away. What kernel version were you using? It's possible that you hit some sort of ext2 corruption completely unrelated to what you were doing at the time. Well, it _was_ a 2.2.X kernel (I think a .10), and since the script was doing a 'dpkg-source -x' at the time, your suggestion has merrit. Do you know of any other reports of file corruption, and with which kernels? 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Increasing regularity of build systems
On Wed, 15 Sep 1999, Antti-Juhani Kaijanaho wrote: On Tue, Sep 14, 1999 at 03:54:15PM -0500, Erick Kinnee wrote: On Tue, Sep 14, 1999 at 10:23:50PM +0300, Antti-Juhani Kaijanaho wrote: No. Uhm, WTH is that about? No, what? No, they suck? No, don't standardize? No, don't standardize. How about a better idea maybe? If there were some specific problems here, I would certainly help in the design of a good solution. But there is no point trying to solve a problem of which only the proposer knows what it is! The specific problem is that with multiple optional helper packages available, all are being used somewhere to build some package, so, if you want to build all packages in Debian, you _must_ first install _all_ of the helper packages. I think it's a nice idea, but hard to do. I would be against standardisation on any helper package, unless there were *really* good reasons for it. There _is_ a really good reason, and I would suggest that we go farther than standardizing on one over another, we should incorporate the helper scripts into dpkg, so there is only _one_ package you need to build source. (yes, I know that there are other, unavoidable, source dependencies, besides the helper scripts, which must be buildable as well) We should also require that packages that are essential to the build process, not use any helper packages other than the dpkg incorporated tools, keeping the source dependency tree managable. 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: An 'ae' testimony
On Wed, 26 May 1999, Sven LUTHER wrote: On Sat, May 22, 1999 at 11:51:48AM -0400, Dale Scheetz wrote: As for the editor that should go on the boot floppies? I'll stay out of that discussion, except: Should anyone come up with an editor that emulates the old DOS edit program, and takes the same order of space on the boot floppy as ae, I would be in favor of replacing ae with that editor. (or one that fits the same space/function constraints) Other than that I could honestly care less what editor is on the boot floppies, I'm sure I will be able to use it ;-) You said above that ae keybinding can be edited. why not provide an optional /etc/aerc or whatever with said edit bindings ? or maybe i misunderstood some stuff. This is what caused the probems with the vi mode (I provided an alternative rc file). The actual situation is that ae only does a small handfull of functions, and it does them in a specific way (save file always prompts for the name which some folks have objected to.). The fact that you can load a file, add text, cut and paste text, and delete text, seems to fall short of the required tools for fixing a broken system. Personally, I don't get it. Also is there a simple ans small help text on how to use ae that could go on the boot floppies also ? ae, carries it's own help, and presents it at the first screen. Something during the installation needs to indicate the name of the editor available on the boot disk. I don't see any need for more 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 _-_-_-_-_-_-_-
Re: An 'ae' testimony
On Wed, 26 May 1999, Sven LUTHER wrote: On Sat, May 22, 1999 at 12:21:02PM -0400, Dale Scheetz wrote: On Sat, 22 May 1999, Michael Stone wrote: On Sat, May 22, 1999 at 07:49:11PM +1000, Craig Sanders wrote: some version of vi is essential on a rescue disk, regardless of what some windows using loudmouth happens to think (and no, i'm not referring to you here joseph). That's just silly. If someone can figure out vi, they really ought to be able to figure out how to use an editor with on-screen help. We're not forcing anyone to write a book with it, just use it for a couple of seconds in an emergency. ae is fine except for the vi emulation mode. it does the job, a simple no-frills no-features text editor. I disagree: I think it's still more complicated than it needs to be. Complicated? E.g., the big block of commands at the upper left is a bit too cluttered. Upper left? You _are_ refering to the help screen aren't you? This screen coveres the top third of the screen, and includes every operation ae will perform. How would you suggest that I make it less cluttered? The phrase, a bit too cluttered is not something I can convert into a patch ;-) remove this help stuff, and have just some sort of help binding that will bring it up. That would be nicer, and let more space for editign. In your last posting you asked for more help information. Now you are asking for less. Is it any wonder that I have trouble satisfying the divers needs of the editing community? Your comments make it clear that you haven't used ae in a long time, if ever. When you first enter ae, the help screen takes up the top third of the screen. One of the items on that screen tells you how to toggle the help screen on and off. If I set it up so that there is no help screen on startup, how is the uninformed vi expert to know how to get the help screen? The prompts sometimes leave something to be desired (When I type ^X^C after changing a file, why does the prompt have n^H at the end of it?) This is a bug that both the author and myself have been unable to resolve. It seems to be an artifact of key encoding, but, since the error isn't obvious, it could just as easily be caused by something else (like a curses difficulty of a completely different nature). As it is only visual cruft, and doesn't effect the opperation of the program, I have not been too frantic about it... yes, but someone who is editing his systems config file file be distrustfull to such garbage. Send me a patch. And it _is_ possible for people to get trapped in ae--but people While this was true for several broken releases of ae, this has not been possible for a long time. The reason this missinformation remains in play for so long is that folks continue to use old, broken rescue disks. The current version of ae does not suffer from this problem, and hasn't for some time. Sure this happened to me a long time ago, didn't try ae since because of it though. So, whenever a program exhibits a bug, you stop using it? You must have a very sparse system ;-) Seriously, if you wish to be helpful with your comments it would help if your understanding of the situation weren't ancient history. 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 _-_-_-_-_-_-_-
Re: request to kill nag messages
On Mon, 24 May 1999, Joey Hess wrote: Dale Scheetz wrote: One way to deal with this is to just mark all your bugs as wish list. The nags don't react to wish list bugs ;-) I hope you arn't seriously advocating that. It's fine for you, if you can keep straight whoch of the bugs are real bugs that need to be fixed. But if anyone else wants to look at and try to fix old bugs, they'll likely skip wishlisted items. Please note the smiley face (and the wink). I was trying to be as rediculous as the nag messages... 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 _-_-_-_-_-_-_-
Re: An 'ae' testimony
On 22 May 1999, Adam Di Carlo wrote: a) keep ae, but remove the vi emulation mode -- I haven't seen anyone claim that ae sans emulation mode is good enough. The list seems to agree, the ae maintainer agrees, and it's easy to implement, so I suggest this is the course of action we take. b) replace ae with something else, the only real contender AFAICT being 'ee' Dale, do you agree with (a)? Should we just go with that? Done, 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 _-_-_-_-_-_-_-
Re: An 'ae' testimony
OK, I haven't read all of this thread, but I've read enough to know that most of what I haven't read is either reguarding a replacement editor or of no value to me ;-) First of all, I only have one complaint, and it goes to Joseph Carter's snide remarkes about the non-functional nature of ae in general. This is simply not true. ae is a nice, functional, compact editor, who's only claim to fame is that it is smaller than anything else. The only current bugs against ae have to do with key bindings. On the other hand, I readily admit that the vi emulation mode is, and always has been to varying degrees, broken beyond repair. The whole concept is a broken one. ae is a nice editor when it runs modeless. As a modal editor (vi is a modal editor) ae is a disaster because of the way that it treats the two states. This makes it impossible to actually emulate the exact behavior of a vi editor. A few of the simpler opperations can be dealt with, but that is not sufficient for the finger programmed in the group. I was swayed to include the patch for vi mode emulation, and have worked real hard to keep that functionality as intact as possible (note the last patch for the Hurd folks), because of strong insistance that ae respond to the vi habituated among us. The repeated discussions about the lameness of the solution, including this one, have convinced me that this was a mistake. In the next release of ae, there will be no support for the editor impared. ae will only run as ae, and will no longer masquerade as something that it is not. If there needs to be a vi script that notifies the finger-programmed to type something else, it will need to reside somewhere in the boot floppies, and be discribed on some information screens during installation. ae will no longer support any reference to vi. If you don't like the key strokes that I have chosen for ae, you can certainly talk to me about them, maybe even submit a bug report. However, the current key configuration has been evolving over the last two years to handle the various strange tty situations where ae is being used, so I'm not likely to change anything here without it actually satisfying a larger audience. Because the key bindings of ae are configurable by the individual user (in their home ae.rc file) every user is free to change the keybindings to suit their needs (or finger memory). I use many editors during the course of my day. They range from sed, ed, and even under some circumstances ae, to vi, beav, joe, and even sometimes emacs. I don't understand how someone can come into ae, and not know what keys to press, as the complete list of possible keystrokes is listed, by default, in the help screen. (There seem to be a lot of folks who edit with their eyes closed ;-) If those keystrokes don't suit your tastes, then I can only suggest that you use a different editor. We have enough different kinds available! As for the editor that should go on the boot floppies? I'll stay out of that discussion, except: Should anyone come up with an editor that emulates the old DOS edit program, and takes the same order of space on the boot floppy as ae, I would be in favor of replacing ae with that editor. (or one that fits the same space/function constraints) Other than that I could honestly care less what editor is on the boot floppies, I'm sure I will be able to use it ;-) 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 _-_-_-_-_-_-_-
Re: An 'ae' testimony
On Sat, 22 May 1999, Michael Stone wrote: On Sat, May 22, 1999 at 07:49:11PM +1000, Craig Sanders wrote: some version of vi is essential on a rescue disk, regardless of what some windows using loudmouth happens to think (and no, i'm not referring to you here joseph). That's just silly. If someone can figure out vi, they really ought to be able to figure out how to use an editor with on-screen help. We're not forcing anyone to write a book with it, just use it for a couple of seconds in an emergency. ae is fine except for the vi emulation mode. it does the job, a simple no-frills no-features text editor. I disagree: I think it's still more complicated than it needs to be. Complicated? E.g., the big block of commands at the upper left is a bit too cluttered. Upper left? You _are_ refering to the help screen aren't you? This screen coveres the top third of the screen, and includes every operation ae will perform. How would you suggest that I make it less cluttered? The phrase, a bit too cluttered is not something I can convert into a patch ;-) The prompts sometimes leave something to be desired (When I type ^X^C after changing a file, why does the prompt have n^H at the end of it?) This is a bug that both the author and myself have been unable to resolve. It seems to be an artifact of key encoding, but, since the error isn't obvious, it could just as easily be caused by something else (like a curses difficulty of a completely different nature). As it is only visual cruft, and doesn't effect the opperation of the program, I have not been too frantic about it... And it _is_ possible for people to get trapped in ae--but people While this was true for several broken releases of ae, this has not been possible for a long time. The reason this missinformation remains in play for so long is that folks continue to use old, broken rescue disks. The current version of ae does not suffer from this problem, and hasn't for some time. are able to escape ee by typing the escape key and answering the prompts. cntrl Q works in ae. 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 _-_-_-_-_-_-_-
doc book filtering tools?
I am specifically looking for the db2rtf conversion filter, but there seem to be a whole collection of such converters that are no where to be found in Debian. (at least not in the slink contents file) I did a hotbot search, and came up with references, including the a copy of the make file that I was trying to run, but no reference to the source code for this filter. This specific problem is just one in a number of subtle requirements that seem to be designed into GPL'd documentation. Yes the original source is there, but much of it may not function, without some other piece of software that isn't normaly found in a standard system, and is not provided with the original source of the book. I'm currently trying to get a Rich Text Format output of the GNOME manuals. The make file provides a target for doing so, which fails on my machine because I don't have the db2rtf program. I have been running into other situations where some, but not all, of the book is provided as html files, and, although the other parts of the book do exist, and are available via the net, any indication of their locations in very carefully omitted from the rest of the material. While these actions _do_ satisfy the letter of the GPL, they certainly don't satisfy the spirit of cooperation embodied in the principles of that license. Personally, I find the imposition of research costs into the path of document freedom to be obstructionism of the came caracter as witholding source, or specification information about hardware. Yes, it an be figured out, but making it difficult to do, is proprietary thinking. The less of that we can exercise, the better off we will all be. Sorry for the rant...I just need the converter ;-) 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 _-_-_-_-_-_-_-
Re: An 'ae' testimony
This is a loose/loose situation. ae IS NOT vi, but can sort of simulate the more important vi commands. However it doesn't even do that the same way, so real vi users are put off byt the quit functionality. The vi link was to satisfy those whose fingers can type nothing but vi. Personally I don't get it. ae comes up with a complete list of available commands on the screen. There is little chance of misunderstanding what editor is on the screen if one is the least bit observant. I would be more than pleased to have some other vi simulator on the boot disks so I could remove the vi-trash from the Debian implementation of ae. Luck, On Fri, 21 May 1999, Jules Bean wrote: I don't want to start a flame-war, so be gentle.. I was just mindlessly (in a tongue-in-cheek way) evangalising Debian on a mailing list I'm on, and I got a private response from a SuSE user. He had installed Debian from a CD (he didn't say which version, I'm afraid) and 'vi fstab' to mount his old partitions. Then he had attempting to do something which would have worked in vi (he didn't give specifics) but doesn't work in 'ae', which resulted in the file getting mangled, and saved. So he switched to SuSE. I'm aware this isn't a particularly helpful post - I'm not suggesting a solution, I don't know what the solution is. But it makes you think. Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- 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 _-_-_-_-_-_-_-
Re: request to kill nag messages
On 21 May 1999, John Goerzen wrote: Dale Scheetz [EMAIL PROTECTED] writes: No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. I don't get such a report. Probably because you are not subscribed to the bug-report mailing list ;-) You have the choice to either recieve bug report synopsis this way, or not by whether you choose to subscribe, or not. The nag messages are specifically designed so that individual developers may _not_ request they not recieve such mail. If you can't see the principle involved in the difference between these two approaches, then I regret I will never be able to convince you there is, indeed, a difference. If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. Why does this mean it's a problem? Because there is no mechanism (aside from closing the bug report) for stopping such messages, if you find them offensive, useless, and obnoxious clutter! I am being imposed upon, by someone who is supposed to be a fellow developer, in a way that I find totally unhelpful. When this, supposidly competent programmer tells me he can not impliment an exception list for these mails, I must wonder why I am being treated like a child with a dirty room. There is a significant difference between a reasoned list of critical release bugs and the arbitrary age mechanism of the nag system. There are many _good_ reasons to leave a bug report open for an indefinite period of time. There is nothing inately evil about an open bug report. The nag message implies that exactly the opposite is the case. This is not a person asking a developer to fix a bug. This is an automated system that spits out messages with NO content of use to the developer, and adds nothing but bulk to the already functional system. The person already asked for a fix, and generally deserves a timely fix. Why not close the bugs instead of complaining about those that remind you to? Many bug reports ask for different behaviour without reguard for the larger issues involved. My experience is that closing such bugs is not a solution that is usually acceptable to the reporter. The person may ask for a fix, but provide no solution. The obvious solutions may be undesirable. A reasonable solution may not exist, or may require the modification of other packages before it can be implimented. The list of reasons not to close a bug are long, but boil down to one simple fact. You don't close a bug report until the bug is fixed, and time is not the sole criterion for fixability. To be reminded of something you already know about is, at best, redundant. 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 _-_-_-_-_-_-_-
Re: request to kill nag messages
On Thu, 20 May 1999, Joel Klecker wrote: At 18:10 +0100 1999-05-20, Adrian Bridgett wrote: On Thu, May 20, 1999 at 06:47:28AM -0400, Dirk Eddelbuettel wrote: Brian Nag also sends emails regarding old bugs on your packages. I never Brian subscribed to that. :p All I'm saying: Everybody is free to procmail away whatever they don't like. This sounds like a good idea - send the Nag reports to the email address @debian.org (which hopefully everyone has). Then if some kind soul could tell us what lines to add where to filter it everyone will be happy. Don't presume to speak for everyone. I would not be happy with that. I will only say that just filter it out or just press the delete key are spammers' answers. I am well aware of my bugs, and I DO NOT need reminders of them. One last thing, the next nag message I get will be treated as spam. One way to deal with this is to just mark all your bugs as wish list. The nags don't react to wish list bugs ;-) 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 _-_-_-_-_-_-_-
Re: request to kill nag messages
On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. This is not a person asking a developer to fix a bug. This is an automated system that spits out messages with NO content of use to the developer, and adds nothing but bulk to the already functional system. This _is_ spam, and nothing more. Please be aware that any message with the word Nag in the subject is always deleted and never read when sent to me, so if you really want to contact me don't use that word ;-) You aren't really suggesting that any well meaning person is correct to set up an automated system for notifying developers about place your important issue here, then you should not complain when some dodo sends you, and the list, critical information about how to get rich quick. He is only trying to be informative... 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 _-_-_-_-_-_-_-
Re: request to kill nag messages
On Wed, 19 May 1999, Christian Kurz wrote: [You don't need to send me an extra Cc as I read the lists on which I write. Thanks!] Dale Scheetz [EMAIL PROTECTED] wrote: On Wed, 19 May 1999, Christian Kurz wrote: Branden Robinson [EMAIL PROTECTED] wrote: On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: I'm not the only one to be annoyed at the nag messages that are sent out. Can the script please be disabled. There are better ways to find out bugs you have open. Long-standing bugs are likely to be less important than recent bugs too. I would rather see the old bugs closed. An old bug is still a bug. Don't like the messages, help close the bugs. Wrong. Brian White is no longer the release manager, so he has no special privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. No one needs to take on that job, as the BTS already reports all open bugs twice a week to every developer. Are you sure? I don't know that this is done by the BTS and have never heard about this? Here is a sample of the beggining of what I normally get on Tuesdays: -begin paste- Date: Tue, 4 May 1999 16:29:46 -0500 From: Debian Bug Tracking System [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Unanswered problem reports by maintainer and package Resent-Date: 4 May 1999 21:30:06 - Resent-From: [EMAIL PROTECTED] Resent-cc: recipient list not shown: ; The following problem reports have not yet been marked as `taken up' by a message to [EMAIL PROTECTED] or or `forwarded' by a message to [EMAIL PROTECTED] ---end paste-- Note that this is a subscription list, so you must request placement on this automated report generator. On Friday the report is ordered differently, and can be grepped for your name to separate out your own bugs from all the rest. You can also request limited reports on your own. Send the word help in the body of a message to [EMAIL PROTECTED] and you will get a list of all the commands that the request server responds to. Among them are requests for indexes by package, or by maintainer. You can then take these indexes and request the actual bug report itself. If this was simply a report to the list, once in a while, like the critical bugs that need to be fixed list, there would be no problem. Instead this mail is generated automatically and sent to every developer with an open bug report over a certain age. Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you The problem is that I can not request that the messages stop, like I can with this list, and the other BTS lists. Even aggressive, and angry requests have met with rejection. This is, by definition, unwanted spam. may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? How do the nag messages to Phil help you know which of his bugs are in need of repair. Your idea that mainainers forget to fix a bug is simply FUD. Nobody forgets a bug, they either don't have the time to figure out what is wrong, or for what ever reason cannot put the manpower into solving the problem. Under these conditions a NMU is very reasonable. I never turn down such help, but what does this have to do with the nags? You seem to have missed the point that, although some of the nags only go to a mailing list, each maintainer also recieves his very own copy of the nags for his packages. Until I complained loudly to Brian about not being able to control the flood, he reduced these messages to only one per maintainer. Previous to this, there was one message for each outstanding bu you had in the system. When I was maintaining glibc this amounted to hundreds of messages cluttering up my inbox. While reducing the number of messages takes the cost load off of the maintainer, the fact that they can not be stopped all together makes them nothing but spam. This is no different from some helpful developer spamming people who, say, have had bugs open for over a year. Such people have (rightly) come under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else
Hurray! and thanks! Re: Update ... Re: Ethernet newbee failure
Thanks to Tony Mancill for pointing out: http://cesdis.gsfc.nasa.gov/linux/setup/3c5x9setup.html The 3c5x9setup program takes the 509 out of PnP mode and lets you set the base and IRQ addresses and write them into the eeprom. I set the card using 3c5x9setup to the base address 300 and IRQ 10 and that was all it took. I was even able to set the irq on the second machine to 12 (what Win'95 thinks the card is on) and the Linux driver came up on the right interrupt! I have now reached Network Administrator, Junior Grade, and am the proud owner of a, soon to be, three machine LAN. Thanks to everyone who helped me out of this boggy pit, I could never have done it without your help. Now, to set up Samba ... 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 _-_-_-_-_-_-_-
3c5x9setup and isapnptools
After my recent experience gettying my new 3COM EtherLink III cards to work, I would like to suggest that 3c5x9setup be included in the isapnptools package. It is composed of a single .c source file with an embedded copyright notice licensing it under the GPL. I would be willing to write a man page from the .html file provided, if Frederic Lepied would be willing to include the two in the isapnptools package. I think this is a better place for this than trying to build another package around this simple program. On a Linux machine the EtherLink III card will not function properly when configured with isapnp, and must be taken out of pnp mode using 3c5x9setup. It seems only logical to have the tool for doing this included with the other isapnp tools. What do you think Frederic? Can we do this? 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 _-_-_-_-_-_-_-
Update ... Re: Ethernet newbee failure
First I want to thank everyone who sent me a reply, both private and on the list. I now know 3 different way to create working routing tables. With regret, this has not resolved the problem. It was John Hasler who actually resolved things for me. I now have the following routing tables on both machines: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 127.0.0.0 * 255.0.0.0 U 0 01 lo 10.0.0.0* 255.0.0.0 U 0 00 eth0 I get better results now than ever before, but still can't complete a ping. Here are the facts: 1. Each machine can ping itself successfully. 2. A ping to the other machine returns 0 packets to the kernel. 3. The PKT light on the hub blinks while a failed ping is in progress. The NICs are EtherLink III cards connected through a hub using twisted pair cable. Suppositions: Fact 1 is not useful, as the kernel, seeing the information in the routing table, has no reason to go to the card to resolve the ping. In this circumstance the kernel is talking to itself and the ping program, not the card. Fact 3 indicates that the ping is getting out of the kernel, into the card, and onto the cable. When properly configured the card in machine one gets a reply from the card in machine two, but fails to get that message to the kernel. (fact 2) At this point, it is my supposition that the card is responding on another interrupt from the one it was commanded to use by isapnp, and the driver. The kernel, the driver, and the isapnp program, all think the card has been configured for base address 0300, and irq 10, yet no traffic makes it out of the card into the kernel, suggesting that it is using another interrupt. As painful as it seemed at this point, I was ready to try loading the driver commanding each interrupt that the card might use, hoping to stumble on it by a careful search. Although the documentation seems to indicate that the only parameter that I can send to the driver is the irq, modconf says that the io base address can also be entered. Worse than that, if you try to specify another interrupt for the driver install, it hangs forever. I was able to do an insmod including the parrameter, but the results were not what I expected: dwarf# insmod 3c509 irq=12 eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 10 5a de c8 16, IRQ 10. 3c509.c:1.16 2/3/98 [EMAIL PROTECTED] Note that the driver still declares irq 10 rather than the irq 12 that I requested. Is my syntax faulty? Ben Pfaff indicated that his card requires a special option before the kernel can hear it. I can find no such indication for the EtherLink III card, but his experience seems similar to mine. Can anyone clue me in? 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 _-_-_-_-_-_-_-
Ethernet newbee failure
I have added Ethernet cards to two machines, one my Linux box, the other my partner's Win'95 machine. To reduce the configuration problems, I installed Debian on the second drive of my partner's machine, reducing the problem to two Linux machines connected through the same hardware. Machine one is 10.1.1.10 and machine two is 10.1.1.20. From either machine I can ping that machine but not the other one. Both cards seem to be working, but I have no network connection. I set them both up with ifconfig and route add, and when I do an ifconfig, I get the following: loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:57 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 eth0 Link encap:Ethernet HWaddr 00:10:5A:DE:C8:16 inet addr:10.1.1.10 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 Interrupt:10 Base address:0x300 The only thing that looks strange here is the Bcast: and Mask:, but I didn't set them. It isn't clear that this is the failure either. I'm pretty ignorant about this stuff, but I think I did everything I need to have a LAN but it doesn't work. Any ideas? All informative flames appreciated ;-) 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 _-_-_-_-_-_-_-
Re: Ethernet newbee failure
On 14 May 1999, John Hasler wrote: Dale Scheetz writes: The only thing that looks strange here is the Bcast: and Mask:, but I didn't set them. It isn't clear that this is the failure either. The ifconfig output looks fine. What does 'route -n' say? I have had several suggestions, all of which are implemented in this particular route table: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 199.44.194.10 0.0.0.0 255.255.255.255 UH0 00 ppp0 10.1.1.10 0.0.0.0 255.255.255.255 UH0 00 eth0 10.1.1.20 0.0.0.0 255.255.255.255 UH0 00 eth0 10.1.1.20 10.1.1.10 255.255.255.255 UGH 0 00 eth0 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth0 0.0.0.0 199.44.194.10 0.0.0.0 UG0 00 ppp0 When I do: route add -host 10.1.1.10 dev eth0 route add -host 10.1.1.20 dev eth0 on both machines, the ping still doesn't work, but I get the PKT light on the hub to blink in time with the pings. This seems to indicate that the hardware is doing the right thing. I still think there is something missing from route... 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 _-_-_-_-_-_-_-
Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0
On Sat, 30 Jan 1999, Alan Cox wrote: I'd like to propose that for now the FHS is changed to read The mail spool area location is undefined. It is guaranteed that both /var/mail and /var/spool/mail point to this mail spool area if the system has a mail spool. The preferred reference name is /var/mail. [Rationale: /var/mail is the only name available on some other modern Unix platforms. /var/spool/mail is the older Linux tradition and needed for compatibility] [Rationale2: The physical location of the mail spool is not relevant to an application and is administrator policy. It is thus left open.] Can everyone live with that and bury the thread Works for 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 _-_-_-_-_-_-_-
mirror problems with ftp.debian.org
I had my mirror fail today with the following message: package=source ftp.debian.org:/debian/dists/slink/main/source - /mnt/c/4/debian/dists/slink/main/source Cannot get remote directory listing because: 200 Type set to A. Cannot get remote directory details (/debian/dists/slink/main/source) The binary-i386, and binary-all parts work just fine. It is only when the source section (package) runs that I get this error. I can ftp in with mc and get dirctory listings just fine. Anyone have any idea what the problem is? 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 _-_-_-_-_-_-_-
Update was Re: Unsatisfied depends in slink main
First I want to thank everyone for their replies. Second I want to appologize for my incorrect phrasing of the subject line. Several people have pointed out that there are very nice packages that deal with dependencies, while others pointed out that the other ored elements satisfied the dependency needs. I should have made it clear that my intent was to find any and all references, that could not be satisfied in the supplied set of packages. As the Packages file is the weak link in the distribution method, I decided to interrogate the actual packages in the given archive and parse their control files. As it turns out, the issue with ppp stems from the fact that, although I started out with a hamm archive as the seed for my slink mirror, satisfying the symlinks, when the package in hamm changed, and the older version was no longer correct, mirror removed it and then failed to make the link to a non-existant hamm directory on my site. I'll be able to recover any other missing files by looking at the changelog, but this brings up another issue. I had understood that, as packages were changed that these symlinks would go away, so all changed packages in hamm should have also updated in slink, disolving the link? In any case, as we are in a freeze, shouldn't these links be replaced with the actual files? I mean, if slink is in freeze, and hamm is still being upgraded... 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 _-_-_-_-_-_-_-
Re: Update was Re: Unsatisfied depends in slink main
On Fri, 22 Jan 1999, Jason Gunthorpe wrote: On Fri, 22 Jan 1999, Dale Scheetz wrote: I should have made it clear that my intent was to find any and all references, that could not be satisfied in the supplied set of packages. As the Packages file is the weak link in the distribution method, I decided to interrogate the actual packages in the given archive and parse their control files. Of course this is not at all true, the package files are generated directly from the .deb files daily they are never wrong, if they were then our tools would stop working! While what you say is in principle true, in practice it doesn't always work out that way. My experience has been that many problems experienced by our users, and much of the fault on broken CDs have been the result of out-of-sync Packages files. In my most recent personal case, that broken sync was caused by a broken mirror configuration WRT symlinks. The result was a package in the Packages file but not in the archives. This can happen through a chain of mirrors in several ways. (Yes, I know that there are safeguards to help, but they are not always used) For myself, I draw through such a narrow straw that it may take days to complete a pass. I know, under these circumstances that I must repeat the mirror until a pass can occure in shorter timeframes. I also know that there are ways to unsync if you have a bigger straw. It's only a matter of timing. Several of the CDs that have been produced by vendors with unspectacular results have been partialy the result of broken Packages files. I have always considered this to be a weak link in the installation process. I know that when I build Packages files using dpkg-scanpackages, that it can take a long time, and that such reconstruction within and FTP install/upgrade is difficult without retrieving the archive, but when the package installation tools can't recover the Packages file, a broken CD is unrecoverable trash. Being able to run against an arbitrary archive is going to become more and more necessary as the distribution becomes larger. 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 _-_-_-_-_-_-_-
Re: Unsatisfied depends in slink main
On Thu, 21 Jan 1999, Jason Gunthorpe wrote: On Thu, 21 Jan 1999, Dale Scheetz wrote: Since the recent discussion with Richard Stallman about the unsatisfied suggests message, I have undertaken the examination of the main archives. The script that I am working on unpacks all of the .deb files it finds and collects Package:, Provides:, Pre-Depends:, Depends:, Recommends:, and Suggests: field information and deterines several things. You do realize that is why we have a 'Packages' file? Yes, and the current packages file indicates that ppp is in base, but it isn't there. The whole reason for scanning the archives was to catch such errors. In any event your script is not handling virtual pacakges, ppp is a virtual package. I add all Provides: to the list of available packages that I use. So if some package provides ppp it isn't indicating that fact. Here is a list of all unmet deps in main: Package chameleon version 1.0-2 has an unmet dep: Depends: libglib1.1.12 (= 1.1.12-1) Depends: libgtk1.1.12 (= 1.1.12-1) (Ehm? This one is new, someone should fix it) A list of unmet suggests/recommends in main is too long to include here. Actually my lists are not much worse than the depends. If I get a chance to work on this today, I'll put the other lists together. 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 _-_-_-_-_-_-_-
Re: Unsatisfied depends in slink main
On Thu, 21 Jan 1999, James R. Van Zandt wrote: Dale Sheetz writes: ... Package not in archives Package which depends on Package not in archives ... tclx emacspeak tclx74emacspeak tclx75emacspeak Here's the actual dependency for emacspeak: Depends: tclx76|tclx75|tclx74|tclx, emacs20 We have /debian/dists/unstable/main/binary-i386/oldlibs/tclx76_7.6.0-3.deb in slink, but older packages would also suffice. What's wrong with this? My mistake. The script parses out each depends and doesn't pay attention to the or-ness. Looks like time for a redesign ;-) 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 _-_-_-_-_-_-_-
Re: Unsatisfied depends in slink main
On 21 Jan 1999, Jim Pick wrote: Dale Scheetz [EMAIL PROTECTED] writes: giflib3g-dev gdk-imlib-dev giflib3g-dev imlib-dev giflib3g-dev libfnlib-dev The full dependencies for these is more like: libungif3g-dev | giflib3g-dev Basically, the unfree giflib stuff has to be in the depends field, because it's in an or relationship with the equivalent free package. You are correct. I haven't dealt properly with the or conditions. 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 _-_-_-_-_-_-_-
