#include <hallo.h>
* [EMAIL PROTECTED] [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.
A-Ha.
> > > /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
> outputs.
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
> configuration.
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
ftp.debian.org.
> 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
MfG,
Eduard.
--
<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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
