[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installation report on AMD Duron system



On Wed, 29 May 2002, Joey Hess wrote:

> Date: Wed, 29 May 2002 00:29:41 -0400
> From: Joey Hess <joey@kitenet.net>
> To: "Paul L. Rogers" <rogerspl@datasync.com>
> Cc: debian-testing@lists.debian.org, branden@debian.org
> Subject: Re: Installation report on AMD Duron system
> 
> Thanks for the detailed report.
> 
> Paul L. Rogers wrote:
> >  o Since this is a X window system/desktop environment
> >    install I would expect installation to complete with
> >    starting gdm/kdm/xdm.  Perhaps a note should be added to
> >    the "Have fun!" message suggesting a reboot or how to
> >    manually get the system into the same state as a reboot
> >    would.
> 
> Branden, what should I do here? Is there some reason xdm's postinst
> doesn't start xdm?

I was thinking of someone who is not familiar with Debian being
left with the impression that all they could do was login at a
virtual console.  I haven't dug into the details of the
installation scripts, but perhaps the "Have fun!" screen
could offer dropping into a virtual console as it does now or
starting the display manager of choice.

> >  o It appears that support for the RealTek RTL-8139 PCI
> >    Fast Ethernet Adapter is compiled into the installation
> >    kernel (vmlinuz-2.4.18-bf2.4).  The card was detected
> >    and configured with no problems.  However after
> >    installing a new kernel (vmlinuz-2.4.18-k7) in an
> >    attempt to resolve the framebuffer issue, support for
> >    the 8139 card is via a module (8139too) which was not
> >    installed during the boot process.  What other drivers
> >    are compiled into the "boot floppies" kernel that are
> >    not present in the "standard" kernel images? This
> >    behavior is not very user friendly.
> 
> You can copy the /boot/config-2.4.18-bf2.4 file to .config in your
> source tree to start at the same place as the shipped kernel.

Agreed, but my gut feel is that most folks don't compile their
own kernels and depend on the kernel-image* packages.  I could
be wrong though.  However, if this is correct, these are the
very users who aren't going to have a clue what happened to
them, other than an upgrade broke their once working system.

> >  o The "rec" command from the sox package is broken.  "rec
> >    x.au" results in "sox: Unknown output file format for
> >    '': Filetype was not specified".  Shouldn't packages
> >    that are installed by default work?  I ran into this one
> >    a while back upgrading another box that used "rec" as
> >    part of a real application.  See Debian Bug #143262
> >    <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=143262&repeatmerged=yes>.
> >    It appears to be fixed in unstable, will the fixed
> >    package make it into Woody?
> 
> Nope, it's too late for this kind of thing to go in.

OK, but it's know of unfortunate that something that has been
working fine for a couple of years will be broken in the new
stable distribution.  I'm sorry that I didn't catch it sooner
(I've been trying to stay up to date with testing for a while),
but if I remember correctly there was a period of about a month
or so where I didn't use the rec command and by the time that I
noticed, the bug had already been reported.

[snip]

> We have talked about it, but are the isdn packages causing you
> particular greif, or just eating hard drive space? The next release
> after woody will allow drilling down into tasks and fiddling with
> individual packages.

I'm just lazy.  I've run through quite a few installs lately and
got tired of looking at the ISDN related stuff since it doesn't
apply to me.  My thinking was that those who have ISDN would know
that they needed to select the ISDN task, where those who haven't
even heard of ISDN wouldn't be burdened with having to configure
something that they would never use.   

> >  o The partimage-server package will not install properly.
> >    See the transcript below.
> 
> Please file a bug on this.

Someone else already has and it looks like it's fixed in unstable.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=145562&repeatmerged=yes>.

> >  o It's too easy to exit tasksel with no obvious way to go
> >    back.
> 
> This is already addressed in unstable, it loops until you tell it you're
> done.

Good.

Once again, I really appreciate everything that you, Branden and the rest
of the Debian developers have done.

> -- 
> see shy jo


-- 
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: