Joey, could you consider moving tasksel to alioth and thus give
translators CVS write access?
I've game for it if Randolph Chung is.
sure.
randolph
pgp0.pgp
Description: PGP signature
Karl,
What web server (and version) are you using?
the range header is a http1.1 extension iirc. the fetch code probably needs
to do a bit more careful checking of the result code from the server prior
to appending results to the file. i'll try to get this fixed later this week
unless someone
You may want to try the potato (2.2) boot-floppies. Try the idepci flavor.
randolph
In reference to a message from [EMAIL PROTECTED], dated Jun 25:
Package: boot-floppies
version: 2.1
architecture: i386
model: IBM
memory: 96MB
SCSI: none
CD-ROM: Hitachi DVD-ROM GD-2500 (IDE)
Problem is, having downoaded the rescue disk, when I boot that I get the
same problem just after the VFS tries to load up the root filesystem.
from where did you download the rescue disks?
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to
With the images at the above location (dated Jun 29 18:30) the following
message appears numerous times before dbootstrap begins:
modprobe: modprobe: Can't open dependencies file /lib/modules/2.2.17/modules.dep (No
such file or directory)
followed by
kmod: runaway modprobe loop
Niccolo,
As the de facto package maintainer I will be the first to admit that the
status of the module messages is totally ridiculous. As you pointed out
there are many inaccuracies and omissions.
Some time late last year we looked into revamping the modconf system
completely, however, because
sent to me privately
- Forwarded message from Niccolo Rigacci [EMAIL PROTECTED] -
Date: Sun, 02 Jul 2000 09:15:08 +0200
From: "Niccolo Rigacci" [EMAIL PROTECTED]
To: "Randolph Chung" [EMAIL PROTECTED]
Subject: Re: Bug#66578: Module descriptions in modconf
Niccolo,
please keep the cc line (to bugs.debian.org) so that we can keep track of
this in the BTS.
I'd like to release something better, but we are in freeze. Do
you think we can add some files to the package? I mean a README
with some guidelines like that:
oh, i thought this was already
ok, some good news and some good news ...
I am rather concerned about the modprobe reports posted to the list earlier.
[ the gist of it is this message, on startup: ]
modprobe: modprobe: Can't open dependencies file /lib/modules/2.2.17/modules.dep
(No such file or directory)
i was
Speaking of modprobe...
Is the "Note: /etc/modules.conf is more recent than
/lib/modules/2.2.15/modules.dep" warning still present in modconf? If
so, perhaps we should work around it; it's annoying.
I didn't see it when i did the install this morning.
randolph
--
Debian Developer [EMAIL
# RC bugs
#64371: Smart Array RAID Compaq do not see at boot; 44 days old
severity 64371 normal
#64823: incorrect LILO automatic placement on i386; 35 days old
severity 64371 normal
#65515: boot-floppies: update-modules requires /bin/bash; 20 days old
# will be fixed with upcoming b-f
I'm only guessing here since I haven't looked at the src, but I've
noticed a couple of times that if the fetch of base fails and then
you retry, it seems as tho the install doesn't overwrite the failed
fetch but actually appends to it. It's not consistent but it gives
Indeed netfetch will
In reference to a message from Aaron Brashears, dated Jul 26:
Package: Modconf
Version: 0.2.26.14
When I attempt to invoke modconf from a console, it doesn't start. There
is no error message. Here's a transcript of what happens:
# modconf
#
please try running modconf as
bash
I grepped in Contents-i386 for "/usr/lib/sgml/declaration/debiandoc.decl"
and found nil.
I'm wondering what I need to do with my system to get a working build
environment again.
I do have task-debian-devel and suggests installed.
gandalf[22:07] % dpkg -S
I boot from a 2.2.17-compact boot disk and use the standard root disk.
^^^
There is a root disk that goes with the compact boot disk. Are you
saying you didn't use that?
randolph
--
To UNSUBSCRIBE, email to [EMAIL
Not sure if this may help you guys, but modutils 2.3.13 supports
compressed objects. Might help shave a couple of bytes of the size
of a ramdisk..
well, it's already stored in a compressed format on the floppy
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
PGP
But they're extracted and copied to a ramdisk at the moment, right?
no, they are extracted into /target (your target /)
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
PGP signature
In reference to a message from bug1, dated Aug 17:
the udma disks spew up heaps of modprobe errors, cant open dependencies
file /lib/modules/2.2.17-ide/modules.dep
the directory created is /lib/modules/2.2.17/
This is pretty serious, stops modules being configured
are you using
We wanted to freeze potato last year but had no working boot-floppies
handy. Only very few people have worked on it.
Since then development was very slow, people dropped away, Enrique,
Erik. Left over are only a couple of people who contribute code.
Actually, the cvs log shows a lot of
I know there are still plenty of video cards that xviddetect does not
detect. I can see a lot of bug reports to that effect.
I think it would be worthwhile to maintain a branch of xviddetect so
that anXious could know about more videocards which get updated at
Potato point releases. Do
Depends should be doable without doing a whole dependency tree checking
thing. I'm thinking that when microdpkg is told to install a set of
debs, it can simply update its in-core status data to reflect all of them
being installed, and then iterate through each and make sure each would
then
How would you actually handle those dependencies though? Presumably you
don't have a udselect that'll automatically find any debs that anything
depends on, nor a uapt to do just automatically install them; you don't
guarantee any ordering so running udpkg -i foo.deb bar.deb won't bother
[EMAIL PROTECTED]
CVSROOT:/cvs/debian-boot
Module name:debian-installer
Repository: debian-installer/tools/
Changes by: tausq@va. 00/08/23 23:21:55
debian-installer/tools
Update of /cvs/debian-boot/debian-installer/tools
In directory
It looks like we should probably get further along on the redesign
so we can begin to get some better idea of what udpkg needs to be able
to do. Maybe we don't need dependencies. Maybe we do.
(FWIW, Randolph is working on some 9 or 10k udpkg that does support
deps.)
I just checked
i checked in another chunk of udpkg code just now. it unpacks the .deb
and writes the /var/lib/dpkg/info entries properly now. i am using the
popen hack i described in a previous post for now. hopefully we can
integrate this into busybox and use that instead at some point.
next steps are
Im getting bogged down with forks and IPC with the C based debconf stuff
i was attempting, i might have a quick look now.
Glenn, is your code available some place?
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Whee, I just made it through the entire thread!! :-) Some comments:
1) hardware detection
Libraries... libdetect is the big one. When it was first started I had looked
at it and thought (IMHO only) it was a mess, but since then it seems to have
improved significantly. it is reasonably modular
Because the data is not quite static. Any config-script and perhaps the
install program may choose it's own sequence of questions. And the
installer may ask variable questions. ( In the menu for example).
So I think there should be the internal database in mDebConf. An the conf
scripts can
Here's a bit of code that doesn't do anything useful yet, but illustrate
some ideas about how a C-implementation of debconf may be built:
http://auric.debian.org/~tausq/cdebconf-0.10.tgz
The basic idea is to have a pluggable architecture where frontend and
database modules can be
In reference to a message from Will Lowe, dated Oct 03:
I've put together (from pciutils and Redhat's anaconda) a small program
that asks the kernel about devices on the PCI bus and loads (or lists )the
needed driver modules. This hopefully enables NIC autodetection for
anyone who's using a
While you're at it -- perhaps you could try to come up with some
patches against xviddetect so it knows about more cards? It really
only knows pathetically few right now. See the bugs against that
package too.
woah if you want to add more things to xviddetect, file bugs or
email me.
In reference to a message from Glenn McGrath, dated Oct 05:
Attached is a little shell script i wrote that does most of what the
real dpkg-deb does.
very cool!
a few questions:
what's control and nl? does it work with busybox?
can you check this into cvs some place? :-)
randolph
--
Debian
For the installer we could share information of detected hardware via
debconf, but i guess it should be stored on the filesystem somewhere.
Where in the filesystem should hardware detection information be stored
?
/var/state/hardware perhaps?
randolph
--
Debian Developer [EMAIL
nl is from textutils, it isnt in busybox, but it wouldnt be hard to do
all it does is number the text lines so head and tail work, there is
ah, you can also do cat file | grep -n "" -
I dont have cvs upload access at debian, i could upload it to busybox's
cvs if Erik wants it.
oh, i'm
Why curses? Aren't we sticking with slang's pic library?
when i brought this up joeyh suggested that i stick with the subset of
curses that is supported by slang (slcurses.h) so that we have the
flexibility to use either... that's still the plan, although if it's
easier to do "real slang" we
I never thought we'd be able to fit *all* the nic drivers in the kernel.
The nic drivers supported by the potato compact floppies seems like a good
start. (Can you check how bug that set is?)
compact has a lot of net drivers built as modules actually. the built in
ones are:
3c905 (Vortex)
even if this can only be done with a special kernel, what's wrong with
probing the monitor. I am new to the list, so i don't know if the your
installer will install X at boottime, which I highly recommend. Most users
from Windos haven't seen the DOS-Prompt before, and having to use the
It's be easier to contact them if you gave their e-mail wink
Anyhow, Aj and Randolph: please feel free to contact me. I've some
curses experience (wrote a few curses program, wrote a curses article
on www.iglu.org.il).
[EMAIL PROTECTED] for me, and [EMAIL PROTECTED] for AJ.
check out the
- http retreiver [UNCLAMED]
Not started. Download udebs, other files from network.
I claim this one as well. This will be based on busybox wget. I presume we
will also need support for other types of retrievers? ftp? cdrom? nfsmount?
mounted filesystem?
joey's
For example, (I'll pick on tausq since he is in the boot-floppies passwd file)
for tausq, there is an entry in passwd, which is being mapped to aph. But tausq
actually this is a bad example. i was added to the passwd file by one of
the debian admins because i was having issues with ssh one
In reference to a message from Glenn McGrath, dated Nov 18:
cdebconf will be a core component of the woody installer, and if
cdebconf works the same way as debconf then it needs shell scripts to
work from.
So the way it is looking we will need a shell to be a core component
wont we ?
Yes.
Well, my personal opinion (and I have stated it several times in the
past few months) is that whenever the kernel version is updated, the
PCMCIA packages should be updated to the LATEST version also. After
all, it is only fair. I don't want to deal with bug reports swarming
in that "PCMCIA
Ive been working on a uapt-get.
Currently status is that it can process //etc/apt/source.list and fetch
the Packages.gz and Source.gz files by calling wget, then to merge the
package files i am calling "dpkg --merge-avail package name" to
generate a correct //var/lib/dpkg/available file.
I was wondering if anyone is interested in arranging a time to hold a
debian-installer design brainstorming session or such on irc
(#debian-boot on irc.debian.org). If we do something like Dec12 midnight UTC
will people find this useful?
randolph
--
Debian Developer [EMAIL PROTECTED]
In reference to a message from Randolph Chung, dated Nov 27:
I was wondering if anyone is interested in arranging a time to hold a
debian-installer design brainstorming session or such on irc
(#debian-boot on irc.debian.org). If we do something like Dec12 midnight UTC
will people find
listmaster -
this guy keeps on forwarding mails back to the list for no apparent
reason. can you take him off the list?
thx
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
- Forwarded message from [EMAIL PROTECTED] -
Date: Sat, 2 Dec 2000 22:28:18 -0500 (EST)
No -- I'm not saying that we create a new task package. I am merely
saying that tasksel should have a selectable item on the list which is
*not* from a task package, representing the packages at the standard
priority.
*grumble*, IMO this is much easier done in base-config
randolph
--
the very short version of the above:
If the installer could read scripted responses from a text file rather
than stdin, wonderful things could happen :)
debian-installer will be able to do this pretty trivially, if we do
things right. but since woody will likely release with the "old"
This isn't really a boot-flopppies bug I think. Nor does it seem to
be a kernel problem. Is it a modconf bug? A modutils bug?
It's not a modconf bug, if you modprobe lp from the command line it
doesn't bring in parport_pc either.
randolph
--
Debian Developer [EMAIL PROTECTED]
In reference to a message from Joey Hess, dated Dec 07:
Here is another debian-installer demo system. It still needs a real
debian system and doesn't chroot, nor does it even use cdebconf although
it probably could. But it is rather more impressive than the last one:
Here's the cdebconf
Since there are a few copies of debconf.[ch] appearing in
debian-installer cvs, i've added debconf-client support code to
libdebconf (cdebconf) so we don't duplicate it too much.
the API is pretty simple:
#include debconfclient.h
struct debconfclient *client = debconfclient_new();
Bah, I read my calendar wrong... I had meant to say midnight UTC between
Dec 9 and 10. (i.e. a weekend night)
would that work?
for those who can't attend, we will make transcripts available.
Just a reminder that this is going to happen today in about an hour, if enough
people show up.
In reference to a message from David Whedon, dated Dec 10:
This is an unrelated patch to debconfclient.c. I don't know if people
will like it, or if it just makes code harder to read. The idea is that we
don't want to take up a lot of space with "INPUT", "GET" in a bunch of places
all
Any prefered naming scheme in use then?
busybox-udeb.*.udeb?
Well that mirrors what tausq did with cdebconf anyway.
which i copied from busybox cvs :-)
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
In reference to a message from David Whedon, dated Dec 16:
If the user wants to go through the network configuration a second time (they
mistyped something) , I'd like to have the default set to their previous
answer, and I'd like it to be obvious that the defaults are such.
I can't
I'm curious... why was `ncurses' chosen over Slang for this? I
thought that the reason Slang had been used for the boot-floppies
`dinstall' was that it's a smaller library than `ncurses'. Or, does
it turn out that an `ncurses' subset is smaller or is just easier to
program and more
Hmmm... with a jumpstart floppy, a menu of standard install types
gotten from a spot on the CD and/or tftp/ftp/http server, AND a tool
to create those config data files? It ought to allow creation of
several (possibly related and mostly identical) configurations. When
it starts, you'd
Added files:
tools/cdebconf/doc: TODO
Log message:
Some things that need to be done...
I'm hoping people here will help with some of these tasks :-)
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Is there a particular coding style which people prefer?
I'd say it depends on the module you are working on. Just stay
consistent with the body of code you are working on.
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
This should be fixed in CVS, it was the debconf.conf using relative
paths.
Problem now is that once started it loops displaying the headings over
and over, it doesnt seem to be displaying any options which is what
might be causeing it to loop, i will delve deeper.
Try deleting all your
In the end, I hope to have the whole system building using automake
and configure, so that one can create a custom installer by giving
various options to configure. :)
cdebconf already uses autoconf. i'd really prefer not to use automake if
we can. it adds way too much abstraction and in my
Looks like lots of interesting things happened to d-i over Christmas.
Very good job everyone!
I tried out Dan's bogl interface. Looks cool once we have the
"select" handler we can do dpkg-reconfigure debconf with cdebconf :-)
one thing i saw was that if the bogl interface segfaults (for
Is confmodule the same?
yes.
Do you need to use a file named frontend; nothing should refer to that..
frontend is a symlink to /usr/bin/debconf in cdebconf. the confmodule script
refers to it.
perhaps we can make a debconfapi package?
randolph
--
Debian Developer [EMAIL PROTECTED]
Perhaps moving the fb-based frontend bogl you speak of to gtk-fb
is the answer we're looking for? That'll give us access to all the
features of gtk, which IMHO would be a boon for the UI.
First I want to reiterate someone else's comment -- having a GUI (in the
sense you seem to be thinking)
(btw, I got a bounce message on your email address)
I agree with that. But there isn't any reason that this couldn't be
accomplished with a gtk-based interface.
of course...
And there are some merits to
using a widget set that more resembles modern computing interfaces,
so [n]curses,
In reference to a message from Joey Hess, dated Jan 10:
Anthony Towns wrote:
The debconf frontend should really be passed through to the udeb frontend;
the keymap should already have been determined.
Right. How we do that with dpkg and random postinst scripts scribbling
all over the
Busybox has some utils, all right, but what I mean is a set
of generic data structure stuff like lists, stacks, hash tables...
well, many linked list routines can be implemented in 3-4 lines of C, so
there is a very little benefit of using a library.
for binary trees and fast searches you can
We really need a cdebconf .udeb on the archive in the same place as all
the other udebs. Right now, the system that is built can be chrooted
into, but I cannot run main-menu or anything, since I am not installing
cdebconf.
i'll fix this rsn.
randolph
--
Debian Developer [EMAIL PROTECTED]
In reference to a message from Joey Hess, dated Jan 20:
Debian Boot CVS Master wrote:
Log message:
made the library reduction routine look at not just binaries, but also
shared objects to pull in library dependencies
The reason I didn't originally do that is pulling in all the different
I uploaded cdebconf, cdebconf-dev and cdebconf-udeb to ftp-master today.
They have been moved from experimental to unstable, so things should be
much happier. Because of the move, it's considered a "new" package, so
it may take a couple of days before it moves into the archive.
the cdebconf udeb
modconf has a number of bugs that require attention. If anyone has time
to look into getting it fixed, please do so. The package is owned by
[EMAIL PROTECTED], and sources are in debian-boot cvs.
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to
If I pick a random module from the kernel say drivers/net/eepro100.c in the
kernel source, I find this:
[..]
Can it be used in some way in modconf? Could we make use of the information
that appears in Documentation/Configure.help as well?
re: use info inside the source... unfortunately, this
Q1: is the one available from cvs
:pserver:[EMAIL PROTECTED]:/cvs/boot-floppies
going to be used for 2.2r3?
yes. it'll be tagged accordingly when it's ready for release.
Q2: what will woody be using?
boot-floppies, most likely.
Q3: how does debian-installer fit in? is this what
There are a lot of undertermined things like how flavors will be handled.
presumably they have different kernel version numbers (2.2.17-compact,
f.i.) so they'll just build into different packages right? although i
guess you need some kind of a "Provides" for the dependencies to work
out
Here is the main menu of the Debian installer.
1. Finish setting up the Debian installer
2. Configure a static network
Prompt: 1 - 2 2
Segmentation fault
make: *** [demo] Error 139
i've seen it do this when it can't find ifconfig, although when i tried
this it told me it couldn't find
add some comments, error checking, have the user confirm operations, still not
tested.
btw, when i tried this on my udma66 drive (/dev/hdg) it complains that
it doesn't recognize things any ideas?
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE,
I'd love to. There is one little problem. Or rather, there are several
little problems, specifically, alpha, hppa, m68k, mips, ppc, and sparc.
Busybox insmod requires a little bit of arch specific code for each
arch. So far, only x86, arm, and sh are supported. So if I turn it on,
I
Many people who work on boot-floppies have commented on the (unneeded)
complexity of the makefiles. I'd be willing to spend some time trying to
clean up the build system a bit. Is this a good time to do this? I'm
sure it'll take some time to iron out all the corner cases for a change
like this,
CVSROOT: /cvs/debian-boot
Module name: boot-floppies
Changes by: tausq 01/01/26 22:15:17
Modified files:
utilities/dbootstrap: bootconfig.c dbootstrap.h
select_not_mounted.c
Log message:
fixes to make dbootstrap work with newer compilers
Modified files:
utilities/dbootstrap: Tag: woody Makefile
utilities/dbootstrap/po: Tag: woody Makefile
Added files:
utilities/dbootstrap: Tag: woody Makefile.orig
Log message:
build system changes...
Makefile has the new build system with some cleanups
In reference to a message from Marcin Owsiany, dated Jan 28:
On Sun, Jan 28, 2001 at 01:39:53PM -0700, Randolph Chung wrote:
things like language-chooser, graphical dbootstrap, etc can be
controled via variables passed into make, which changes the relevant
CFLAGS/LIBS, instead of having
(pristine disto tasksel (no option)) + sendmail + bind - ppp = OK
Actualy, (base-config = tasksel) = "tasksel -riq"
= (tasksel | dpkg)
So it's some sort of arg interaction? Wierd. be sure you note this
ont he bug ...
ok, i'm very confused about
Randolph, can you explain what thisi s for, who might be using it?
I'm experimenting with better modconf support for woody b-f. On the road
right now; more details when I get back...
Excellent. I'd like to get some form of auto-PCI detection going in
woody.
modconf2 uses
libdetect. Someone KILL libdetect.
It has fledgling PPC support, but it's (A) hacked together awfully (B)
a little lacking in correctness (C) nowhere near compiling. I got it
to build once, with two hours work, but not function.
hmm.. drow, I'd like to talk to you about this more... am
Wouldn't it be good to separate udpkg data from dpkg data? So even if
a user uses it (he might want to) it wouldn't interfere with dpkg database?
well, udpkg is supposed to help bootstrap your system into a real
system. if it's messing up your status files, we should fix the problem
rather
I just commited it, this stops the status file getting corrupt on my
machine, much better than any of the patches i was thing of.
thanks for the fixes!
the uninstall (-r) code hasn't been tested much at all, so i'm not
surprised it doesn't work. let's fix it! :)
randolph
--
Debian Developer
Genn has merged it into the busybox CVS tree, but has some real concerns about
its functionality. I am trying to get BusyBox 0.50 released today (or possibly
tomorrow). Glenn thinks the problems are serious enough that he recommended
that it be disabled for the release. I have a few other
It will be much easier to maintain if it can be used outside the
installer.
What size are you prepared to pay if any for full support, if i could
get it down to 1 KB difference would that be ok ?
How about make it selectable at compile time via BB_FEATURE_FULL_DPKG
or some such?
what's the deal with these messages?
Checking in src/common.h;
/cvs/debian-boot/debian-installer/tools/cdebconf/src/common.h,v -- common.h
new revision: 1.13; previous revision: 1.12
done
2001-02-16 10:49:52 14Tpx2-00057r-00 Failed to find user "" from
expanded string "${lookup {${domain}:user}
* The system needs a great deal of polish. There are little things in
cdebconf like the way it doesn't tell what menu item is default, and
of course a slang or curses frontend would be flashier, but I'm really
talking more about polishing the flow from one bit to another, and the
In reference to a message from David Whedon, dated Feb 21:
I've been playing with devfs. I'm considering it on the install system for the
do things like libparted work with devfs?
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL
In reference to a message from David Whedon, dated Mar 03:
I just noticed who the maintainer is. I uploaded a fix, please pardon the extra
list traffic.
or you could do:
Index: modconf
===
RCS file:
- syslogd not working, maybe it is because /dev/log doesn't exist, I get tail:
/var/log/messages: No such file or directory I ctrl-C it a few times and try
manually starting syslogd, mkfifo /dev/log, eventually it works, not sure
what I actually needed to do.
hmm... /dev/log is not a
It still wouldn't work with ash. In fact, those two lines are exactly
the same in any POSIX shell.
Have you actually tried it? i did, and it works.
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
In reference to a message from David Whedon, dated Mar 17:
Are we using compact, idepci and udma66 flavours for i386 for 2.2r3?
If so we'll need kernel images built from 2.2.19pre17:
http://lists.debian.org/debian-boot-0103/msg00217.html
I can build them if necessary.
David, go for it...
The below problem is fixed. The only problem now is an aesthetic one. The
compact and idepci kernels attempt to draw a framebuffer penguin logo at boot.
The 2.2.19pre17 version has a messed up color map for me (I tried the
2.2.17-idepci kernel and the color map was fine, so I don't think my
Mailx does meet the criteria for important very well though.
Is there no way to have a package be priority important and skipped by
tasksel?
How about if we change the semantics of the -r and -i flags of tasksel
so that it only marks a package for install if it doesn't conflict with
a
(Not sure if one of these has been filed for ia64 yet, so here goes...)
INSTALL REPORT
Boot-Floppies: 3.x (2001-07-05; Richard's image on merulo built from CVS)
Architecture: ia64
Method: cd-rom install with rescue, root, drivers;
net install (http.us.debian.org) for base and standard
In reference to a message from Colin Watson, dated Sep 18:
Is it OK and/or welcome for random developers (specifically the
maintainer of the relevant package) to add a package to a task in
tasksel CVS? I've received a request for a package to include Japanese
support, which I would prefer to
BTW: libdetect0 has no udeb. ethdetect is uninstallable
are we still using libdetect? i was told that it is very i386 specific
and may not work well at all on other archs.
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
1 - 100 of 117 matches
Mail list logo
