On Wed, 25 Jun 2003, Eduard Bloch wrote: > #include <hallo.h> > * [EMAIL PROTECTED] [Wed, Jun 25 2003, 02:47:44PM]: > > > > > > Stable still has 3.0.22. Is there a reason 3.0.23 never moved to > > > > > stable, Eduard? > > > > > > See above. Woody has been moved to stable under our asses, and to this > > > time there were an RC bug about potential security problems. One of the > > > problems with Debian's release system. > > > > I have tried the testing version. It fails too: > > 1393+1 records out > > You did not understand the problem. It is not the version of BFs
The problem, I thought, is that the three versions of b-f I've used do not produce bootable images. > whereever it now are, it is the location of the supplementary packages > like kernel-image-*; they are still located in unstable while the > build scripts look in Woody. Why is that? I would have thought it logical to distribute b-f configured to look for kernels in places where they may be found. I'm new to all this, I don't have a clue where to look. My plan was to build bootable floppies as near as possible to what I can download from the local Debian mirror, and having done that, figure how to make the changes I desire. > > /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_main_binary-powerpc_Packages > > E: Couldn't download pcmcia-modules-2.4.18-newpmac > > E: ./kernel.sh abort > > And the solution is: get those packages from the pool and store them in > your local package directory (see the "config" file). IMV that's more a workaround than a cure. While it will likely fix it for me, the next person along will encounter the same difficulties. > > > It seems to me part of the problem is that it has hard-coded into it > > versions of kernels to use, and the kernel maintainers have replaced > > those packages. > > The kernel maintainers cannot replace or move packages easily - Woody is > stale^h^hble. That should make hard-coding versions less of a problem, but it's still a flawed approach. > > > I'm sure I can hack this thing to build the bootfloppies _I_ need, but > > that won't help others. Part of what I would do is prevent it from > > building for boxes I don't have. > > And that is the reason why boot-floppies are no built by build daemons > but manually by each architecture maintainer. > > > What I think should be happening is this: > > 1. Default to using mirror(s) from /etc/apt/sources.list. That would > > eliminate one of the customisations I must make. > > 2. Parse the Packages to the extent necessary to discover the most > > recent of each of the packages needed. > > You can define a mirror in the config, that is not the problem. The problem is the > Debian release which the > packages belong to. A possible workaround would be modifying the build > scripts to work with the pool structure (read: having a private version > of the /etc/apt directory where you can specify the priority of the > packages, scanning every Packages file available on that mirror), taking > the stable version of a package if possible and if not, fall-back on the > Sid version of the same package. Maybe you can use apt for this purpose, > but who is going to make this work? Many people declared the BFs as > doomed, I doubt that you really wish to stand up and work on it. Something needs to be done in the short term. From what I've seen there are quite a few refugees from Red Hat come to Debian recently. A lot of them are capable at what they do (installing and configuring Linux), and they will be finding this part of Debian a nasty shock. > > 3. Maybe source a site configuration file from /etc/bootfloppies/ where > > the results of steps 1 and 2 can be adjusted. > > Why /etc? We are just building a package, the changes on the host system > should be minimal. At this level, b-f is a tool, not so different from mkisofs, that takes data from various sources, processes it in magical ways, and produces outputs. I've not tried using it except as root - in my environment the usual advice not not be root doesn't seem so sensible - but it does require configuration, and /etc seems to me a sensible place for that configuration. Red Hat's equivalent tool is Anaconda, and you don't go fooling round with the package itself to build your CDs (Anaconda does a bit more) and boot images. Even if you disagree on /etc, ~/boot-floppies/ remains a good place for personal customisation. > > > 4. Source a personal configuration file for further fine-tuning. > > Feel free to create a such thing, I won't accept it in the "stable" > branch. > Very likely, you'd not like anything I'm likely to come up with. In a shell script, i'd so something like [ -f $HOME/boot-floppies/config ] && . $HOME/boot-floppies/config at a point that seems good to me;-). How I would do that in a make file, I really don't know. > > I'm sure you can argue whether this idea is slightly broken: the main > > objective is to achieve something that is robust enough to work for the > > It is quite robust as-is. It is just the FTP archive that is > incosistent. Robust? It doesn't work at all at present. As a user, I don't care whether the particular problem is that the Debian respository has changed since b-f was packaged. I don't have to be a car mechanic to diagnose that my car won't start, and I don't care whether it's because it's out of fuel or the spark plugs are dirty. Either way, the engine cranks but doesn't start. Robust means to me that when someone updates the repository, especially with an official update, it continues to work. > > unsuspecting (me, for example) and to simplify customisation for more > > advanced use. Customising the config file doesn't seem to me especially > > elegant or robust, and I can imagine it causing problems with updates > > from CVS. > > Nack. There only were few problems with CVS mergin in the hot > development phase. I may be mistaken, but I think that if you changed a line near here, then my attempt to update from CVS would run into trouble: ## ## Debian mirror we can download from, must be http://, ftp:// or file:// ## export MIRRORS := http://ftp.wa.au.debian.org/debian ## ## How to achieve root > > MfG, > Eduard. > -- Cheers John Summerfield Please, no off-list mail at all at all. This address accepts mail only from Debian addresses. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
