> Please reply to the debian-boot mailing list (reply-to is set). If we do not
> receive a reply within the next two weeks, we'll proceed with the removal.
Please go ahead and remove me, and thanks for your work on D-I :)
randolph
signature.asc
Description: Digital signature
Nobel,
We tried as your recommendation which was removing SCSI_PPA in our config.
But we still have the similiar problem which has the similiar message, not the
same exaclty.
James Bottomley pointed out that the imm driver is also broken on
parisc. Can you try a standard config on your machi
ot
needed and causes all sorts of problems.
thanks,
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > 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
out 'db_capb backup off'? The 'on' could be implicit in
> 'db_capb backup'.
sounds reasonable to me. can you also suggest this as a debconf spec
change on [EMAIL PROTECTED] ?
thanks,
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.
> I believe I fixed all resulting breakage a few days ago, with a global
> s/debconf_input/my_debconf_input/.
thanks richard, then i'm not going to touch them...
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sorry for the late reply, i was out of town for a few days.
> 1. The helper macros recently introduced do break several packages
> under debian-installer/tools/ which used to declare their own
> debconf_input function. Maybe we could remove these macros, I
> wonder whether they are that useful.
> Does it mean that cdebconf should not use the LANGUAGE environment variable
> at all? If not, what is the exact role of this variable and the debconf
> question?
well... i'm not clear on why we have LANGUAGE and don't use either
LC_MESSAGES or LC_ALL. Isn't that the standard way to define local
database,
and have a mechanism to trigger cdebconf to re-read the debconf database
(e.g. when getting a SIGHUP). i remember there were some discussions
along the same lines some time ago.
will that do what you want?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www
no effect.
> Exist a solution for this problem.
you need a newer kernel for this to work. search the mailing list at
parisc-linux.org or send mail to [EMAIL PROTECTED] if the
info on the website is not enough for you to get this going.
randolph
--
Randolph Chung
Debian GNU/Linux Developer,
> I've got a feeling that it would be nice just to upload first and coordinate
> later :P
>
> Uploading cdebconf (probably) doesn't break anything right now, does it?
it doesn't break anything, but it still leaves cdebconf more or less
useless :)
randolph
--
To UNSUBSCRIBE, email to [EMAIL
In reference to a message from Tollef Fog Heen, dated Aug 14:
>
> unless somebody has some big objections, I'll upload cdebconf 0.21
> tomorrow or so.
>
> tausq, it would be nice if you showed some life signs. :)
i'm alive but am very swamped at the moment. you need to coordinate with
joey hess
I've been getting some inquiries about what the plans are for cdebconf
moving forward. I thought I'd write down a few things I have in mind,
with the hope that other people can help contribute :-)
The goal here is that we can continue to use cdebconf as a small(er)
(size-wise) implementation of t
Just a heads up that I checked in a bunch of stuff to break cdebconf
today. I will be working on fixing things up gradually over the week,
but people are welcome to help :-)
if you need a working cdebconf, use a cvs checkout date of yesterday or
so.
randolph
--
To UNSUBSCRIBE, email to [EMAIL
> have you discussed this and come to a conclusion?
>
> if not, I'll just rename /usr/bin/debconf to /usr/bin/cdebconf for now
> and you should be able to make that conflict a versioned one.
i'll put it on the list of things i need to corner joeyh and discuss
during OLS :-)
randolph
--
To UN
> I've found /tasksel/po/ on cvs.debian.org (today it seems oddly
> slow) with a lot of .po, but no .pot at all! where is it?
what are .pot files for?
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
> can you send some lines about this. What languages need work?
all the ones are a bit out of date, so they all can use some work :)
> Can we translate the tasksel descriptions? Have tasksel support for
> this?
not right now.
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.
tasksel 1.12 was uploaded to the archive recently. It adds in almost all
of the translations that I've received to date (I missed the .fr one by
mistake; that will be added in the next release.)
There are currently no >severity normal bugs on tasksel. Here are some
notes on some of the remaining
> 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]
w
> - It checks dependencies (not sure if udpkg does this)
yes, udpkg has always done this. it also has optional dependency
ordering.
if the bb dpkg does the job better and smaller then let's go with that
instead of udpkg
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauS
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
(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
M
> 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 p
> AnXious doesn't have to go away, it can just stop sweating the X server
> issue.
anXious has been removed from woody for some time already. i thought
dexter already does everything that anXious did?
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
PGP signature
> 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
In reference to a message from David Whedon, dated Mar 27:
> I noticed that I should have built idepci and compact kernel flavors with
> gcc272. I didn't have it installed on the machine I built them on at the time.
> The pcmcia modules I just built I did use 272, that is why I noticed I had
> m
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 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 "uns
> - 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 no
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: /cvs/debian-boot/modconf/mod
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 PRO
> Totally broken! Try enable CosNaming service. Doing corba_text method.
> BTW, what's the difference between _text and _string?
you may want to read the debconf spec :)
string is one line, text is multiline.
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUB
In reference to a message from zhaoway, dated Feb 21:
> Hi, I'm doing a corba frontend for cdebconf. It's at the very, very
> begining. 0.0.0.0.1alpha0.0.0.1 I mean. ;-) Please, may I commit it to
> under d-i/tools/cdebconf/modules/frontend/corba ? Because, a) I hope
> to listen to others ideas wi
> * 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
>
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}
> > 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 s
> 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 oth
> 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 Develope
> 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 th
> 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...
> > > 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 use
> > (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 v
> > Log message:
> > Initial import of new modconf development branch
>
> 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...
randolph
--
Debian Developer <[EM
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
> >
> 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
>
> This is just moving stuff around, no substantive changes to the logic.
similar to what i plan to do on a first pass as well.
> Here are the logic changes I want to do:
>
> - all the arch-level stuff should be broken into make. files
yup, this is what i've done. so, f.i., all the evil flavo
> > Log message:
> > fixes to work with devfs
>
> Evil! Please do this stuff in the woody branch!
to clarify, the "fix" involves making some of the buffers used to read
device names (e.g. /dev/sda) bigger. (they are all PATH_MAX now instead
of some random number)
i can revert this and recommi
> 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 co
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, bu
> 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,
>
> 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 UNSUBSCRIB
> 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'
> > > 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 co
> 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 w
> 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, t
> What is the long term future with modconf, seems that the
> debian-installer, modconf and kernel-package are all pretty much
> intertwined.
First I want to clarify -- modconf has needs for potato (the point
releases) and woody (even if we don't have a d-i solution), so it
really needs attentio
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 t
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
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 d
> 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 PROTECTE
> 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 ca
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 t
(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,
> 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 thinkin
> 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]>
htt
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 exam
> 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
> - cdebconf: nothing (I think)
just /bin/sh ...
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [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 yo
> 1. It's been stuck in incoming all week. Why?
i have it set to experimental for now.
> 2. Look at this pretty failure mode. Looks like it
>doesn't work if not run in / -- should be easy to fix of course.
> # pwd
> /usr/lib/debian-installer/retriever
> # /usr/share/debconf/front
> 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]
w
> 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 s
In reference to a message from David Whedon, dated Dec 17:
> I made udebs of dhcpcd (turns out to be smaller than pump, and I've heard is
> better behaved), pump and ppp. If anyone wants to play with them, (or critisize
> them in case I made an error) the patches can be found at bugs #79841 (pump
> 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, y
> 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 mor
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 f
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 f
> > 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
> Make sure this works for unattended installations :)
this is definitely on my list of things to test.
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> tools/cdebconf/src: debug.c debug.h
a word on this, for people who are playing with cdebconf:
cdebconf now recognizes the DEBCONF_DEBUG environment variable. Unlike
the perl version this one is numeric, see common.h for some debug levels
(the INFO_* #define's).
Turning it up to 5 or m
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 ar
> The problem with the old way is that the STRDUP() macro expands to make two
> calls to strtok(), first to make sure the return value !=NULL, and then again to
> try and duplicate the sring. The second call to strtok() returns something
> different than the first call, and we fail.
>
> It's pos
Package: ash
Severity: wishlist
Version: 0.3.7
Herbert, as you may have heard, debian-installer uses udeb packages to
create the initial boot system. Here's a patch that allows ash to build
.udeb packages.
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
diff -uNr ash-0.
> 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
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
struct debconfclient *client = debconfclient_new();
client->command(client, "INP
> Hmm. Is that stripped?
Yeah, but most of the size is actually due to various small files and
directories, and the 4k block size on my ext2 fs. if you look at the
tarballs (uncompressed) it's actually only about 70k.
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
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 ver
> It's not a modconf bug, if you modprobe lp from the command line it
> doesn't bring in parport_pc either.
Ok, nevermind, ignore me
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troub
> * joey@gumdrop:~>busybox wget -c http://slashdot.org/
> wget: cannot parse url: slashdot.orgdot.org
> (No comment ;-)
Fixed in busybox cvs.
> * -O - does not cause it to output to stdout. Of course, if it *did*,
> the progress display would need to be turned off or go to stde
> 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]>
http://ww
> 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"
bo
> This can really be read two ways; either standard is selected if you pick
> nothing else and deselected if you pick anything, or it is selected and
> anything else you pick layers on top. Since the second is dselect's behavior,
> I suspect the second meaning is the intended one.
My concern is
> 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
-
> Oh no, it's the "should tasksel autoselect standard" question again. We
> had a talk about this last spring, and probably chose wrong.
>
> I've just uploaded to unstable a base-config that calls tasksel -s.
> Problem solved.
Hrm there are currently 90 "standard" packages in woody that add
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)
F
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
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]>
http://ww
> 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 " to
> generate a correct //var/lib/dpkg/available file.
Glenn,
> tasq says udebconf needs a shell, what specifically ?
^u :-)
we need "glue" that invokes the various components. This doesn't
necessarily need to be shell i guess... (the counterpart to
/usr/share/debconf/* in perl-debconf)
also config scripts may be shell
note that cdebconf as currently
> 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 "PC
1 - 100 of 167 matches
Mail list logo
