Re: Building boot images with boot-floppies on PowerMac
* email@example.com [Thu, Jun 26 2003, 11:11:39AM]:
> > > 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.
That is the reason for first asking the arch maintainer. RTF intro files
in the package, starting at README.
> > 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
Because we need a controllable way to take the _stable_ packages for
_stable_ branch of boot-floppies.
> 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.
> > > /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.
And it won't change. If you are willing to make radical changes, look at
the Debian installer project. There a such problem has never existed
since they have a separated tree in the FTP archive.
> > 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.
Who are you speaking for? Newbies? They are users, not developers.
> > > 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
Loool. And KDE is just a user tool, not so different from cdrecord (in
your categories), isn't?
> data from various sources, processes it in magical ways, and produces
There is not magic in mkisofs, clean code based on almost clean specs.
The job ob BFs is quite different. (and before you start bichting: I am
the cdrtools comaintainer).
> 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
And if a developers wants to commit the changes on his personal files,
he has to move it first? Sounds more like a cludge for me.
> 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.
Redhat does not have multiple kernels (does it?), so many installation
ways withing the first stage installer, etc.
> Even if you disagree on /etc, ~/boot-floppies/ remains a good place for
> personal customisation.
WHY? We are developers, not users. We can use diff, patch and cvs.
> > > 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.
Talk is cheap.
> Robust means to me that when someone updates the repository, especially
> with an official update, it continues to work.
That is the core problem, and if you wanna complain, file a bug against
> 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:
man cvs | grep merge
<jjFux> Wirklich schwierig, ein neues fortune unterzubringen. weasel macht nen
netten Spruch und reagiert nicht auf meinen Vorschlag, Alfie schickt
mich zu Zomb, Zomb zu weasel.