Re: Removal from Uploaders fields for Debian Installer
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
Re: [parisc-linux] Fw: HPMC in ppa_init()
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 machine, such as the b180 config? The problem is that many of these drivers are written with x86 hardware in mind and do not work correctly on other architectures. You can try copying arch/parisc/configs/b180_defconfig to your .config and start from there, or download a prebuilt kernel from http://cvs.parisc-linux.org/download/linux-2.6/ Let us know how that goes. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#282851: hppa d-i install report
Package: installation-reports INSTALL REPORT Debian-installer-version: http://people.debian.org/~jbailey/d-i/hppa/2004-11-24/2.6/mini.iso uname -a: Linux legolas 2.6.8-1-32-smp #1 SMP Tue Nov 2 13:07:05 MST 2004 parisc GNU/Linux Date: Wed, 24 Nov 2004 14:38:07 -0800 Method: Network install from ftp.us.debian.org, no proxy Machine: HP PA-RISC J6000 workstation Processor: 2x552MHz PA8600 Memory: 4GB Root Device: SCSI (Quantum Atlas 10k 18G LVD) Root Size/partition table: Device Boot Start End Blocks Id System /dev/sda1 1 33 33776 f0 Linux/PA-RISC boot /dev/sda2 34 157 126976 83 Linux /dev/sda3 158 1736617622016f W95 Ext'd (LBA) /dev/sda5 * 158 1670116941040 83 Linux /dev/sda6 16702 17366 680944 82 Linux swap sda2 is /boot, sda5 is / Output of lspci and lspci -n: legolas:~# lspci :00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) :00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip :00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE (rev 03) :00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev 01) :00:0e.2 USB Controller: National Semiconductor Corporation USB Controller (rev 02) :00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :00:0f.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :01:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) :02:02.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) legolas:~# lspci -n :00:0c.0 0200: 1011:0019 (rev 41) :00:0d.0 0401: 11d4:1889 :00:0e.0 0101: 100b:0002 (rev 03) :00:0e.1 0680: 100b:000e (rev 01) :00:0e.2 0c03: 100b:0012 (rev 02) :00:0f.0 0100: 1000:000b (rev 04) :00:0f.1 0100: 1000:000b (rev 04) :01:01.0 0200: 14e4:1645 (rev 15) :02:02.0 0380: 103c:1005 (rev 03) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] Config network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [E] Comments/Problems: i cannot use the 2.4 image as the kernel is too old to boot on my test machine. The last image i tried was the Nov 11 snapshot. That one did not work for me at all. This one was much better. A few glitches - i am doing a net install, but the default kernel had no driver for the tulip card that is common to almost all hppa systems. It did find the tg3 addon card that i had in the system and i was able to use it to do the install. After reboot, the system did not come up automatically. This seems to be because the initrd parameter was missing from the palo command line installed by the installer. If i manually add initrd=2/initrd.img, then the system boots up fine. doing task installation it complained about not being able to install some packages. i think it is the kernel-image package that it was complaining about.. there was also a message about not being able to install read-edid, altho that didn't seem to cause any problems. oh, and please remove saveserial from the hppa package list. it's not 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]
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
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
Re: Turning off backup
In reference to a message from Petter Reinholdtsen, dated Mar 10: [Martin Sj?gren] What's the best interface for this? Three suggestions (in order of preference): db_capb nobackup db_capb -backup db_nocapb backup What about '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.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [cdebconf] helper macros, i18n, backup, etc
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]
Re: [cdebconf] helper macros, i18n, backup, etc
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 thought you asked for them? :-) unless i hear otherwise i'll commit a patch tomorrow to wrap them inside a #ifdef WITH_DEBCONF_HELPER_MACROS or something like that. 2. The attached backup.patch finishes support for backing up. As it slightly changes cdebconf interface, I prefer sending it there. looks ok in general, but perhaps you can add an enum for the -1, 0, 1 stuff instead of using a number? thanks! this is a long-needed bugfix. 3. May I set a _ macro in frontend.h in order to start i18n of frontends? As libdiscover already calls dcgettext, I would like to set it to #define _(x) dcgettext(cdebconf, (x), LC_MESSAGES) sounds fine to me 4. As esplained in #172218, current TITLE command is not l10n-friendly. I will wait for Joey's solution before changing this in cdebconf, but the new progress bar support suffers from the same problem. hrm, i see making it a template seems like a reasonable thing to do... btw, someone (waldi, I think) asked for debconf-communicate support in cdebconf. i hacked up something while i was on the plane a few days ago and it's now in cvs. seems to work, but yell if it breaks stuff. right now it's built for both deb and udeb. If this becomes a size problem we can always remove it from the udeb. btw2, we should really not have this piece of code in debconf.c: q = questions-methods.get(questions, debian-installer/language); can this be just debconf/language instead? putting cdebconf in debian-installer cvs was more of a convenience. cdebconf is not meant to be a debian-installer-specific application. btw3, istr some talk about implementing a http based db backend. is that available some place? sorry if i missed this on the list, i haven't been following d-boot too closely. thanks, randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Language selection: cdebconf and main-menu
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 locales? instead of using getenv(LANGUAGE) we could use setlocale(3) actually i don't mind using an environment variable for this purpose, I'm just not comfortable with adding random debconf commands to cdebconf if we can avoid it. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Language selection: cdebconf and main-menu
* In cdebconf, implement this new X_SET_LANGUAGE command.
Note that the language list is hardcoded in main-menu/language.c and not
in languagechooser/debian/{postinst,templates}. In fact, as language
selection is driven by main-menu, I suggest not to add the languagechooser
package and instead add its template under main-menu wings.
why do we need to implement a special command to do this?
this command is non-standard (not in the debconf spec)... this seems
very much like a hack to me.
I'd rather have the language setting be read from the debconf 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.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#161284: woody + hp9000 installation problem
Branching to kernel enty point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org Search there was not sucessfull. Changig terminal type by PALO takes 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, hppa/ia64 ports http://www.tausq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf upload
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 PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf upload
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 before you upload the new cdebconf. we need debconf to move to the new debconf-api dependency as well. randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cdebconf plans
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 the debconf protocol for debian-installer; at the same time, cdebconf will be a full-implementation of the debconf spec that will allow you to use cdebconf as a complete replacement of the perl implementation of debconf if you so desire. Towards these objectives, I have commited some changes over the last few days to address some of the main differences that remain between debconf and cdebconf. Since the last significant changes were committed to cdebconf several months ago, Joey has made some significant enhancements to debconf and cdebconf was lagging behind. The main changes I have made after talking to Joey at OLS was to separate out the concept of a template database vs a config database (cdebconf calls the latter a question database). These used to be a single database entity in cdebconf. Just as in perl-debconf, there is a configuration file that allows you to choose where the template/question databases are stored, and which driver is used to store the template/config data. The second major change I am working on is to introduce the idea of instances in cdebconf. By this I mean that (as in perl-debconf) you can have multiple databases (or frontends, for that matter) defined for use, and these can be stacked together to form a database chain. For example, in the default perl-debconf config, the configuration database is split into a password database which is stored in a read-only file, whereas the rest of the data is globally readable. To do this in cdebconf, you would instantiate two instances with the rfc822db driver (originally written by Tollef Fog Heen) which defines the database file locations, etc. Then you can define a third instance using a stack module (to be written) that links them together. If this is not clear, you may wish to consult either the perl-debconf documentation on how the Stack module works. The third area I plan to work on is to improve the documentation for cdebconf, both in terms of internal code documentation and documentation of the public APIs that module developers can use to develop new frontend/database modules. Some of this work was started by Moshe Zadka already. What I am considering to do is to use doxygen to have in-code comments that can be processed to give an easily-accessible API documentation. Last but not least, Tollef has done some i18nization work on cdebconf. Right now the mechanism is not very clean; we are working out ways to improve i18n support in cdebconf. In parallel, Joey and I will be working on trying to clarify some items that have become a de-facto standard in how debconf works based on Joey's implementation, but are not specified formally in the official specification. It is my hope that cdebconf will continue to support the small size footprint required for d-i, but at the same time be suitable as a full-fledged implementation of the debconf-spec that can be used on typical Debian installations. Most of the enhancements will happen in loadable modules (e.g. ldap backends, etc). At the same time I would like to make sure whatever we do is compatible with Joey's debconf implementation. So, in short, volunteers are sought to help write documentation, loadable frontend and database modules, and of course help test cdebconf. One of the things Joey and I discussed was the need to come up with a testsuite that can be used to verify compliance with the debconf-spec. This will be an interesting and independent project someone can work on (hint hint) :-) Comments, criticisms, patches, feature suggestions, etc are always appreciated. Especially patches! randolph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cdebconf
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 PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i]: cdebconf safe to install? (newbie question)
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 UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tasksel.pot?!
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 unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tasksel bug-scrub for woody; translations; plans for 1.13
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 bugs: Normal severity: 109938: - isdn task: doesn't exist anymore? - devel in C++ is duplicated (development and misc) -- i have no idea what this is supposed to mean - non-interactive mode has always been available, so the third point is not really valid I am tempted to close this bug unless there are any objections. 114721: this is the tasksel needing 'dselect update' mess the currently suggested option is to have tasksel always do (in effect) system(dselect update) on startup. Is that a reasonable workaround until apt knows more about tasks and we can do this more sanely? will go in 1.13 unless i hear otherwise. 116302: tagged wontfix, though it doesn't show up for some reason... that problem is because of how apt works. nothing we can do 116609: shouldn't a generic X installation pull in a window manage (ok, so it's twm, but still...) Not sure we should really put a window manager into the gnome task. but i'm open to suggestions. Wishlist severity: 72972: fixed in local tree, will be in 1.13 79212: won't be done for woody. hopefully by woody+1 we'll have a better system 108061: java doesn't work on many of the debian architectures yet, so i'd rather not do this for now. any other existing bugs not addressed in this email will not be fixed for woody. the only other pending issue i know of for tasksel is the suggestion for a ocaml task. the requestor has yet to file a bug on this though. If people are interested in updating the tasksel translations now would be a good time as well. Either check them into cvs directly or mail the .po's to me. There should not be any more text changes. The procedure to use for this is to go into the po directory, do 'make C.po', copy C.po to your locale.po and update the msgstr entries. The next tasksel upload will happen around Nov 25 (PST) to meet aj's base/task freeze. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tasksel bug-scrub for woody; translations; plans for 1.13
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/ msg12591/pgp0.pgp Description: PGP signature
Re: debian-installer status
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] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Editing tasks
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 fix by adding a related package to the japanese task. Fine by me; please do send a note about changes you make to this list though. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Install Report (b-f 3.x ia64; cdrom/net; standard)
(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 Machine: HP i2000 Workstation Processor: 2x800MHz Itanium Memory: 2G Root Device: SCSI (sda) Root Size: sda1 (8G) Base System Installation Checklist: Boot Complete [X] Keyboard Config[X] Create Partitions [X] Install kernel [X] Install drivers[X] Config drivers [ ] Config Network [X] Install Base [X] Config Base[X] Create boot disk [ ] Reboot [X] Comments/Problems: STANDARD SYSTEM INSTALLATION Installation process: HTTP Package Choice: tasksel Everything more or less worked; one glitch is that I had configured static network support, but after the reboot a dhcp client started up and overwrote my static IP and DNS settings. Installation experience: Fairly smooth install... should be ready for end-user. The CD-ROM image I downloaded does not autoboot, but included clear instructions on how to start the installer. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ PGP signature
Re: configuration of base packages
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 package already marked for installation. This will require that we track Provides and Conflicts in tasksel tho... randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: still not out of the woods with idepci / compact kernels
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 hardware is the problem) the colormap flashing is a known problem, it has to do with how the console is initialized. i'm not sure why you didn't see it with 2.2.17idepci, i've seen with every compact/idepci kernel i've built. I'd like to either fix the color map or remove the logo. I think I know how to remove the logo, I haven't figured out how to fix the color map. I did a variety of diffs between 2.2.17 and 2.2.19 and nothing has come to me. if this can be turned off without a patch, go ahead. i thought the logo is included automatically if you have fb support turned on. At this point I'll just remove the logo unless someone speaks up that they really want it, or that they know what the problem is. 2.2.19 is out and packaged, can you look into packaging that? i'm going to be moving fairly soon so i probably won't be able to get to this for a couple of weeks at least. thanks, randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel for woody
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... I was hoping to do those this weekend but have some other things i need to finish up first. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to boot-floppies by dwhedon
- 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 fifo, it's a unix domain socket make sure your kernel has unix domain socket support. (it's a module in some of the standard kernels) - modconf doesn't find any modules. My only choice is to be finished and return to the previous menu. show us the output of ls /lib/modules/`uname -r` please? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#88413: PATCH]: modconf broken with ash
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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#88413: [PATCH]: modconf broken with ash
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/modconf,v
retrieving revision 1.7
diff -r1.7 modconf
115c115
tdir=${directory//\//_}
---
tdir=`eval echo \\${directory//\//_}`
(thanks to aaronl for the suggestion)
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer and devfs
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 PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i: status and where to go from here
* 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 gestalt. For example, when you boot up right now, you see a main menu like this: If you haven't done so, please add things like this to the cdebconf TODO list as you see them. I just finished with several weeks of traveling and hope to have more time to work on these things soon. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: task problem
(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 all the "equations". the only thing tasksel does is mark packages for install by apt. what i'd suggest is that, from a clean install, run tasksel -riq manually, select the task you want to install, and then run apt-get install and send the output to the BTS. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Boot CVS: tausq
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, so it should do some forms of PCI/ISA/USB/PCMCIA autodetection. It seems to work on my PCI network card at least... I'm not sure how much bloat this will add to the the boot-floppies though. we'll see will be back home (for a few days at least) on tuesday will do a more detailed writeup then. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the whole purpose of kernel-image-di?
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 looking into doing autodetection stuff for woody b-f using libdetect, but that might not be such a good idea if it's very i386 specific. cdebconf. Randolph, please do something about the warning and error I showed you from the preinst (?)! been on a road a lot this last few weeks. will fix on tuesday when i get back. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udpkg in busybox
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 than hack around it. FWIW udpkg does backup status files before changing them... re merging with busybox, as long as Erik is ok with it I have no issues with it. Looks like Glenn has already done quite a bit of work here, but if I need to do something let me know... randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udpkg wierdness
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 [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udpkg in busybox
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 bugs to fix, so I won't have a chance to dig into it. If you (or anyone else) have a bit of time to look into fixing it up today, that would be great! i don't have time to look into it today, and will be out for the long weekend. if glenn doesn't mind, let's turn it off for now and we can look at it some more next week. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg, udpkg and busybox
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? That way we can disable it to save space if needed. woah woah woah if you want full dpkg support, use dpkg. all the dependency checking and stuff is *HARD* and we don't want to fork another dpkg implementation into busybox. udpkg has very specific and limited goals. I've tried to document some of these in the design doc in the source. It is *only* supposed to work within the prescribed limitations; it is not meant to be a replacement for dpkg at all. The size goal for udpkg was around 8k. I think we should keep that goal in mind. the whole idea of the udebs is to bootstrap the system into a usable state ASAP. Once you have access to one of the retrievers you can get a real dpkg.deb and install/use that... randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cvs messages?
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} partial-lsearch
{/etc/exim/bsmtp} {$value}}" from the bsmtp transport
2001-02-16 10:49:52 14Tpx2-00057x-00 Failed to find user "" from
expanded string "${lookup {${domain}:user} partial-lsearch
{/etc/exim/bsmtp} {$value}}" from the bsmtp transport
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Notes on dbootstrap makefile and plans [Re: Debian Boot CVS: tausq]
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 Makefile.orig is the original makefile, keeping it in the repository for now in case i broke something some comments on this: dbootstrap's makefile seems to have accumlated a lot of special cases over the past months. here's an attempt to clean it up some. the idea is that things like language-chooser, graphical dbootstrap, etc can be controled via variables passed into make, which changes the relevant CFLAGS/LIBS, instead of having them be separate targets. I envision that we'll probably want to just standardize on, say, always turning language chooser on, and not have to always have multiple variants (though you can still build these quite easily). I've also made the build be silent by default (i.e. it doesn't show you the actual gcc command line). you can override this by passing NOISY=1 on the make line. Also, by default output all go into a build/ subdirectory instead of cluttering the source tree. This is similar to the .depends and .translated directories we had before, but i feel doing it this way is a bit cleaner. Finally, the foo_test make targets have also been cleaned up as well. Things that haven't been moved over yet are the *.trm targets. Of course you can still manually do something like make -C po C.trm, cp po/C.trm test.trm ... I don't think I'll have a whole lot of time to work on b-f stuff in the next few weeks, but I'd like to spend some time cleaning up dbootstrap. Since Adam has been working on the makefiles i'll leave that to him. The goal here is not so much to add new features, but to make b-f more maintainable. Comments on these are welcome of course; this include things like "your makefile sucks, let's just use the old one" :-) randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Notes on dbootstrap makefile and plans [Re: Debian Boot CVS: tausq]
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 them be separate targets. I envision that we'll probably want to just standardize on, say, always turning language chooser on, This means that framebuffer support would have to be turned on for all flavors. how does that follow? and not have to always have multiple variants (though you can still build these quite easily). How? make FB=true - dbootstrap with framebuffer support make LC=true - dbootstrap with language chooser support make FB=true LC=true - combo of above make SMALL=true LC=true - LC-enabled dbootstrap with size optimizations etc.. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[boot-floppies] overhauling makefiles?
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, but hopefully this will make things a lot more maintainable.
As an example of what I hope to achieve, see the attached sample
top-level makefile that I hope we'll end up with (work-in-progress, does
not work yet..)
comments? volunteers to help?
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
# This is the top-level makefile. Try to keep this clean; we split things
# into smaller chunks so that it is managable. Generic rules should be used
# if possible, but try to make things basic so that people understand what
# is going on and don't jump through too many hoops to get what they want.
#
# main configuration
include config
# any other local definitions (optional)
-include Makefile.defs
# architecture-independent settings/make rules
include build/Makefile.common
# Internationalization settings
include build/Makefile.i18n
# architecture-specific settings/make rules
include build/Makefile.$(architecture)
# documentation make rules
include build/Makefile.docs
# generic make rules
include build/Makefile.rules
# This file should only contain "major" build targets (subjective, of course)
all:: build
null:
: Null target for testing Makefile with "make -p null"
# check target - makes sure all prereqs are met
check: localfiles check_mirror check_loop check_kernel check_depends check_tools
$(CHECKFS)
@echo "check successful"
utils:
$(MAKE) -C utilities KVER=$(kver) KERNEL_VERSION_CODE=$(KERNEL_VERSION_CODE)
$(base_archive): basedisks.sh
$(ROOTCMD) ./basedisks.sh $(archive) $(debianversion)
build:: localfiles
$(MAKE) utils
$(MAKE) build_arch
$(MAKE) $(base_archive)
release: build docs
$(MAKE) release_arch
clean: umount distclean
distclean:
$(MAKE) -C utilities distclean
$(MAKE) -C scripts/rootdisk/messages clean
$(MAKE) -C documentation distclean
$(MAKE) -C powerpc-specials clean
rm -f *.bin *.tgz sys_map*.gz config*.gz linux* modcont* core \
base-contents.txt $(SFONT) \
root*.tar.gz silo1440k* tftpboot*.img *.tmp *.o
rm -f `find -name \*~` disks-$(architecture)
rm -f `find -name '.#*'`
rm -rf release updates check_basedeps ${tmpdir}/boot-floppies
# [ED] avoid direct compilation of C programs from the utilities subdir
# (see the root.bin dependencies).
.SUFFIXES:
.PHONY: release umount clean distclean
Re: Debian Boot CVS: tausq
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 with this change (and the associated libfdisk changes in the next CVS message) dbootstrap now runs on IA64! of course, "runs" is relative... lots of things still don't work. oh well.. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: flavors in debian-isntaller
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 correctly. So you aren't able to get rid of flavors for debian-installer? I don't really know. "Flavors" can also correspond to specially-built kernels, I'm sure people will at least find reasons to do that. there are a number of things that still cannot be built as modules, and building all those things in (serial console, partition support, etc) may still give us a kernel that is too big... i so wish we could somehow get rid of flavors though. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: demo segfaults
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 ifconfig... what you probably should do is go through the chroot manually; start in a shell, turn on core dumps (ulimit -c unlimited) and run /usr/bin/debconf /usr/bin/main-menu, when it segfaults you can at least tell from the core which component is segfaulting. can we turn on core dumps by default in the make demo target? a feature request for joeyh's build system: it'll be nice if somehow we can build a debug version of the chroot where we don't have all the size optimizations on the binaries that make debugging difficult... randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Boot CVS: dwhedon
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, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: busybox insmod
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 will get nasty emails from the autobuilders saying: #error Sorry, but insmod.c does not yet support this architecture... is this arch-specific code we can "borrow" from some place? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call-for-help: modconf
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 is not really available for any random module. The common ones have decent builtin docs that can be accessed via modinfo; but it's not implemented by many modules. As for using Documentation/Configure.help, modconf already uses this, but Configure.help does not usually document module parameters. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i, bf and udeb
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 the release after woody shall be using? :pserver:[EMAIL PROTECTED]:/cvs/debian-installer/ yes, and it may be available for limited uses for woody. Q4: what is a udeb, and how does it differ from a regular deb? what steps are different between making a deb and a udeb? a udeb is a debian package that is a "minimal" version of an application; it may not be completely policy compliant, does not support all features of dpkg, and is used by the debian-installer. i am hoping that the answer is RTFM, and a pointer as to where that FM might be. Archives of this list is probably the best way to find these answers. Reading past editions of DWN will also help. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ PGP signature
Re: Debian Boot CVS: tausq
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 libraries needed by varios cdebconf frontends was bloating the image. Is there some way we can trim it down to one frontend per image? The new cdebconf-udeb package i just uploaded only has the text and slang frontend enabled. Is that good enough for now? cdebconf also needs libdl, which was not being pulled in. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdebconf-udeb uploaded; notes about using with joey's build system
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 includes the text and slang frontends at the moment, unfortunately, the slang frontend doesn't work out-of-the-box inside the chroot (it's the default atm tho). The reason seems to be that slang requires the terminfo database to work properly, and this is not currently part of the chroot. So, for now, you can either edit /etc/debconf.conf and change the frontend default to text, or set the DEBCONF_FRONTEND environment variable to text instead of slang System stats Installed udebs: anna main-menu udpkg busybox-udeb ash-udeb choose-mirror wget-retriever cdebconf-udeb Total system size: 1.5M Gzips to: 580k randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Call-for-help: modconf
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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer: disk partitioner
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 use tsearch and friends from glibc. (glibc actually implements this with AVL trees, so you have near hash-table performance) glibc actually has a lot of nice data manipulation functions that we can use. we should look there before putting more libraries into d-i randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i build system
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] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new demo system -- chrooted!
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 display, I'm not sure. perhaps you preconfigure everything first (with their debconf protocol output/input just passing through to the cdebconf frontend), then when you actually install the stuff you redirect it to tty3? ok, pardon me for being slow.. just got back from a trip what exactly do you mean by passing the debconf frontend to the udeb frontend? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on the installer (early)
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) doesn't necessarily increase usability. Usability comes from a design that allows the user to do what s/he wants intuitively, not from a pretty look-and-feel. I'm not sure I understand why using gtk-fb, etc helps over using something like bogl. Two of the design constraints/goals for the installer are size and simplicity. What kind of overhead will gtk-fb add? We already have slang-based and bogl(fb)-based UIs in the works. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ PGP signature
Re: Thoughts on the installer (early)
(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, slang, etc are not "modern" and standard? there's definitely a place for a gtk-based UI, and it's on the cdebconf TODO list, but doing gtk on console/fb doesn't seem to make a whole lot of sense IMO. From what I gather today after playing around with gtk-fb today is that you would have to have the appropriate versions of several libraries available- the gtk gdk libs, compiled for frame buffer support, glib, the pango libs, and the freetype libs. That's a little overhead, yes, but I do think that since gtk-fb's a *little*? the gtk libs (the X ones, at least) adds up to about 2Mb. That's bigger than the size of cdebconf, udpkg, anna, and their support libs combined. motivation is for embedded devices that it would be adequate for our purposes. From first glance at looking at the new debian installer, it looks like size is becoming less of an issue, since the appropriate modules (udebs) can be retreived while the installer is running. At first glance, it seems feasible to me. If you are proposing that, for broadband/CD-ROM based installs, that we give the option of an X-based install where we use GTK+-type libraries for a UI, that's perfectly reasonable, and quite doable in the cdebconf framework. But if you look at the design, the udebs and cdebconf are mostly aimed at bootstrapping -- this falls under the portion of stuff you might, for example, put onto a floppy to get your install going so that you can pull the rest of things in through the network on a CD-ROM. Heck, as Joey puts it, this base system might not even have a shell The way I see it, the benefit of using this approach over something like bogl (sorry, I've haven't seen this yet), is that it provides a complete set of widgets that we can work with to produce a very bogl has a decent set of widgets... afaik it's one of the precursors of microwindows. Actually in boot-floppies (potato) there's even some wrappers to let it work in a pluggable fashion with dbootstrap. good. I don't think it would be wise to scrap the bogl efforts and move towards something else, but what I'm asking is if it is feasible to move the UI that bogl implements over to use gtk-ui, as opposed to the lightweight, from scratch interface that is there already? i don't want to sound very negative, but i really don't see the point of gtk-fb. gtk on X sounds reasonable, and I'd welcome anyone who'd be interested in writing a gtk UI module for cdebconf. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ PGP signature
comments on cdebconf
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 example on an unknown question type) the screen doesn't get cleaned up properly. is there a way to handle this more gracefully? (perhaps a simple SIGSEGV handler will work) i checked in a slang ui today; this will (for now) replace the ncurses stuff. slang is more lib-reduction friendly (at least right now) and has a cleaner interface. the slang ui doesn't handle multiselect and text question types yet, but other things should work. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf problems
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] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autoconfautomakelibtool
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 experience makes the makefiles *much* more difficult to understand. can you explain why you want cdebconf to use automake? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf problems
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 templates and questions and do this again also turn on debugging and see what happens. there're still a lot of things that need to be fixed about visibility handling and such. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coding style?
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] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Boot CVS: tausq
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 of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: biweekly debian-installer status report
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 flexible... or what? This has been discussed. slang will work just as well, but if we stay with the curses subset supported by slang than we can go with either ncurses or slang. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: biweekly debian-installer status report
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 tell it which one this is, and the rest is auto? if we do things right, automated installed "fall" right out of using debconf with minimal if any extra code needed. The recent article in one of the Linux magazines about using netboot and dhcp to automate installs in a computing lab was very interesting. How can debian installer do something like that? i didn't see this article, but in many cases these are done with ghost images -- you create a boot image, and all machines either boot with that image (nfsroot type), or you duplicate the image over to the machine. it would seem that automated installs using either an "answer file" that is part of your installation media, or using configuration gotten from a central configuration database (ldap, pgsql, or what have you) will give you the flexibility needed to do mass installs in, for example, a lab environment. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf feature?
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 figure out how to get this behavior with the current version of cdebconf. it's not there yet. your fix is basically the right way to do it, but i'm going to code something more generic so that all the question types can use it. i also need to implement the "seen" (aka isdefault) flag correctly. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: time to upload udebs!
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 subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf client support in cdebconf
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 around the tree.
Hm... I'd rather do this with a string lookup table and macro integer
constants. I'll put something like this in tomorrow. something along the
lines of:
static char *dc_command_strings[] = {
"INPUT", "GET", ...
};
#define DC_INPUT0
#define DC_GET 1
...
sounds ok to you?
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] anyone interested in an irc meeting?
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. The meeting will be on irc.openprojects.net (aka irc.debian.org), in #debian-boot randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer demo system, take 2a
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 version :-) samwise[21:42] demo% du -sh 276k. [ Not too big, I hope compresses to about 40k ] samwise[21:42] demo% find . ./var ./var/lib ./var/lib/dpkg ./var/lib/dpkg/info ./var/lib/dpkg/info/udpkg.list ./var/lib/dpkg/info/main-menu.list ./var/lib/dpkg/info/main-menu.postrm ./var/lib/dpkg/info/main-menu.templates ./var/lib/dpkg/info/wget-retriever.list ./var/lib/dpkg/info/choose-mirror.list ./var/lib/dpkg/info/choose-mirror.postrm ./var/lib/dpkg/info/choose-mirror.postinst ./var/lib/dpkg/info/anna.list ./var/lib/dpkg/info/anna.postrm ./var/lib/dpkg/info/anna.templates ./var/lib/dpkg/info/anna.postinst ./var/lib/dpkg/info/choose-mirror.templates ./var/lib/dpkg/status ./var/lib/cdebconf ./var/lib/cdebconf/templates ./var/lib/cdebconf/questions ./var/cache ./var/cache/anna ./usr ./usr/bin ./usr/bin/udpkg ./usr/bin/anna ./usr/bin/choose-mirror ./usr/bin/main-menu ./usr/bin/dpkg-reconfigure ./usr/bin/debconf ./usr/bin/debconf-loadtemplate ./usr/lib ./usr/lib/debian-installer ./usr/lib/debian-installer/retriever ./usr/lib/debian-installer/retriever/wget-retriever ./usr/lib/cdebconf ./usr/lib/cdebconf/db ./usr/lib/cdebconf/db/textdb.so ./usr/lib/cdebconf/frontend ./usr/lib/cdebconf/frontend/text.so ./usr/lib/libdebconf.so.0.1.0 ./usr/lib/libdebconf.so.0.1 ./usr/lib/libdebconf.so ./usr/share ./usr/share/debconf ./usr/share/debconf/confmodule ./usr/share/debconf/frontend ./etc ./etc/debconf.conf samwise[21:43] demo% LD_LIBRARY_PATH=usr/lib usr/bin/debconf-loadtemplate \ var/lib/dpkg/info/*.templates samwise[21:43] demo% LD_LIBRARY_PATH=usr/lib PATH=usr/bin:$PATH \ usr/share/debconf/frontend usr/bin/main-menu [ using the text ui, not very polished right now, and the titles are not set correctly. also, it doesn't optimize away single selects like perl debconf does, but that's easily changed ] Configuring main-menu = Choose the next step: Here is the main menu of the Debian installer. 1) Finish setting up the Debian installer 1 - 1 1 Choose == Use a mirror from what country? The goal is to find a mirror that is close to you on the network -- be aware that near countries, or even your own, may not be the best choice. 1) Australia 2) Austria 3) Belgium 4) Brazil 5) Britain (UK) 6) Bulgaria 7) Canada 8) China 9) Costa Rica 10) Croatia 11) Czech Republic 12) Denmark 13) Estonia 14) Finland 15) France 16) Germany 17) Greece 18) Hong Kong 19) Hungary 20) Indonesia 21) Ireland 22) Italy 23) Japan 24) Korea (South) 25) Latvia 26) Mexico 27) Netherlands 28) New Zealand 29) Norway 30) Poland 31) Portugal 32) Russia 33) Slovakia 34) Slovenia 35) South Africa 36) Spain 37) Sweden 38) Switzerland 39) Taiwan 40) Turkey 41) United States 42) enter information manually 1 - 42 [default = 41] Choose == Choose the Debian mirror to use: Select the mirror Debian will be downloaded from. You should select a mirror that is close to you on the net. 1) http.us.debian.org 2) ftp.eecs.umich.edu 3) llug.sep.bnl.gov 4) ftp.debian.org 5) ftp-mirror.internap.com 6) debian.uchicago.edu 7) ftp.us.debian.org 8) debian.tod.net 9) lyre.mit.edu 10) mirrors.xmission.com 11) download.sourceforge.net 12) ftp.kernel.org 13) sunsite.unc.edu 14) ftp.cerias.purdue.edu 15) debian.fifi.org 16) mirrors.rcn.net 17) debian.gnaps.com 18) ftp.keystealth.org 19) debian.bilow.com 20) natasha.stmarytx.edu 21) ftp.digex.net 22) debian.lrlug.org 23) ftp.tux.org 1 - 23 [default = 1] Enter http proxy information, or leave blank for none: If you need to use a http proxy to access the outside world, enter the proxy information here. Otherwise, leave this blank. When entering proxy information, use the standard form of "http://[[user][:pass]@]host[:port]/" http://samwise.tausq.org:3128/ [ pause ... ] Choose == Choose the next step: Here is the main menu of the Debian installer. 1) autodetection of ethernet cards 2) Finish setting up the Debian installer 1 - 2 1 [ ctrl - c ] samwise[21:44] demo% find usr/bin usr/bin usr/bin/udpkg usr/bin/anna usr/bin/choose-mirror usr/bin/main-menu usr/bin/dpkg-reconfigure usr/bin/debconf usr/bin/debconf-loadtemplate usr/bin/memdetect usr/bin/mdmdetect usr/bin/ethdetect usr/bin/diskdetect usr/bin/cpudetect usr/bin/cddetect demo2a can be found at: http://people.debian.org/~tausq/debian-installer/demo2a.tar.gz cdebconf actually also has a ncurses frontend in the works. (it configures debconf (the perl one) even :-), but it only handles a subset of the question types now so i've not used it in this demo run. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ --
debconf client support in 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(); client-command(client, "INPUT", "low", "foo/bar", NULL); myvar = client-value; (or myvar = client-ret(client); ) /* ... */ debconfclient_delete(client); to compile the library, go to tools/cdebconf, and do ./configure; make add -I(path to tools/cdebconf/src) to your makefile for now, and -L(path) -ldebconf to link. By default libdebconf is built with a rpath set to the path where cdebconf is, so you don't need to set LD_LIBRARY_PATH. If you don't want that you can set --without-rpath when you build cdebconf I'll make a -dev package for cdebconf at some point, but it's moving too fast now and the API may change from time to time. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [VA-Debian] Comments from a first-time Debian install.....
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 -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sumary] Re: unattended install
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" boot-floppies system maybe this is worth looking into for b-f as well. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#78750: Can't load lp module during install
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://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FWD: Re: Debian Boot CVS: polish
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) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Debian Boot CVS: polish Reply-To: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] archive/latest/14811 ** Original Message ** FROM: [EMAIL PROTECTED] SENT: Sun 12/03/2000 12:56 AM TO: [EMAIL PROTECTED] SUBJECT: Debian Boot CVS: polish CVSROOT: /cvs/debian-boot Module name: boot-floppies Changes by:polish 00/12/02 09:51:40 Modified files: documentation : doc-check Log message: should run a bit faster now -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] __ Make A Buck Or Two @ TheMail.com - Free Internet Email Sign-up today at http://www.themail.com/ref.htm?ref=1763925 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] anyone interested in an irc meeting?
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 this useful? 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. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: common udpkg and uapt-get functionality
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. Glenn, while there may certain a place for a "uapt-get" type application, there are still MANY TODO items in the d-i list needed to get a basic system working. Would you be interested in working on one of those instead for now? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[debian-installer] anyone interested in an irc meeting?
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://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody: shell a core component?
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. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.18pre kernels and pcmcia in 2.2rN
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 support is broken with the latest kernel (version xx.xx.xx)", when the pcmcia sources are obsolete. OK, pcmcia-cs and modules for the four i386 flavors have been uploaded. hope they work i've talked to aj about this and he's ok with the new versions going into 2.2rX randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Boot CVS: aph
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 week. aph may be handling the passwd file differently. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One or two floppies (was: first weekly debian-installer status report)
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) PCNET32 (Not very common, but used by VMWware so helps with test installs) Intel EEPro (PCI, not ISA) NE2K (PCI) VIA Rhine randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Monitor autodetection
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 shell to edit some configs or reading the manuals is too hard for them. This doesn't need to be, and IMHO doesn't belong, in the kernel. Assuming you mean DDC for getting monitor frequencies and such, X4 already does this automatically. If not there are apps out there like read-edid that can do this in user-space. Combined with things like anXious (or Progeny's dexter) this makes things quite easy. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first weekly debian-installer status report
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 stuff from cvs, and let me know if you have any questions :-) randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first weekly debian-installer status report
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 can do that too... randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: first weekly debian-installer status report
- 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 retriever doc has cdrom, floppy, hdd, http, ftp (maybe) and nfs, but for the prototype i think we are only going to do http for now. one thing is that the current busybox wget doesn't support http proxies. we'll probably need to add that. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-deb shell script
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 Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to store hardware info ?
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 PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-deb shell script
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 sure Adam can add you... (this is the debian-boot cvs btw) randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
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. there are only a small number of cards (3?) reported to be not yet detected in the bts. most of them were actually added to a rejected upload to potato. i can reupload it for 2.2r1 if needed. i haven't heard that xvidetect knows about "pathetically few" cards... Adam, where did you hear that from? randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PCI autodetection
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 PCI nic. this is really just like what xviddetect/anXious does; you just have a db of kernel modules instead of Xserver names randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[very preliminary] C debconf conceptual code
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 written and plugged in via a configuration file.
i'd like to think the overhead for this flexibility is fairly minimal
(some dlopen code, and maybe the configuration stuff, which adds up to
about 7-8k); if people think that's too much we can use a static
architecture for the boot-floppies debconf.
Right now, the confmodule starts up by reading a config file, that might
look like this:
frontend {
default {
driver "ncurses"; // use the ncurses frontend by default
};
driver "ncurses" {
module "modules/frontend/ncurses.so";
};
driver "text" {
module "modules/frontend/text.so";
};
};
database {
default {
driver "textdb"; // use the textdb database backend by default
};
driver "textdb" {
module "modules/db/textdb.so";
};
};
The database and frontend modules are then instantiated, loading in the
approrpriate DSOs from the config file. Finally, a confmodule is
initialized which will call fork/exec to run the config script, and talk to
it using stdin/stdout.
if anything looks odd, it's because i wrote most of it on a plane :-)
seriously though, comments/suggestions are most welcome. volunteers to
work on this will be very much appreciated too!
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
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 say the Frontend that they want to have answered some question. Therefore the frontend can look in some database, if it wants. Right, but how does it follow that you don't have a single database for both the questions and the answers? (the current debconf does this...) Perhaps I still don't understand what you are getting at. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: redesigning the debian installer
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 and you can decide not to probe for isa devices if you don't want to, etc. other than libdetect there aren't any big projects out there. however, for modern devices all the "detection" is really done by the kernel already (cf. pci, usb) and really all is needed is a good database of id-to-driver mappings. The rest can be done with a very simple C program and some shell scripts. I also saw references to vii (DCC based monitor setting retriever). I'll definitely check it out. Several of us had thought about doing this last year but it unfortunately never happened. of course, if we standardize on X4 for woody then this is moot. 2) fully automated installs Like others I think this will be one of the most important features we should build into the new installer. I like the idea of "profiles" or "scripts" that have answers to various installer questions. Using debconf for this seems like a natural extension. (see more below). 3) custom-built images (through a CGI or something) Very interesting idea, but I think this should be a longer-term goal. As Brooks puts it so eloquently, beware of the "Second System Effect"! Let's try to get a complete but *simple* system going first. 4) C-based debconf Anyone (other than Glenn and myself) interested in working on this? I had planned on tackling this after i finish udpkg, but my time will be somewhat limited in the next few weeks. I don't *think* it should be too difficult to do this A month or so ago I had posted a proposal to design a detachable database system for debconf that is modularized (can use a text or binary, local or remote) database. i think we can work this in with the automatable installs: a text-based debconf database is easily editable by a system administrator. otoh, a network based (ldap or whatnot) system will also allow automated installs over a lan/wan. Of course, size/complexity is a concern as well. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[woody] udpkg progress
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 configure (should be easy -- just run the postinst, passing in the right parameters) and status file merging. also, need to explore integrating busybox tools into udpkg. either udpkg pulls in busybox modules, or we just go ahead and add udpkg as another busybox utility module. Erik, comments? i also checked in the topological sort code so that packages are installed in the correct order if you want to install multiple packages. if we are only going to install one package at a time though this is not needed. right now you can turn all the dependency checking off with --without-depends. i'll add some switches for finer-grain control of what goes in at some point. with debugging turned off, dependency checking, -Os optimization, and stripping, the binary is now 10804 bytes :-) the status merging stuff is the next big piece of code... if someone wants to look at the busybox aspect i'd appreciate it. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] microdpkg
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 subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
CVS Update: debian-installer
[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 va:/usr/debian/tmp/cvs-serv18492/tools Log Message: Directory /cvs/debian-boot/debian-installer/tools added to the repository -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] microdpkg
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 something into cvs. it's in tools/udpkg
It's really still very incomplete. It "supports deps" right now only in the
sense that it will check dependencies against installed/to-be-installed-with-
same-command packages. it doesn't do any of the ordering stuff yet,
although the hooks are there. Dependency checking can be turned off
completely at compile time as well.
As I mentioned above, it's still very incomplete. Feel free to
contribute changes, etc. I am exploring how to best handle the files
that go into /var/lib/dpkg/info/ in particular the list file is
ugly... i'm thinking of doing something like (+ error checking, etc):
FILE *infp, *outfp;
char buf[MAXLEN];
char *p;
infp = popen("ar p foobar.deb control.tar.gz | zcat | tar -tf -");
outfp = fopen("/var/lib/dpkg/info/foobar.list");
while (fgets(buf, sizeof(buf), inp) !feof(inp))
{
p = buf; if (*p == '.') p++;
fputs(p, outp);
}
fclose(outfp);
pclose(infp);
Gross
Suggestions and code contributions welcome :
randolph
--
Debian Developer [EMAIL PROTECTED]
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] microdpkg
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 have its dependencies fullfilled. If not, punt; if so, go ahead and install them all and write the status data back out to disk. not quite sure what you mean by "whole dependency tree checking" ... right now i am playing with this, and have it load the status file into memory, storing the package name and status info of each record (no other meta data is stored). if a package provides a virtual package, the virtual package is added as another package in the list with the "real" package's status. [1] when you install a list of packages, these packages will have their status set to "install ok installed" [2] in the above list. then, for each package, it will look up the status in the list and make sure all the dependent packages are in the "install ok installed" state. if not it will die. [3] otherwise the data.tar.gz component will be unpacked in /, and the postinst script run if it exists. finally the appropriate control files are moved into /var/lib/dpkg/info/ once packages are installed, the status file is updated by passing in all the control info from the recently-installed packages. a merge between status and the new control data is done, with status info updated from the in-memory list. does that sound about right? * Dpkg-deb has a really simple interface and will be trivial to clone well. So people will be able to use the clone with a high degree of confidence that it'll work like dpkg-deb would. unlike dpkg, dpkg-deb can quite easily be written as a shell script. this may be a better home for it then busybox, which is really a non-debian-specific tool. randolph [1] it needs to be a bit more intelligent than it is currently, probably. if several packages provide a virtual package, whatever occurs later in the status file will take precedence, which may not be desirable. [2] maybe this should be "install ok half-installed". i need to figure out what dpkg does [3] if you are installing multiple packages then it needs to update the status flags and then do the status file merging could be ugly :-( -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [debian-installer] microdpkg
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 install bar before foo just because foo depends on bar... well, you *could* do ordering. presumably if you have to handle depends, you need some sort of DAG to model the dependencies. it shouldn't be hard to do a topo-sort on the DAG to get what to install in what order. if you do force-depends all the time there is no reason to write a program, you'd just use something like Erik's shell script that unpacks data.tar.gz to / and run things from control.tar.gz. if you force depends it almost doesn't make sense to update the status file... A uapt-get that lets you say "uapt-get install foo" and *does* cope with resolving dependencies (but not conflicts, versions, or multiple Packages files, perhaps) might be useful too, without being too difficult or large. Hmmm. It really depends on what you want to use it for, though. are you volunteering to write this? ;-) in all seriousness, if someone wants to write a small but robust http/ftp fetch module for busybox that'd be awesome. perhaps all we need is snarf. but in keeping with the modular approach this will let us integrate things in a more flexible manner. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ PGP signature
Re: regarding xviddetect
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 you agree? well, it really wouldn't be a branch... i uploaded a xviddetect to close most of those bugs for new video cards, but it was rejected for the initial potato release. hopefully it'll make it into the r1 release. randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bf rewrite?
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 work going into dbootstrap (and other parts of the system). For example, things like DHCP support, HTTP installs, better I18N and powerpc/arm support were all major enhancements added to dbootstrap in the past few months. base-config, the task selection system and a X Window configuration helper system were added. Support for TFTP installs on Sparc, and installs from ZIP/LS120 media were also added to the boot-floppies in the recent past. (not to mention the amount of documentation that has been created and revised for potato...) I don't think it's fair to characterize this as "very slow" development. On the other hand, it's true that a lot of the installation system remains kludgy and not as nice as, say, RedHat's Quickstart, in certain ways. There are many limitations in the current system that can be changed to make an IMHO better system: - there is no reason we need a 20+meg tarball to bootstrap the system. base2_2.tgz should go, or at least become much smaller - we need ways to do (at least semi-)automated installs, or at least installs that require less response from the user - we should probably go to an initrd-type kernel system so that we don't need so many root/driver disks A lot of these require fundamental changes to the way the current system works. If someone wants to spend time continuing to maintain the current system I think that will be very useful. But at some point we do need to do a clean design if we want to improve one of the most-criticized components of Debian. my 2 cents, randolph -- Debian Developer [EMAIL PROTECTED] http://www.TauSq.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
