Subject: Re: dcontrol IRC meeting log - msg#00023

Previous Message by Date: click to view message preview

Re: Building headless network install the proper way

> maybe > F7 will give more details on getting the boot strings right. You would probably need to figure out the debconf answers you need to provide tough, only a couple of them are shown on the help screen. Maybe some of those: /var/cache/debconf# grep install config.dat Name: debian-installer/country Name: debian-installer/keymap Name: debian-installer/language

Next Message by Date: click to view message preview

Re: [dannf@xxxxxxxxxx: cdd-doc licensing]

On Sat, 31 Jul 2004, dann frazier wrote: > I was poking through cdd-doc in svn and noticed that it is licensed under > the GFDL - should this be changed to the GPL, given the DFSG compatability > issues? What do you think about it. I have to admit that I do not really understand all this licensing fuss, but if I'm not completely wrong GFDL is not incompatible to DFSG per se but only if there are some certain additions. Anyway, I would just choose a DFSG compatible license to avoid all trouble but I will not spend my time with licensing issues (flame wars). Just give concise and well thought reasons which make absolutely clear that cdd-doc is incompatible to DFSG and make a suggestion which would fix that. Kind regards Andreas.

Previous Message by Thread: click to view message preview

Building headless network install the proper way

I need help doing properly what I did before by modifying an initrd. A while back, I used the "twin" package and modified the sarge network install ramdisk to support a fully interactive headless network install. By controlling the reset switch with a serial port controlled relay module, and a dhcp/tftp server, this allowed me to bring up machines from scratch and do a full install if needed. I built this the hard way by adding files and libraries to the initrd till it all worked, running twin continuously till it stayed up (network had come up) and pre-supplying some of the installation answers and running at high-priority so not all questions were asked. This was enough for the installer to bring the network up and then pop up the installer under twin, on my X server (specified in kernel boot string). I now have the kit installed to build by own debian-installer setup and I guess to this I am going to have to add udebs that contain twin, the extra init scripts and so forth. er... help! I'm looking to know which config files I need to mod, what to do to get twin compiled so it doesn't need a full glibc, help help etc I'm not dumb... I think.... so specific questions: 1) I want to add a package to the initrd as built using the debian-installer builder. How do I go about having the package build statically? Is this what I should be doing? 2) Is there a better way to have the network brought straight up by DHCP or with kernel boot config strings? I'll be testing the ramdisk using colinux initially and when I think its right I'll try on some real hardware. Sam

Next Message by Thread: click to view message preview

Using tasksel features (Was: an idea for debian-edu tasks)

Hello, I'd like to point out you to this mail from Joey Hess at debian-edu mailing list because it concerns all CDDs. I'd suggest to continue the discussion at debian-custom because it belongs to this list and we might CC Joey Hess (and others who might be only subscribed to debian-edu but not debian-custom). On Fri, 16 Jul 2004, Joey Hess wrote: > We're still having much trouble getting the education-* packages into > testing. The next release of tasksel will have some features that could > let us use it instead of task packages, and avoid these problems. > > Here's how it could work: > > - debian-edu installations install a education-tasks package, or similar. > - This provides a /usr/share/tasksel/debian-edu-tasks.desc, which lists > the debian-edu tasks. > - Also a /usr/lib/tasksel/packages/debian-edu program. That program would > be responsible for outputting a list of packages to install as part of a > task. > - With the above files in place, tasksel would be able to display and > install debian-edu tasks. > - We could also include a /usr/lib/tasksel/tests/debian-edu, which > would be used to tell tasksel which debian-edu tasks to automatically > install, based on /etc/debian-edu/config. > - debian-edu-install would be changed to let tasksel run during > base-config. The debconf priority would prevent tasksel from being > seen, but it would install all the appropriate packages from > debian-edu tasks just as it does for other Debian tasks. > > This would solve the problem of education-* task packages dependencies > keeping them out of testing, since we'd no longer have such packages. > The implementation of /usr/lib/tasksel/packages/debian-edu could just > cat out predetermined lists of packages for a task at first, but if we > later wanted to make it use debtags or something more sophisticated, > we'd have the flexability to do that. Another nice benefit is that we > could make the education-laptop task be automatically installed if the > Debian laptop task was installed (the Debian laptop task will soon be > automatically installed on all laptops). > > The disadvantages are mostly related to not being able to apt-get install > education-whatever. We would need to deal with upgrades in some other > way. Perhaps we would still include education-* packages, but rather > than depending on everything in the task, they could just be installed > as part of it, and be used to add new packages during upgrades. > > Another area of complication is getting the package lists for the CD. > Simply adding the education-* packages to the CD would not do it anymore > (if it ever really did). The new tasksel has a facility to list the set > of packages in a task, and I will probably hook this into debian-cd. If you ask me I see no chance in the near future to get rid off the meta packages approach because the suggestion of Joey just covers one aspekt of the sense of meta packages - the dependencies. If you have a look at http://people.debian.org/~tille/cdd/ch-technology.en.html#s-metapackages I see no clue how to go for the other three points. On the other hand it might be useful to profit also from the enhanced features of tasksel because tasksel is the very first interface after new installations. Is there any short intro into the new features of tasksel which might help representing every single CDD in an apropriate way? Kind regards Andreas.