Re: debian-devel-digest Digest V102 #138
>debian-devel-digest Digest Volume 102 : Issue 138
>To UNSUBSCRIBE, email to email@example.com
>with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org.
> interesting times installing 2.4.17 [ email@example.com (Jim Gettys) ]
> Re: Debian as a CORBA component [ Rodrigo Moya <firstname.lastname@example.org> ]
> Virus Found in message "new photos f [ Justin Hahn <email@example.com> ]
> aspell package splitting => dependen [ Domenico Andreoli <cavok@filibusta. ]
> Bug#131301: ITP: netperf -- Network [ firstname.lastname@example.org ]
> Re: Debian as a CORBA component [ Adam Heath <email@example.com> ]
> Re: aspell package splitting => depe [ Adam Heath <firstname.lastname@example.org> ]
> Re: The future of gpassman (was Re: [ Andreas Rottmann <email@example.com ]
> Re: Encrypting BTS Messages [ Rob Bradford <firstname.lastname@example.org> ]
> Bug#131318: general: apt-get and dse [ Brady McCary <email@example.com> ]
> Re: The future of gpassman (was Re: [ Scott Henson <firstname.lastname@example.org> ]
> Re: Spam (Re: Urgent Investment) [ Manoj Srivastava <email@example.com ]
>Date: Mon, 28 Jan 2002 08:29:49 -0800 (PST)
>From: firstname.lastname@example.org (Jim Gettys)
>Cc: email@example.com, firstname.lastname@example.org, email@example.com
>Subject: interesting times installing 2.4.17 in Woody...
>Message-Id: <[🔎] 200201281629.g0SGTnO410989@pachyderm.pa.dec.com>
>I'm new to Debian; an old fart in UNIX and X, and using RH and Mandrake
>the last few years...
>I had an interesting (as in the chinese curse) installing Debian; in some
>ways, I know too much, and tend to go down paths that some newbies might
>not. In others, I am alot like other newbies... So solving some of these
>problems would reduce the inertial barriers to attracting new recruits.
>I posit that I am the kind of person you'd like to see using Debian, and
>that problems I have are the immediate kinds you'd like to fix (rather
>than catering to the completely unwashed user community, which while
>a laudable goal, involves alot more work indeed).
>And at this date, most people using woody are likely to be developers,
>and many/most of them will want/need 2.4, so I claim the upgrade path
>is going to be very common, even if stable is still 2.2 based; and given
>the date, alot of people will soon been following the upgrade path even
>after woody ships as the next stable. This is becoming the default in
>commercial distros, as 2.4 has (finally) mostly shaken down.
>This was my second Debian install (or third, if you count the fact that
>I screwed up my first so badly I started over), onto my laptop. I'll leave
>that tale to some other time.
>As I'm setting up to do some actual hacking on X, to teach it about the
>new input system, I needed to install a recent 2.4. Also experience has
>shown me over the years that having a journalling file system is *really*
>nice (having had one on Tru64 UNIX for many years), particularly when
>hacking on X servers, where you can do yourself in given the horrifying
>propensity for PC graphics hardware to hang your system buss...
>So I got the basic install done, and loaded a pile of packages (I'd kept
>a list of what I'd likely need from my previous install). Modulo the fact
>that the tasks are broken in tasksel, per previous discussion, things
>went ok, and, wonders upon wonders, I even ended up with a functional
>X/Gnome environment, including my USB mouse. Fixing tasksel in woody
>to load decent sets of packages would be a big help.
>So far, so good....
>I installed the 2.4.17 package, appropriately edited my lilo.conf
>(note that I think the message about what file to add in the package install
>to get the initrd is slightly broken; at least it was in my desktop install;
>would be even better if it added it itself).
>This went relatively smoothly (this time); the first time I had trouble
>with the name of the initrd file, as the kernel install script suggested
>a slightly broken name, and I didn't check the name of the initrd
>file first hand.
>But a number of problems remained, which could either be fixed by
>some pretty simple package changes, or by documenting a 2.4 upgrade
>in the installation directions:
>o gnome battery aplet is advising me the kernel may not have APM support.
>Is this true? Do I have to build a kernel to get it? This would be
>o the gdm in woody is very old; as I muck around in X server land, I
>appreciate some of its new features and regret its antiquity (and edit
>by hand), as recent versions allow me to edit what server gets started
>with what options, and I need to run a TinyX server; that is a different
>tale, and one I'll work on first hand).
>o My wireless card didn't work. Memory on previous 2.4 installs warned
>me about the transition to the ornioco driver, but of course, details
>are not in my cache. With alot of wandering around, figuring out the
>changes required to /etc/pcmcia/config for the orinoco was solved,
>along with the change needed to get the system to DHCP on the card.
>o The really obscure problem I could not have solved easily without
>Keith Packard's help was the need for the file /etc/default/pcmcia,
>with the line PCIC=yenta_socket. That one I would not have suceeded
>very soon at figuring out (as opposed to the orinoco driver, where
>I had some memory to help me look and had found it about the time
>I was bothering Keith last night).
>o to get ext3 to work on my root file system was another interesting
>diversion (beyond tune2fs -j). On my desktop, I had rebuilt the kernel
>and added support built in.
>On the laptop, Keith's suggestion was different: to add ext3 to my initrd.
>Using mkinitrd did the trick, and now my laptop is running ext3 on the
>root. It sure would be nice if the initrd that came with current 2.4's
>after 2.4.16 came with ext3 in it, or if the base system built ext3 in
>o someone, somewhere along the line installed gpm on me: this caused
>various trouble in my X hacking along the way.
>In general, gpm should *NOT* be the default (if you install an X desktop,
>anyway, which can be used as a signal you aren't likely to want cut and
>paste on the consoles). It only makes interactive behavior of the system
>worse by interposing a user process. With Keith's (relatively) new X
>scheduler in place, having a user process in the way makes for poorer
>interactive feel, particularly on a loaded system. In the short run as
>2.4 deploys, setting up the server to use /dev/input/mice is probably
>the right answer; in the longer run, I hope to move the X server over
>to /dev/input/event completely, and the entire mess will vanish (presuming
>we can get a line discipline in the kernel to handle PS/2 and serial mice
>someday for legacy boxes).
>Net result was a day or two of messing around that is preventable, by
>at most a few hours of writing documents, or a few days of messing with
>Still can't get sound out of xine, but that will wait for another day...
>(xmms is working fine).
>Hope this experience helps.
> - Jim
>Cambridge Research Laboratory
*** Your message did not reach its recipient ***
It was caught by the mailing system as spam.
If this message is not spam and you feel that
this message was caught in error, please email
a note to firstname.lastname@example.org.
If this message is spam, knock it off!
This server is in California where it is illegal
to spam! We do not accept spam here!
We will go after all spammers to the maximum
extent of the law!