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
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
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.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe
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.
i
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
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.tausq.org/
--
To UNSUBSCRIBE
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, hppa/ia64 ports
http
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
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
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
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
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
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.org/
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]
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
(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
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
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
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...
- 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 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:
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
* 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
(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}
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
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
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
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
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
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 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
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,
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]
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
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
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]
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
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
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
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 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
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 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();
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]
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)
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
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 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
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
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
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
- 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
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
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 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
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
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
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
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
[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
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
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
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
1 - 100 of 117 matches
Mail list logo
