Install issue
I ran through my first x86 install today, and had a wierd problem. After pounding my bios into properly detect both c and d drives, I started the install using loadlin planning to avoid floppies altogether. However, when the time came to select a partition to find the resc1440.bin for drivers, it failed to display hdc1. My partitions were this: hda1, a 1.2GB FAT32 drive hdc1, a 3.6GB partition on secondary master (5GB drive) hdc2, 1.3GB ext2 hdc3, swap hda1 showed, and hdc1 was indeed not mounted but did not appear in the selection dialog box (after choosing media harddisk). I was able to mount it by hand in the other VC and continue, though. Any ideas? dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Install issue
On Sat, Jun 06, 1998 at 09:55:57AM +0100, Enrique Zanardi wrote: > > Not yet. A few questions: Which filesystem type has hdc1? Which version of the > boot-floppies were you using? I assume hdc2 and hdc3 were properly detected > in previous steps (initialize swap & initialize linux partition), right? hdc1 was FAT32, as was hda1 (which did show up). The boot-floppies was (i think) 2.0.6 - it was the current set off of ftp.debian.org as of midday yesterday. hdc2 and hdc3, which I created with cfdisk during the install, did indeed get deteceted properly and initialized. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Install issue
On Sat, Jun 06, 1998 at 12:28:24PM -0400, LeRoy D. Cressy wrote: > Where or what is your /dev/hdb drive? Is your hdb drive your > cdrom? If so, it should be detected. I don't know if the > cdrom has been compiled as a module, if so they must be loaded from the > drivers > disk. hdb is my cdrom, but there is no disk in it. I assume that's why it wasn't showing up. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Propersel for standerd configuration system.
Now, don't get me wrong...I hate windows registries just as badly as anyone else, and I've been using linuxconf on and off for ages. But this has one darn good idea to it: many programs using the same data source. For instance, I just installed this machine with one hostname before realizing that alas, I could not get that hostname! It was a royal pain to find all occurances of that hostname and change them all. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop vi discussion
On Mon, Jun 15, 1998 at 12:34:38PM +0200, Yann Dirson wrote: > Andreas Jellinghaus writes: > > what then ? > > joe. > > Well, that's IMHO an idea worth worth studying. When I first > installed Linux, I was coming from DOS and Borland's editors, which > joe mimics quite closely. And joe, like ae, emulates other editors - not quite perfectly, perhaps, but I'm writing this non-flame in jpico, which I find exceedingly convenient sometimes (I symlink /usr/local/bin/pico to it and can get by that way; evil habit of mine). But this thread relly has begun to go on too long. Dan [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to Package: mod_perl
mod_perl (which I'm going to package as libapache-mod-perl .. any
better ideas?) is an apache module for tighter integration of Perl with
Apache. With the releases of 1.12, mod_perl compiles pretty simply as a
shared Apache module, so now looks like the right time to package it up.
The package is almost ready.
Source: libapache-mod-perl
Section: main/web
Priority: optional
Maintainer: Dan Jacobowitz <[EMAIL PROTECTED]>
Standards-Version: 2.4.1
Package: libapache-mod-perl
Architecture: i386
Depends: ${shlibs:Depends}, apache (>= 1.3.0), perl
Description: Integration of perl with the Apache web server
mod_perl allows the use of Perl for just about anything
Apache-related, including sections in the config
files and the famous Apache::Registry module for caching
compiled scripts.
.
It can produce anywhere from a 400% to 2000% speed increase
on sites using perl scripts, and is used on many large script-
based web sites - for example, www.slashdot.org.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: worth packaging apache-modperl ?
Since the dynamic version of mod_perl is quite broken right now (I believe Jules advised the perl maintainer of the problems; loading dynamic shared objects from another DSO reults in a few undeclared symbols from libperl.a - I'm guessing somehow the lowest level module can't see them, and don't know what to do about it) I've been considering packaging something called apache-modperl which would be exactly identical to apache but have mod_perl compiled in statically. It would Provide: apache. Any comments? Agreed, it's an ugly hack, but it may be a while before this issue is resolved and I have received several messages which suggest people want a mod_perl solution fairly promptly. This would beat each user trying to compile it into apache themselves, certainly. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: worth packaging apache-modperl ?
Will do, then. This leaves me one big question, though. This is going to require mixing four things: (A) apache 1.3.0 (B) netgod's massive apache diff (C) mod_perl upstream -- probably going to version it by date and use the CVS tree instead of the rarer new releases. (D) My own diff for this project. Any ideas on how to handle this? dpkg still doesn't handle multiple source tarballs so I'll probably have to make an orig containing apache and mod_perl,, and just use netgod's diff as the basis for mine. Or I could apply his diff to the orig since it's not my work, and work on top of that. Slightly puzzled. Dan [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: The BTS, "Severity: Fixed", etc. (Was: An idea for the BTS)
On Tue, Jun 23, 1998 at 12:38:19PM +0200, Wichert Akkerman wrote: > Previously Manoj Srivastava wrote: > > I think that not only should bugs be marked by the > > distributions they exist in, they should also be classified by > > architecture; > > Actually, I think we can do the same way more efficent. Each bug already > has a Version-number. Now we if we add a field Fixed-in-Version the BTS > can simply look for which architectures the fixed version is available. Except that sometimes bugs are architecture-related. For instance, an endian assumption bug. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade report from "bo" to "hamm" :-(
On Tue, Jun 23, 1998 at 08:09:51PM +0200, Paul Seelig wrote: > Actually the true killer was the upgrade of the teTeX packages. It is > pretty hard to stand seeing three time in a row "Running initex [...] > This will take some time" on a 486DX-2/66 at the configuration stage. > This alone consumed almost half an hour IIRC. > > Would "apt" have made a difference with this? Like installing and > configuring all teTeX packages in a row and running "initex" > afterwards just once? Or is this simply impossible? Which reminds me - the same method that we come up with to fix this, if it can be fixed, might be usable for iamerican/ibritish. What we need is something along the line of what update-menus does but interactive. Perhaps DPKG:TNG wil include some way of registering a script to run at the end of the configuration? Any interactive but non-vital configurations could then happen at the very end, easing one point. It would probably allow one running of inittex and one selection of ispell dictionaries. Ideas? Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xterm-debian terminfo entry
Or at least offer an xterm-cons or xterm-black-bg. Also, could someone PLEASE figure out the remaining options to make xterm behave graphically like a console? I can't get the combination of bold and 16 colors to work correctly. Dan On Tue, Jun 23, 1998 at 05:43:54PM -0500, Alexander E. Apke wrote: > Now that debian is going to be using a nonstandard terminfo entry > for xterms, can the default colors be setup like a normal linux console, > black background with white foreground. > > I liked this when the xterm was setup this way a while back. I > believe the reason for switching back to white background was for > compatibility sake. Since xterm-debian is the standard terminfo entry > for debian, a black background would also be nice. > > The black background is much more pleasing to the eye, especially > with colors enabled. > > > Alex > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gothenburg -> Vancouver
The problem with roadrunner is this: They explicitly disallow all servers of ANY kind. No open ports, except maybe identd. A friend of mine was running one just fine under linux, with dhcp and all, but got his account terminated for having sendmail up :) So be careful. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PERL: patch for glibc 2.1
On Mon, Oct 05, 1998 at 05:19:51PM -0700, Darren Stalder wrote: > Matt McLean, in an immanent manifestation of deity, wrote: > >this is necessary since the semun union is no longer in the libc. its been > >awhile since your last perl upload, and newer versions have come out.. are > >you still alive? :-) > > I thought I'd be able to have access to a PPC Linux box today, but > that's not going to happen. The semun union patch didn't make it into > this version of Perl since doio.c has changed quite a bit. Can you > please check it to make sure it's still needed and get me a new patch if > it is? > As a general aside, if you want an account to test something, tervola (powerpc.debian.org) is already available, and my machine here at CMU will be providing developer accounts in a few days (soon as my nine gig drive gets here and I have room for the lot of you :)> Dan
Re: korganizer debian package (OT: licence interpretation)
On Mon, Oct 05, 1998 at 05:27:23PM +0200, Moritz Moeller-Herrmann wrote: > I study law. And I can tell you that there´s not a problem with the GPL > licence in the KDE project. Even if the GPL (read very narrowly and literally) > prohibited the use of QT, every judge/lawyer would reinterpret this licence to > allow the use of QT , if the author of kpackage used it to distribute his > program. What I am trying to say is, a licence can be interpreted in many ways > and one very important issue in the interpretation of any legal document is > the > intent of the author or the user of this document. As the author of kpackage > didn´t want to ban anyone from using qt, his licences (the GPL) must be read > to > allow the use qt. No problem so far. > Problems could only arise if another copyright holder´s rights were violated, > for example if a second GPLd program were merged into kpackage, and the author > of this program read the GPL in a much more strict way than the author(s) of > kpackage. Then we´d have two licences (both of identical wording: GPL), which > could be interpreted differently, because the people who use the licence have > opposing intentions with their licence. Since you distribute a binary DEB > file, > the problem can´t come up. > Hope to clarify the issue a bit! I have one question to that - in what way does distributing a binary suddenly resolve a licence conflict? According to the GPL, GPL'd code can not be linked to QT; _only_ the author of a given piece of code has the right to make an exception to that rule. Because the original in many cases was not written for QT, no such exception is present. And just because it would most likely be struck down in court does not make it legal. The exception still needs to be present if it is intended. Dan
Re: what's after slink
On Wed, Oct 07, 1998 at 09:34:46AM +1000, Hamish Moffatt wrote: > Depends what image you want for the system. The HHGTTG was good, > but I don't think it is worth naming the releases after it. > I prefer the penguins. > > BTW, wasn't it "Slartibartfast", one word? Another vote for penguins. Speaking of which, anyone want to call a vote? :) And yes, it is one word. Dan
Re: PERL: patch for glibc 2.1
On Wed, Oct 07, 1998 at 01:34:42AM -0700, Darren/Torin/Who Ever... wrote: > >I know what's going on with IPC, and I'm guessing the DBM test is failing > >because of a bug in the libc. > > So, what's going on with IPC? IPC until very recently was completely hosed on powerpc. We have hopes that a new set of compiler and libc will resolve the issue - expect progress reports in the next few days :) Dan
Re: Perl policy for managing modules ?
> Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: > > I do worry about what this might break as well. Another option would be > > to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and > > leave /usr/lib/perl5/$version(/$arch)? there with only the Perl > > installed files. I'll ask on p5p if this will break things. My question is, why are we so intent on removing the versioned component even though we have lost binary compatibility? I understand that it requires some packaging changes, but the packaging can usually be easily rewritten to work for any version (use perl5/5.*/, etc.). Dan
Re: libapache-mod-perl
On Sun, Oct 11, 1998 at 08:01:42PM -0500, Justin A. McCright wrote: > Is anyone going to try and get a version of this that works with newer > Apaches out before the freeze? I'm working on it. It's very broken at the moment! Dan
Re: Upcoming 2.1 Release Architectures
On Wed, Oct 14, 1998 at 10:15:51AM -0400, Brian White wrote: > Could I get some official word on which architectures wish to be included > in the 2.1 release of Debian? Thanks! > > Brian > ( [EMAIL PROTECTED] ) PowerPC has more or less given up on making 2.1. We're moving well, but I'm of the inclination we shouldn't release until we have a truly stabilized libc - or at least until we're a lot closer. Dan
Re: [] Bug#27841: apt: apt depends on a missing library
On Mon, Oct 12, 1998 at 10:05:09PM -0700, Ben Gertzfield wrote: > Nobody has moved on getting libstdc++2.8 back in slink, even without > a -dev. > > Is anyone going to do this? > > Ben See, it's not "Is anyone going to?" or "Do we agree we should?" right now. It's "does anyone but Dan have the time to look at http://master.debian.org/~dan and figure out why the compiled libstdc++2.8 package whose source is there is missing a lot of important symbols". I can't figure it out. Dan
Re: [] Bug#27841: apt: apt depends on a missing library
On Wed, Oct 14, 1998 at 10:56:56PM -0700, Ben Gertzfield wrote: > >>>>> "Dan" == Dan Jacobowitz <[EMAIL PROTECTED]> writes: > > Dan> See, it's not "Is anyone going to?" or "Do we agree we > Dan> should?" right now. It's "does anyone but Dan have the time > Dan> to look at http://master.debian.org/~dan and figure out why > Dan> the compiled libstdc++2.8 package whose source is there is > Dan> missing a lot of important symbols". I can't figure it out. > > The source in http://master.debian.org/~dan in the libstdc sir > is for 2.9. Could this be the problem? I present http://master.debian.org/~dan/libstdc/libstdc++_2.90.29-1.dsc for your enjoyment... Notice it says Binary: libstdc++2.8. Dan
Re: [] Bug#27841: apt: apt depends on a missing library
On Thu, Oct 15, 1998 at 09:49:22PM -0700, Ben Gertzfield wrote: > >>>>> "Dan" == Dan Jacobowitz <[EMAIL PROTECTED]> writes: > > Dan> See, it's not "Is anyone going to?" or "Do we agree we > Dan> should?" right now. It's "does anyone but Dan have the time > Dan> to look at http://master.debian.org/~dan and figure out why > Dan> the compiled libstdc++2.8 package whose source is there is > Dan> missing a lot of important symbols". I can't figure it out. > > Ben> The source in http://master.debian.org/~dan in the libstdc > Ben> sir is for 2.9. Could this be the problem? > > Dan> I present > Dan> http://master.debian.org/~dan/libstdc/libstdc++_2.90.29-1.dsc > Dan> for your enjoyment... > > Dan> Notice it says Binary: libstdc++2.8. > > Wow. How does 2.90 compile out to become 2.8? The same way egcs 1.1b becomes gcc 2.91.53. The one is an interface number and the other an internal version. Dan
Re: moving mutt-i from non-us to main
On Fri, Oct 16, 1998 at 08:38:57PM -0500, [EMAIL PROTECTED] wrote: > Steve Greenland writes: > > While I agree in principle, you might want to ask Michael Elkins first; > > it's conceivable that he could be brought into any litigation > > I didn't realize that the author of mutt-i was a US resident (I don't use > mutt at all, myself). > He isn't. ME no longer does the mutt-i patches; they are maintained in Germany. Dan
Re: mutt
On Sat, Oct 17, 1998 at 09:42:54AM -0500, [EMAIL PROTECTED] wrote: > Marco writes: > > Look like there is consensus to move mutt-i to main. In the next days I > > will upload it along with some fixes. > > Do you think we should check with ME first? While I don't believe he is at > any risk of prosecution, we should respect his wishes. > > We should also consider moving any other software that is non-us because of > encryption hooks out of non-us. And I maintain that we can not do this. Much as I wish we could. Note that mutt-i has a separate upstream source - in Germany. Dan
