Re: Building D-I - formerly Building boot images with boot-floppies on PowerMac
On Thu, Jul 03, 2003 at 12:07:30PM +0800, [EMAIL PROTECTED] wrote: > On Wed, 2 Jul 2003, Chris Tillman wrote: > > > On Thu, Jul 03, 2003 at 07:54:37AM +0800, [EMAIL PROTECTED] wrote: > > > On Wed, 2 Jul 2003, Chris Tillman wrote: > > > > > > > > Recipe: > > > > > - install the build-dependancies on the host system > > > > > I don't know what they are, don't know how to find out so we'll see what > > > > > breaks > > > > > > > > The build dependencies are listed in build/debian/control.in. One easy way > > > > to have it check for you, is to cp debian/control.in to debian/control, > > > > then in the bulid directory use dpkg-buildpackage -D -b. Although this is > > > > not a normal debian package, you will still get the unsatisfied dependencies > > > > listed. There is also a @UDEB_DEPENDS@ entry, which the make process will > > > > fill in and download later based on your arch and sources.list.local. > > > > > > I presume I need to upgrade this system to sid? > > > > No, I wouldn't upgrade the whole system if I were you. If you install the > > packages you need, they will pull in the dependencies from unstable as > > needed, for example libc6 etc. But you will have a more stable system > > if you just let it get whatever it needs out of sid. > > I copied by deb line, changed stable to unstable and ran this command: > for p in install libdiscover1-pic libdiscover1 genext2fs mklibs libdebconfclient0 > libdebian-installer3; do apt-get -qqyu install $p; done You can list as many packages as you want after install: apt-get -qqyu install libdiscover1-pic libdiscover1 genext2fs mklibs libdebconfclient0 libdebian-installer3 -- Debian GNU/Linux Operating System By the People, For the People Chris Tillman (a people instance) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building D-I - formerly Building boot images with boot-floppies on PowerMac
On Thu, Jul 03, 2003 at 07:54:37AM +0800, [EMAIL PROTECTED] wrote: > On Wed, 2 Jul 2003, Chris Tillman wrote: > > > > Recipe: > > > - install the build-dependancies on the host system > > > I don't know what they are, don't know how to find out so we'll see what > > > breaks > > > > The build dependencies are listed in build/debian/control.in. One easy way > > to have it check for you, is to cp debian/control.in to debian/control, > > then in the bulid directory use dpkg-buildpackage -D -b. Although this is > > not a normal debian package, you will still get the unsatisfied dependencies > > listed. There is also a @UDEB_DEPENDS@ entry, which the make process will > > fill in and download later based on your arch and sources.list.local. > > I presume I need to upgrade this system to sid? No, I wouldn't upgrade the whole system if I were you. If you install the packages you need, they will pull in the dependencies from unstable as needed, for example libc6 etc. But you will have a more stable system if you just let it get whatever it needs out of sid. > btw is either b-f or d-i supposed to be able to create a bootable CD for > the powermac? From what I"ve read, these OldWorld powermacs are supposed > to boot from CD, but I've not got a CD that does boot on them. CDs are produced by yet another package, debian-cd. It uses mkisofs to create an hfs-hybrid bootable CD, well bootable on NewWorlds anyway. OldWorld powermacs can boot from CD, only if the CD has proprietary MacOS drivers. So Debian CDs don't boot on OldWorlds because there is no free equivalent CD driver (it's MacOS ROM code I believe). You can make an OldWorld bootable, if you want to copy the drivers from a MacOS bootable CD -- but we can't distribute that solution. There is a recipe somewhere, I think in mkisofs docs. BootX is convenient for booting OldWorlds from an existing MacOS installation. -- Debian GNU/Linux Operating System By the People, For the People Chris Tillman (a people instance) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building D-I - formerly Building boot images with boot-floppies on PowerMac
On Wed, Jul 02, 2003 at 08:03:57AM +0800, [EMAIL PROTECTED] wrote:
> On 1 Jul 2003, Gaudenz Steinlin wrote:
>
> > Am Die, 2003-07-01 um 14.40 schrieb [EMAIL PROTECTED]:
> >
> > > I would need to build _everything_, unless there are binaries some place
> > > for oldworld powermacs. The build document is a little terse, and I
> > > don't see a list of udebs at all.
> > No you don't have to do that. Read build/README. Basically you have to
> > copy build/sources.list to build/sources.list.local and edit this file.
> > Then you have to call make cd_image (patch pending) or make initrd to
> > build installer images.
> >
> > gaudenz
>
>
> Okay, I read that readme again and decided to try it on the basis that
> if it works but take a day it mightn't matter too much.
>
> Recipe:
> - install the build-dependancies on the host system
> I don't know what they are, don't know how to find out so we'll see what
> breaks
The build dependencies are listed in build/debian/control.in. One easy way
to have it check for you, is to cp debian/control.in to debian/control,
then in the bulid directory use dpkg-buildpackage -D -b. Although this is
not a normal debian package, you will still get the unsatisfied dependencies
listed. There is also a @UDEB_DEPENDS@ entry, which the make process will
fill in and download later based on your arch and sources.list.local.
> - adjust apt sources (create sources.list.local - see sources.list)
> Did that.
>
> - run "{sudo,fakeroot} make build"
> Kultarr:~/cvs/bf/debian-installer/build# time make build
> Makefile:83: make/arch/linux-powerpc: No such file or directory
> make: *** No rule to make target `make/arch/linux-powerpc'. Stop.
This is the file that was committed last night.
> real0m3.378s
> user0m1.020s
> sys 0m0.800s
> Kultarr:~/cvs/bf/debian-installer/build#
>
>
> - run "sudo make image"
>
> >
>
> --
>
> 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]
>
--
Debian GNU/Linux Operating System
By the People, For the People
Chris Tillman (a people instance)
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building boot images with boot-floppies on PowerMac
On Tue, Jul 01, 2003 at 09:33:13PM +0200, Gaudenz Steinlin wrote: > Am Die, 2003-07-01 um 14.40 schrieb [EMAIL PROTECTED]: > > > I would need to build _everything_, unless there are binaries some place > > for oldworld powermacs. The build document is a little terse, and I > > don't see a list of udebs at all. > No you don't have to do that. Read build/README. Basically you have to > copy build/sources.list to build/sources.list.local and edit this file. > Then you have to call make cd_image (patch pending) or make initrd to > build installer images. > > gaudenz I did just commit the patch for cd_image. -- Debian GNU/Linux Operating System By the People, For the People Chris Tillman (a people instance) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building boot images with boot-floppies on PowerMac
On 1 Jul 2003, Gaudenz Steinlin wrote: > Am Die, 2003-07-01 um 14.40 schrieb [EMAIL PROTECTED]: > > > I would need to build _everything_, unless there are binaries some place > > for oldworld powermacs. The build document is a little terse, and I > > don't see a list of udebs at all. > No you don't have to do that. Read build/README. Basically you have to > copy build/sources.list to build/sources.list.local and edit this file. > Then you have to call make cd_image (patch pending) or make initrd to > build installer images. What about all those udebs? Don't I need those too? -- 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]
Re: Building boot images with boot-floppies on PowerMac
Am Die, 2003-07-01 um 14.40 schrieb [EMAIL PROTECTED]: > I would need to build _everything_, unless there are binaries some place > for oldworld powermacs. The build document is a little terse, and I > don't see a list of udebs at all. No you don't have to do that. Read build/README. Basically you have to copy build/sources.list to build/sources.list.local and edit this file. Then you have to call make cd_image (patch pending) or make initrd to build installer images. gaudenz signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Building boot images with boot-floppies on PowerMac
On Mon, 30 Jun 2003, Eduard Bloch wrote: > > Yes. And when you do, you have to know what you are doing. I think, D-I > will be the perfect toy for you. Use it, and stop bitching about > boot-floppies. I've updated my CVS of it, read the recommended docs and some not recommended. I would need to build _everything_, unless there are binaries some place for oldworld powermacs. The build document is a little terse, and I don't see a list of udebs at all. -- 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]
Re: Building boot images with boot-floppies on PowerMac
On Mon, 30 Jun 2003, Eduard Bloch wrote: > #include > * [EMAIL PROTECTED] [Sat, Jun 28 2003, 11:16:30AM]: > > > The "arch maintainer" for what? My problem is with b-f, according to > > those documents you mention, this list is the right place. > > For the problem with your powerpc kernel package which was your initial > problem. > > > > > > 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. > > > > My initial problem is that that is precisely what I cannot do. If I can > > And that is, precisely, and edge and chicken problem. The build cannot > take the kernel images since they are not in the archive, but it uses > the archive structure to decide which package to take (expecting > "stable" package). And the packages do _not_ land in the stable branch > immediately because the distro is frozen. So you stuff _will_ be > buildable when r2 has been released and the SRM accepted the > kernel-image* and according pcmcia-modules-* packages to stable. Until > this happens and since you are using a development version of > boot-floppies (*), please stop fighting windmills. The _only_ reason I've tried anything other than the stable version is this: The stable version did not work. See my first post in this thread. When I posted the initial problem here, someone (Chris, I think) said to use one of the other versions: I think he said testing, but no matter, I've tried testing and I've tried CVS. If the stable version worked, I'd be content. I want to build a stable installation with only _my_ changes. I have r1 ISOs here: if you think those will work, I will burn off as many more as I need and/or extract the files from them, > > (*): or an outdated/wrong version, bug FTP maintainers, and this is > another story > > > do that, then I have a base to work on. > > As said, your work won't be honored enough. > > > > > 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. > > > > I am a user. I'm one of many who's been using Red Hat Linux for years > > (in my case since some time in '96), who's been helping out on the > > various Red Hat support lists, and who doesn't like recent changes to > > Red Hat's business model. > > Fine. Comming back to your mkisofs example, it's typical daily job for a > normal user to recompile mkisofs again and again? I am using b-f source only because when I tried to "apt-get install" I didn't find a package to install. > > > > > > 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? > > > > Certainly, it's tool, but I don't see that it has much similarity to > > cdrecord;-) > > Oh, please, you tried to escape the correct answer. > > > > > 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 think you're concentrating on differences, I see similarities. As a > > I do not concentrate on anything or close my eyes, I just tell you the > facts. Please estimate the level of complexity in the cooperation of > different tool, platforms specifics, etc. > > > user, I don't care for specs, I care for results. Both take some data > > There won't be any results if you break with the roots. > > > (files), fiddle round and create files containing essentially the same > > data structured differently. > > With this attitude you can argument even for LFS. > > > As for you being the cdrtools comaintainer, that doesn't carry much > > weight: I have used mkisofs and cdrecord, I know what they do. I don't > > care how they do it, though you might;-) > > I did not say cdrecord. It was your idea to distract from the > KDE-vs.-single-tool argument. > > > > > 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 co
Re: Building boot images with boot-floppies on PowerMac
#include * [EMAIL PROTECTED] [Sat, Jun 28 2003, 11:16:30AM]: > The "arch maintainer" for what? My problem is with b-f, according to > those documents you mention, this list is the right place. For the problem with your powerpc kernel package which was your initial problem. > > > > 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. > > My initial problem is that that is precisely what I cannot do. If I can And that is, precisely, and edge and chicken problem. The build cannot take the kernel images since they are not in the archive, but it uses the archive structure to decide which package to take (expecting "stable" package). And the packages do _not_ land in the stable branch immediately because the distro is frozen. So you stuff _will_ be buildable when r2 has been released and the SRM accepted the kernel-image* and according pcmcia-modules-* packages to stable. Until this happens and since you are using a development version of boot-floppies (*), please stop fighting windmills. (*): or an outdated/wrong version, bug FTP maintainers, and this is another story > do that, then I have a base to work on. As said, your work won't be honored enough. > > > 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. > > I am a user. I'm one of many who's been using Red Hat Linux for years > (in my case since some time in '96), who's been helping out on the > various Red Hat support lists, and who doesn't like recent changes to > Red Hat's business model. Fine. Comming back to your mkisofs example, it's typical daily job for a normal user to recompile mkisofs again and again? > > > > 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? > > Certainly, it's tool, but I don't see that it has much similarity to > cdrecord;-) Oh, please, you tried to escape the correct answer. > > > 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 think you're concentrating on differences, I see similarities. As a I do not concentrate on anything or close my eyes, I just tell you the facts. Please estimate the level of complexity in the cooperation of different tool, platforms specifics, etc. > user, I don't care for specs, I care for results. Both take some data There won't be any results if you break with the roots. > (files), fiddle round and create files containing essentially the same > data structured differently. With this attitude you can argument even for LFS. > As for you being the cdrtools comaintainer, that doesn't carry much > weight: I have used mkisofs and cdrecord, I know what they do. I don't > care how they do it, though you might;-) I did not say cdrecord. It was your idea to distract from the KDE-vs.-single-tool argument. > > > 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. > > I don't understand what you're saying here. Doesn't matter. > > Redhat does not have multiple kernels (does it?), so many installation > > ways withing the first stage installer, etc. > > Red Hat has many kernels for IA32. I'm not sure what the latest Yet another distraction. How many do you select when starting the installer? > I've seen > i386 > i386-BOOT > i586 > i586-smp > i686 > i686-smp > i686-enterprise > athlon > athlon-smp > athlon-enterprise We have a similar set of kernels, the user is free to install them. After the base system and the installation kernel has been installed. > RHL is also available for other architectures, to be sure not as many as > Debian. YEAH! And exactly here is the problem. Redhat supports only the "new" architectures which don't create much trouble. > If I w
Re: Building boot images with boot-floppies on PowerMac
On Thu, 26 Jun 2003, Eduard Bloch wrote: > #include > * [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. I've read (several times) README, README-Overview (nothing relevant) and README-CVS. It should have been obvious to you when I submitted the patch that I'd read this last, because the patch complies with your requirements. The "arch maintainer" for what? My problem is with b-f, according to those documents you mention, this list is the right place. > > > 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. My initial problem is that that is precisely what I cannot do. If I can do that, then I have a base to work on. > > > 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. I don't have any great objection to trying d-i on the Macs. Are there prebuilt binaries some place? > > > > 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. I am a user. I'm one of many who's been using Red Hat Linux for years (in my case since some time in '96), who's been helping out on the various Red Hat support lists, and who doesn't like recent changes to Red Hat's business model. >From discussions we had on Red Hat's lists, a fair few of us have decided to move to Debian, I think a couple decided on other distros, though with the SCO fiasco they may be rethinking the U-L consortium. They're not new to Linux, they are amongst the most experienced users Red Hat had, many have RHCE certification. I don't speak for them, but I often try to argue the case for less capable users. > > > > 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? Certainly, it's tool, but I don't see that it has much similarity to cdrecord;-) > > 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 think you're concentrating on differences, I see similarities. As a user, I don't care for specs, I care for results. Both take some data (files), fiddle round and create files containi
Re: Building boot images with boot-floppies on PowerMac
#include * [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 mi
Re: Building boot images with boot-floppies on PowerMac
On Wed, 25 Jun 2003, Eduard Bloch wrote: > Feel free to create a such thing, I won't accept it in the "stable" > branch. Here is a patch to allow user customising without changing any source at all. It doesn't address any other problems, it simply eliminates the need to edit the config file itself. Kultarr:~/cvs/bf/boot-floppies# cvs -q diff -u Index: README === RCS file: /cvs/debian-boot/boot-floppies/README,v retrieving revision 1.30 diff -u -r1.30 README --- README 28 Feb 2002 21:37:29 - 1.30 +++ README 26 Jun 2003 06:50:54 - @@ -51,6 +51,8 @@ (The font reduction process needs to run under a UTF-8 locale. It doesn't much matter which one; en_IN.UTF-8 was just a random choice.) +Configuration ovverides for config can be stored in $HOME/boot-floppies/config + Whenever you are setting up boot-floppies for building on a new system, you need to follow these steps: Index: config === RCS file: /cvs/debian-boot/boot-floppies/config,v retrieving revision 1.170 diff -u -r1.170 config --- config 22 Feb 2003 16:55:16 - 1.170 +++ config 26 Jun 2003 06:50:54 - @@ -227,6 +227,7 @@ # Empty string for no, anything else for yes. CLEAN_RELEASE_DIR_AFTER_TAR = +include $(HOME)/boot-floppies/config # export MAINTAINER="1name 2name <[EMAIL PROTECTED]>" # For debuging set these defines Index: debian/changelog === RCS file: /cvs/debian-boot/boot-floppies/debian/changelog,v retrieving revision 1.1361 diff -u -r1.1361 changelog --- debian/changelog23 Apr 2003 02:37:16 - 1.1361 +++ debian/changelog26 Jun 2003 06:51:10 - @@ -7,6 +7,7 @@ - kernel 2.2.22 on alpha, i386 - installation from some USB and FireWire devices possible [i386] - pt removed on i386 floppy (only floppy version) +- Read optional config overrides from $(home)/boot-floppies/config * Matthew Vernon: - remove an unhelpful and incorrect paragraph about ssh since debconf Kultarr:~/cvs/bf/boot-floppies# -- 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]
Re: Building boot images with boot-floppies on PowerMac
On Wed, 25 Jun 2003, Eduard Bloch wrote: > #include > * [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
Re: Building boot images with boot-floppies on PowerMac
#include * [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 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. > /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). > 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. > 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. > 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. > 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. > 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. > 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. MfG, Eduard. -- Zeit fuer Bloedsinn zu haben, bedeutet noch lange nicht, ihn auch zu machen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building boot images with boot-floppies on PowerMac
On Mon, 23 Jun 2003, Eduard Bloch wrote: > #include > * [EMAIL PROTECTED] [Mon, Jun 23 2003, 07:19:54AM]: > > > /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 > > make[1]: *** [linuxnewpmac.bin] Error 1 > > make[1]: Leaving directory `/root/cvs/bf/boot-floppies' > > make: *** [build] Error 2 > > According to madison's output, the package is in unstable only. The > reason may be some temporary RC bug that prevented the package from > beeing accepted in Woody. > > > > 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 I: downloading packages modconf, modutils, whiptail-utf8 I: this arch/subarch supports PCMCIA, downloading pcmcia-cs I: extracting packages into driver extract area /var/tmp/boot-floppies/extract-tmp-529 I: tarring pcmcia materials into incorporated tarball, /var/tmp/boot-floppies/drivers-529/pcmcia.tgz I: removing unneeded message catalogs from modconf I: patching modconf to work with LANG_CHOOSER I: moving from extra area into staging area for driver tarball, /var/tmp/boot-floppies/drivers-529 I: finishing up /var/tmp/boot-floppies/drivers-529 I: moving /var/tmp/boot-floppies/drivers-529 into driverspmac.tgz I: splitting drivers into floppy-sized chunks 1440+0 records in 1440+0 records out 1440+0 records in 1440+0 records out I: downloading kernel-image-2.4.18-newpmac I: downloading PCMCIA module package, 'pcmcia-modules-2.4.18-newpmac' I: Validating /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release I: Validating /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 make[1]: *** [linuxnewpmac.bin] Error 1 make: *** [build] Error 2 real27m8.803s user11m56.990s sys 5m3.070s Kultarr:~/testing/boot-floppies-3.0.23# The current position is; Woody fails CVS fails Sarge fails. 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. I don't know what kernel versions to use for what, or OTOH how to build my own kernels so as to get things in sync. 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. 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. 3. Maybe source a site configuration file from /etc/bootfloppies/ where the results of steps 1 and 2 can be adjusted. 4. Source a personal configuration file for further fine-tuning. 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 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. > > What should be in stable is working tools that may be used to create the > > binaries created;-) How else can uses enjoy their GPL-given rights? > > It should. My bug report against ftp.debian.org has been closed quickly, > so blame those guys. -- 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]
Re: Building boot images with boot-floppies on PowerMac
#include * [EMAIL PROTECTED] [Mon, Jun 23 2003, 07:19:54AM]: > /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 > make[1]: *** [linuxnewpmac.bin] Error 1 > make[1]: Leaving directory `/root/cvs/bf/boot-floppies' > make: *** [build] Error 2 According to madison's output, the package is in unstable only. The reason may be some temporary RC bug that prevented the package from beeing accepted in Woody. > > 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. > What should be in stable is working tools that may be used to create the > binaries created;-) How else can uses enjoy their GPL-given rights? It should. My bug report against ftp.debian.org has been closed quickly, so blame those guys. MfG, Eduard. -- *patsch* was bin ich bloed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building boot images with boot-floppies on PowerMac
On Sun, 22 Jun 2003, Chris Tillman wrote: > On Sun, Jun 22, 2003 at 10:55:48AM +0800, [EMAIL PROTECTED] wrote: > > I have done these things: > > apt-get source boot-floppies > > cd .. > > vim config > > # to change mirror, local directories., maybe one to two other things > > # Having alread had troubles like this, I left the kernel selections > > # well alone. > > make check # OK > > time make release > > > > It failed thus: > > I: Validating > > /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release > > I: Validating > > /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 > > make[1]: *** [linuxnewpmac.bin] Error 1 > > make[1]: Leaving directory `/root/boot-floppies/boot-floppies-3.0.22' > > make: *** [build] Error 2 > > > > real23m35.152s > > user12m16.050s > > sys 5m0.340s > > Kultarr:~/boot-floppies/boot-floppies-3.0.22# > > I see you have 3.0.22, which IIRC had this bug. Try getting 3.0.23 > (from unstable), or better yet do a cvs checkout from > cvs.debian.org/boot-floppies, which has 3.0.24-almost. I did that after my initial report. It fails thus: ./kernel.sh /archive/debian/download 2.4.18 newpmac I: downloading kernel-image-2.4.18-newpmac I: downloading PCMCIA module package, 'pcmcia-modules-2.4.18-newpmac' I: Validating /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release I: Validating /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 make[1]: *** [linuxnewpmac.bin] Error 1 make[1]: Leaving directory `/root/cvs/bf/boot-floppies' make: *** [build] Error 2 real26m26.481s user12m18.430s sys 4m58.800s Kultarr:~/cvs/bf/boot-floppies# > Stable still has 3.0.22. Is there a reason 3.0.23 never moved to > stable, Eduard? What should be in stable is working tools that may be used to create the binaries created;-) How else can uses enjoy their GPL-given rights? -- 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]
Re: Building boot images with boot-floppies on PowerMac
On Sun, Jun 22, 2003 at 10:55:48AM +0800, [EMAIL PROTECTED] wrote: > I have done these things: > apt-get source boot-floppies > cd .. > vim config > # to change mirror, local directories., maybe one to two other things > # Having alread had troubles like this, I left the kernel selections > # well alone. > make check # OK > time make release > > It failed thus: > I: Validating > /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release > I: Validating > /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 > make[1]: *** [linuxnewpmac.bin] Error 1 > make[1]: Leaving directory `/root/boot-floppies/boot-floppies-3.0.22' > make: *** [build] Error 2 > > real23m35.152s > user12m16.050s > sys 5m0.340s > Kultarr:~/boot-floppies/boot-floppies-3.0.22# I see you have 3.0.22, which IIRC had this bug. Try getting 3.0.23 (from unstable), or better yet do a cvs checkout from cvs.debian.org/boot-floppies, which has 3.0.24-almost. Stable still has 3.0.22. Is there a reason 3.0.23 never moved to stable, Eduard? -- Debian GNU/Linux Operating System By the People, For the People Chris Tillman (a people instance) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Building boot images with boot-floppies on PowerMac
I have done these things: apt-get source boot-floppies cd .. vim config # to change mirror, local directories., maybe one to two other things # Having alread had troubles like this, I left the kernel selections # well alone. make check # OK time make release It failed thus: I: Validating /archive/debian/download/var/lib/apt/lists/debootstrap.invalid_dists_woody_Release I: Validating /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 make[1]: *** [linuxnewpmac.bin] Error 1 make[1]: Leaving directory `/root/boot-floppies/boot-floppies-3.0.22' make: *** [build] Error 2 real23m35.152s user12m16.050s sys 5m0.340s Kultarr:~/boot-floppies/boot-floppies-3.0.22# What do I need to change? -- 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]
