Re: RPM vs DEB vs Slackware-like tgz
Alexander E. Patrakov wrote: > Gerard Beekmans wrote: > >>> Yes. Note that I have not evaluated pacman. >>> >> Do you by chance have any plans or desire to do so in the near future? >> > > Not in the nearest future--too busy with bureaucracy that surrounds > presenting > the dissertation (scheduled for July, 3). > > >>> What's even more important for educational purposes, Debian rules are >>> incoherent >>> between various Debian packages. >>> >> How does RPM differ in that regard? Couldn't RPM spec files (in theory?) >> suffer from the same problem depending on who writes them? >> > > RPM doesn't have this amount of additional layers of almost-mandatory helpers > for getting dependencies right, and the "debconf" tool for interactive > package > configuration. As I said, a few Debian packagers do things by hand, some use > debhelper, some call cdbs (that doesn't even contain the explicit build > instructions, but is suitable only for simple CMMI-like packages), and there > are > other options. > > 2 additional benefits to rpm: http://rpmlint.zarb.org/cgi-bin/trac.cgi rpm lint, to help keep filesystem clean of no-longer used files. http://wiki.mandriva.com/en/Development/Howto/Spec-Helper spec-helper, a set of scripts that assists in making the rpms to a consistent format. While many people don't like Mandriva, they have developed a set of tools that work very well, and made them open source. little things like the spec-helper script are valuable for making a "distro" with consistent package manager spec files. [ Mandriva falls short on the package description end. ] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
Alan Lord wrote: > J. Greenlees wrote: > >> Gerard Beekmans wrote: >> >>> Rather than re-invent the wheel, would a program like BlueFish be a >>> possible candidate? I haven't used this program in over half a decade >>> but I hear it supports XML. It may be a possible alternative to at least >>> look into before deciding on a custom "in-house" application. >>> >>> Gerard >>> >>> >> Yes, Bluefish has some support for XML. It at least has syntax highlighting. >> how well it would work with the LFS Book's schema is not clear, but it >> may work fine. >> > > I've used Bluefish for quite a while now. It's a decent editor for most > languages. > > The "missing link" is any sort of integration with SVN, CVS, GIT or Bzr > etc... > > One could always use Eclipse with the subclipse plugin. Works a treat > for me. > > Al > > ~shudder~ last time I installed support for Java [ Sun's jre-1.6 ] I physically noticed an increase in time for loading any application, even non Java apps. and eclipse requires Java. [ AMD Athlon AM2 3800+ 1 GB ddr2 @ 533 MHz onboard Sata for drive interface. ] I personally avoid software that has that much of an effect on performance. :D Jaqui lspci output: 00:00.0 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:00.5 PIC: VIA Technologies, Inc. K8M890CE I/O APIC Interrupt Controller 00:00.7 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:03.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 02:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
Gerard Beekmans wrote: > Hi all, > > Take a look at http://wiki.linuxfromscratch.org/lfs/wiki/LFSFuture > > Looking forward to reading you guys' comments. > > Gerard > F.W.I.W. A Not-For Profit cost here in BC comes to around $500. I have been a member of a couple of them, founding member of one. I know it's different in different provinces, but finding the lowest cost province for registering and doing it there, then getting a license for operating across the country covers all of Canada. The only requirement would be a "Board Member" resident in the province of registration. Since that means a Board Member "for life" in effect, it really should be Gerard. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
Gerard Beekmans wrote: > Rather than re-invent the wheel, would a program like BlueFish be a > possible candidate? I haven't used this program in over half a decade > but I hear it supports XML. It may be a possible alternative to at least > look into before deciding on a custom "in-house" application. > > Gerard > Yes, Bluefish has some support for XML. It at least has syntax highlighting. how well it would work with the LFS Book's schema is not clear, but it may work fine. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Not-For-Profit (part of Future of LFS discussion)
TheOldFellow wrote: > Could some kind American or Canadian soul post a link to something that > explains this concept as it applies to a corporation? I think some of us > Non-NA peeps could do with an understanding of that it means, and IANAL! > I presume it cheaper than a Delaware Corporation :-) > > For what little it's worth, I have assumed that any contribution I have > made via these Usenet lists is Public Domain unless it contains a > specific copyright notice, so I can't see how I could assign it to a > Foundation. In so far as it has been incorporated into an LFS Book, I > have already, by the act of contributing as an editor, assigned the > copyright to the book's copyright holder as defined in the Prologue to > the book in question. Or have I? I certainly intended to. > > It seems to me that this is not connected too intimately with the other > discussions. But really does merit getting right before we invest too > much in the rest of it. I have been unhappy for some time (years) that > copyright to the LFS book resides with Gerard, not because I don't want > him to have it, but because I am unsure of who would inherit it, or to > whom it might be assigned by him 'in extremis' (several scenarios to > consider here). Here is a link to that on the Government of Canada website, focussed on BC, annd direct to thier faq comparing business types. http://bsa.canadabusiness.ca/gol/bsa/site.nsf/en/su06803.html#a1 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: > >> Alexander E. Patrakov wrote: >> >> ~snip~ >>> 3) When package management enters the book, include a procedure for >>> building >>> packages for a lower CPU (basically, import config.site from the LiveCD and >>> adjust toolchain and perl configure arguments as done there) and >>> transferring >>> LFS and subsequent packages to a different machine. >>> >> Disagree. This is something for a hint or something similar to the user >> notes >> on BLFS. Trying to address every corner case in the book would be >> distracting >> to the majority of users. >> > > I disagree that this is a corner case. It came up several times on the livecd > list, so this has to be addressed somehow (possibly even by explicitly > recommending to use a binary distro). I remember seeing frequent questions on using the livecd os on the hard drive, by moving it over on the livecd list. [ and the requirements for getting the process to do so ] The moving a built lfs os from one system to another being a completey different issue, and shouldn't need much explanation, since it is pretty much what is happening with the live-install method used by most livecd based distros. [ 20 minute install of a distro, with KDE and tons of bloat just seems wrong somehow ;) ] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8518 - in trunk/BOOK: . chapter01 prologue
Dan Nicholson wrote: > On Fri, Apr 11, 2008 at 11:49 PM, J. Greenlees > <[EMAIL PROTECTED]> wrote: > >> Dan Nicholson wrote: >> >> > bash - Not needed for actual building, but glibc's ldd and tzselect >> > need either bash or ksh to work. The values will be substituted at >> > configure time. I don't know what happens without them, and it's >> > probably not that important in Ch. 5 if those utilities aren't there. >> > However, we create the LFS user with /bin/bash as the login shell, and >> > this can't be substituted as is because we set up the environment >> > through the bash initialization files. >> > >> >> Yet another minor issue with PCLinuxOS as a build environment, the >> environment set up following the book is not a login shell. >> [ only mentioning it as a f.w.i.w. ] >> > > Sure it is. You switch to the lfs user with `su - lfs'. That creates a > login shell using the shell listed in the passwd database. If > PCLinuxOS' su doesn't follow that trend, I don't know if there's a lot > we can do about that. > > -- > Dan > And even the LFS Livecd will toss a "Not a login shell, try exit instead" when given a logout. I rarely get more than an hour or two to actually work on a build in one session, so I always wind up having to end a session, or I wouldn't have noticed. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
Alexander E. Patrakov wrote: > J. Greenlees wrote: > >> and this is done manually typing in, or copy and paste of the build >> commands? >> or is it scripted to remove the manual input [ slow point ] requirement? >> > > It is completely scripted, see the LiveCD SVN repository. I can't afford any > uncertainty due to typos for official LiveCD releases. > > I figured that, and understand completely. but a manual build is going to take quite a bit longer, and the book recommends a manual build the first time, for the problem solving that give the user a chance to learn more I suspect. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
Alexander E. Patrakov wrote: > J. Greenlees wrote: > >> 8 hour build time? unless using the build scripts I don't think it's >> possible without brand spanking new hardware with massive amounts of ram. >> > > ums.usu.ru (before it died in November, 2007 due to voltage spike): Pentium > IV > 2.4 GHz (without hyperthreading), Intel S845WD1-E server board, 512 MB of > RAM, > 120 GB IDE hard disk. Bought in May, 2003, not upgraded since then until the > complete replacement in November, 2007. Able to build LFS LiveCD (the full > version) in 12 hours. So we are not speaking about brand new hardware. > > And the "8 hours" figure has the following origin: it's the maximum amount > that > we can realistically expect a typical desktop computer to stay on, so one > doesn't have to bother with exiting and reentering the build environment > (that > is poorly documented in the book, probably because it is not supposed to be > done). > > and this is done manually typing in, or copy and paste of the build commands? or is it scripted to remove the manual input [ slow point ] requirement? >>> Hard disk space is a mandatory requirement. >>> Disk requirement on IPCop is 2 GB free space before building. >>> Indicative minimal memory could be somewhere between 128 MB. >>> Recommended memory to build should more than 256 MB >>> I have mesured IPCop 1.4 (is with gcc-3.3) building time on the same machine >>> with 128 MB and 512 MB. 128 MB require 3 time more to build than with 512 MB >>> memory. >>> > > We are talking about a bit different things. The paragrapk above is talking > about building gcc-3.3 based IPCop from itself - that's fine. But building > gcc-4.x with gcc-3.3 triggers a known bug in gcc-3.3 that leads to huge > consumption of memory (above 512 MB). > > >> and the learning opportunities for building on a more limited resource >> system are greater, you run into problems from the limitations. >> > > Let me just throw your child into water and say "he learns swimming" (bad > joke: > I can't swim). No, learning must be gradual, the reader must see a > trouble-free > book first and _then_ experiment. > That's how I learned to swim, just jumped right into the pool in the back yard. :D still can't float, not a good swimmer on top of the water, but almost a fish under water :D -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
> I agree for "586-class computers with only 16 MB" would give bad result if > any. > I have build IPCop in the past on a 586-class laptop with 160 MB memory in > approximatly three days. > well, an i586 with 128 mb ram and a total hd space of 3 GB took 3 days just for pass1 of chapter 5 with a recent build I did. [36 hours just for gcc to build] >> P.S. I accept the challenge to "try that with a regular distribution". >> >> Proposal: >> >> 1) Remove this advertisement. >> >> 2) List hardware requirements (CPU, RAM, hard disk space) on the same page >> > as > >> software host requirements, or immediately before it. Good idea. >> These requirements >> > should > >> be set so that the total build time (including all testsuites) is less >> > than 8 > >> hours, and that the build process never needs to get into swap (the worst >> > case > >> seems to be Chapter 5 gcc Pass1 when starting from a host that is based on >> > gcc-3.3). > 8 hour build time? unless using the build scripts I don't think it's possible without brand spanking new hardware with massive amounts of ram. > Hard disk space is a mandatory requirement. > Disk requirement on IPCop is 2 GB free space before building. > Indicative minimal memory could be somewhere between 128 MB. > Recommended memory to build should more than 256 MB > I have mesured IPCop 1.4 (is with gcc-3.3) building time on the same machine > with 128 MB and 512 MB. 128 MB require 3 time more to build than with 512 MB > memory. > > Time should not be a requirement but a guide line. > Just say it take x time with this cpu, memory and disk. > > good point. > We all know the problem with heavy swap usage but it may happen a small part > goes permanently in swap without a big slowdown. This happen to me on alpha > (160 MB memory). > Until that part remain permantly in swap, this is not a problem. > and the learning opportunities for building on a more limited resource system are greater, you run into problems from the limitations. Even though the direction seems to be to make LFS more a build your own distro guide, the learning aspect can't be ignored. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8518 - in trunk/BOOK: . chapter01 prologue
Dan Nicholson wrote: > yacc (bison) - Definitely needed since we patch the bash parse.y file > in Ch. 5 and yacc will need to be rerun. Could add bison to Ch. 5 > before bash, but IMO it's easier for the host to just install bison. > > yup. definitely easier, that was how I addressed the missing yacc with PCLinuxOS as build environment. > bash - Not needed for actual building, but glibc's ldd and tzselect > need either bash or ksh to work. The values will be substituted at > configure time. I don't know what happens without them, and it's > probably not that important in Ch. 5 if those utilities aren't there. > However, we create the LFS user with /bin/bash as the login shell, and > this can't be substituted as is because we set up the environment > through the bash initialization files. > Yet another minor issue with PCLinuxOS as a build environment, the environment set up following the book is not a login shell. [ only mentioning it as a f.w.i.w. ] Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
Alexander E. Patrakov wrote: > Dan Nicholson wrote: > >> You really need gawk, not mawk. >> > > Then please add gawk and bison in Chapter 5 before binutils, to accomodate > Debian-based LiveCDs and PCLinuxOS, respectively. and here I was thinking that a note that bison is required to be installed if using PCLinuxOS as host would be sufficient. The distro does fine by adding their package. [ fewer changes to build process needed thn ] Even the livecd of PCLinuxOS will allow you to install bison into the os and build with it. [ though building with the bloaty PCLinuxOS as livecd means you need a lot of ram or large swap partition. ] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: init-ng, cmake
TheOldFellow wrote: >> runit is better. (IMnsHO) >> >> http://smarden.org/pape/ >> >> R. oh boy, more to look at and test. :D The joys of looking at all the possibilities, just to find the tools that you prefer to use. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > J. Greenlees wrote: >> Personally, on the svn version I'm doing a test build with, I went lilo >> before starting and made sure I had the sources and dependencies sources. >> [ lilo depends on nasm according to the hint on the website for "beautifying lilo" ] > Are you sure? The LiveCD contains LILO and uses bin86, bot nasm, to build it. Nope, I'm not sure. I got that dep from: http://www.linuxfromscratch.org/hints/downloads/files/PREVIOUS_FORMAT/lilo.txt 1. What do you need lilo-22.2 or lilo-22.3.2 nasm-0.98.34 (just install nasm the way you usually install packages) 640x480x16 bmp file a hint that is up for adoption so is badly outdated. > This, by itself, looks right. Let's see if the book and our resources can bear this. and what Jeremy is doing by including options in the dev version is a start to that. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
init-ng, cmake
I decided that I wanted to take a look at init-ng while doing my current test build with the latest svn version of the book. once the build is done I'll be able to decide if it is worth using and adding a hint for. But, in looking at it, and the dependencies, init-ng requires cmake to build. According to the cmake site, KDE requires cmake to build. While KDE is definately BLFS not LFS, I couldn't find where cmake is mentioned at all in BLFS. init-ng, supposed to be an asynchronous initialization, that is faster than the sysv style init currently used in the book. The docs indicate that it can convert the sysv init scripts, and that runing it's make after installing a new app with create the init script for the app. [ boy, will these claims be fun to test ;) ] Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Jeremy Huntwork wrote: > I'm not sure if the community has decided what direction to take here. I > need to get some kind of boot loader into the jh branch (currently there > is none) so I will be playing around with a more flexible approach to > installing one there. > Personally, on the svn version I'm doing a test build with, I went lilo before starting and made sure I had the sources and dependencies sources. [ lilo depends on nasm according to the hint on the website for "beautifying lilo" ] > Basically, I'm going to create a bootloader sub-section inside chapter 8 > "Making the LFS System Bootable". Seems appropriate. The section will > contain (at least for now) instructions for patched grub legacy and lilo > and allow a user to make a choice. The sub-section could also point to > other alternatives, even listing 'use the host's bootloader > configuration' as an option. > > Maybe then the community can decide if it wants to merge the whole > section over, or just use bits of it, or even go a completely different > direction. With the direction for LFS discussions, isn't presenting the options in keeping with the general input for the direction, which was to make LFS more a guide to creating a distro if I remember correctly than just a guide to building a linux system? Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Which type of LFS should I choose on 64bit system
Alan Lord wrote: > > There are too many issues and non-supported applications for native > 64bit platforms. So you end up needing to build a multi-lib system (both > 64 and 32bit libraries) which, to me anyway, feels like bloat that I can > do without. true > Also, I have yet to see any decent data that provides compelling reasons > such as performance improvement etc to make we want to go to 64bit. I'm, > sure the time will come, and maybe you have specific apps that would > really benefit from bigger address space etc, but I'm a "regular" kind > of Desktop user and there is more headache than benefit in it for me. exactly, right now 64 bit is really only usefull for two purposes, developing applications that use 64 bit, or servers. basic desktop use, stick with 32 bit, fewer build headaches and fewer issues with additional functionality, such as video codecs. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
Zachary Kotlarek wrote: > > > Maybe I'm missing something, but the LSB Core specification is pretty > sparse: > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/book1.html and that is where it should stop to be the base they intend. everything else makes it a DISTRO standard. LFS isn't a distro in the common meaning of the term, since it is not a collection of software pre-built and ready to go. compliancy to the LSB is, and should be, entirely up to the one building their system. Though including a link to the LSB and FHS in the book for those who want to build a compliant system is a good thing to do. I only use the FHS section, since having everything laid out the same helps anyone new to the host find their way around it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Foundation Collaboration Summit
Bruce Dubbs wrote: > I have been invited to attend the Linux Foundation Collaboration Summit > taking place at the University of Texas Supercomputing Center in Austin, > TX from April 8 to 10, 2008. > > I applied using my LFS background and feel I will be representing the > community there. The agenda is at: > > https://www.linux-foundation.org/events/collaboration/program > > I will be attending the following sessions with LFS in mind: > > Open Source Legal Issues for Non Lawyers >(do we want/need to change out license) > > LSB Workgroup Meeting >(here I am interested in getting the directory layout updated. > I don't thing /usr/X11R6 is really appropriate any more.) There is more than just that holdover that is wrong the the FHS and with the LSB. [ at least in my opinion ] with the FHS: /media << new usrs think store music and videos, which is where MS stored them pre winxp, not removable disks / drives. This name is NOT clear and that lack does not help with adoption of GNU-Linux by more people. /mnt << if using /media, why bother with /mnt? if using /mnt then get rid of /media. 2 separate sections for mounting filesystems is a waste of effort. /opt << meant for third party applications, not those included in a distro? then why would any distro install anything into it? [ Suse, installs almost everything over the base system into it last time I checked to be specific. ] /proc << was this not being done away with in favour of /srv? With the LSB: Why would a BASE standrd not stop at the absolute minimum needed for a functioning system? The addition of package management [ for example ] to the LSB has made in no longer a BASE standard. If extras are going to be included, then call it a Linux DISTRO Standard, not a Base Standard. [ I for one ignore the LSB because it is not what it claims to be, a BASE for Linux.] LFS and DIY are much closer to being a base in the lack of extra software. Both sections need to be made as simple and clear as possible, with the absolute minimum required for a functional system to be base system standard. The additions to the LSB, while meant to promote support for Linux by commercial software houses, actually do nothing but polarize the community, since they pick one package over another, to the irritation of the supporters of the package(s) not picked. The infamous Vim / Emacs holy war being a good example of what the LSB is doing when they pick one package over another. A specific suggestion re the package manager, remove the reference to RPM in that section, and you remove the LSB from the dispute about which package manager is better. If the LSB just said packages must follow this format (format details as written, without reference to any specific package ) Anything that should be adopted by all distros must remain non-controversial to truly be acceptable by all, the more specific the LSB gets, the less respect many people will have for it. Specific in software over the true base system being the issue. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
J. Greenlees wrote: > Alexander E. Patrakov wrote: >> 2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: >>> http://gag.sourceforge.net/ >> Requires Borland Turbo Assembler (available for MS-DOS only) in order >> to be recompiled. LFS cannot assume that this proprietary OS is >> installed. >> > hmm, I wonder if my borland Kylix3 enterprise edition has support for > that. unfortunately, it won't install on a system with a kernel version > above 2.4. > I know I have the free version of Kylix3 kicking around as well, but it > hits the same limitation re kernel version. I doubt it's actually the > kernel version, more likely the toolchain changes for the 2.6 kernel, > but it does not play nice even with an upgrade of os after install. > > I'll take a look at it in my [ sarcasm ] copious [/sarcasm ] spare time > and see if I can build it, and maybe port it to gcc. I just looked closer at gag, it still requires either lilo or grub to boot, it can't recognise the kernel image by iself. kills that idea. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > 2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: >> http://gag.sourceforge.net/ > > Requires Borland Turbo Assembler (available for MS-DOS only) in order > to be recompiled. LFS cannot assume that this proprietary OS is > installed. > hmm, I wonder if my borland Kylix3 enterprise edition has support for that. unfortunately, it won't install on a system with a kernel version above 2.4. I know I have the free version of Kylix3 kicking around as well, but it hits the same limitation re kernel version. I doubt it's actually the kernel version, more likely the toolchain changes for the 2.6 kernel, but it does not play nice even with an upgrade of os after install. I'll take a look at it in my [ sarcasm ] copious [/sarcasm ] spare time and see if I can build it, and maybe port it to gcc. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: > Hello, > > as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker), > due to recent changes in e2fsprogs, Grub-0.97 no longer works. Grub, Grub2, Lilo have been mentioned. A quick google search brings as result 3: http://gag.sourceforge.net/ GAG (initials, in spanish, of Graphical Boot Manager) is a Boot Manager program. It's loaded when the computer is turned on and allows you to choose the operating system you want to use. up to 9 operating systems, released under the GNU-GPL. Haven't looked at it yet. though result 6 of that search return looks much more interesting to me: http://gujin.sourceforge.net/ freshmeat description: Gujin is a PC boot loader which can analyze your partitions and filesystems. It finds the Linux kernel images available, as well as other bootable partitions (for *BSD, MS-DOS, Windows, etc.), files (*.kgz) and bootable disk images (*.bdi), and displays a graphical menu for selecting which system to boot. Gujin boots Linux kernel using the documented interface, like LILO and GRUB, so it doesn't need any other pre-installed bootloader. It can also directly load gzip'ed ELF32 or ELF64 files, with a simple interface to collect real-mode BIOS data. There is no need to execute anything after making a new kernel: just copy the kernel image file into the "/boot" directory, with a standard name. Gujin is written almost entirely in C with GCC, and it fully executes in real mode to be as compatible as possible. requirements: you will need also GCC-4.2.3 and Binutils-2.18 just a couple of other optons that can be concidered. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Alexander E. Patrakov wrote: > Greg Schafer wrote: >> Alexander E. Patrakov wrote: >>> does it >>> allow running arbitrary scripts on the DESTDIR contents before >>> actually creating a package? >> Um, I don't think so. However, while Pacman itself is written in C, the >> "makepkg" portion of the system is a Bash script which allows easy >> hackability. That's what allowed Alex Merry to write the fake_install() >> patch that I still use today. > > I.e., writing such patch would be easy. That's enough. There is a good perl based start to handling the differences in package manager formats. http://kitenet.net/~joey/code/alien/ It's often included as an option in the debian and rpm distros, to increase the ease of finding packages in a package manager format. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll results
Alexander E. Patrakov wrote: I.e., again, we have to learn more about > package management before attempting to write about it. > exactly why I didn't vote, I don't know enough to have any meaningful input :) Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
Gerard Beekmans wrote: > > If at the end of the day the current DocBook setup can no longer deliver > what we need, and nobody can find a way to make it work, then we'll have > to do what it takes to get the job done. Staying with > DocBook/XML/whatever is never a requirement. We'll use what we need to. > > G Most likely it wouldn't support the multiple options, as it's currently implemented. Making a DTD segment for each pm and having each pm tagged appropriately would enable keeping most of the current text intact. Since it's an XML format, one DTD for basic structure, with additional DTD for the different pms / other modules as selected. [ figuring the modular, custom book idea. ] If the user selects to use dpkg, then a small bit if DTD is added into the document headers to define th dpkg specific code blocks. The only issue is that the book sources will be much larger, having a section for each difference being supported. Using CSS to style the sections, can be one css for all versions, since if a particular item is never called it just gets ignored by the user agent. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning an overall direction for LFS
Jeremy Huntwork wrote: > Hello All, ~snip~ > Merging the projects is a good idea, but I think, for the sake of > customization and flexibility, it will still be good to break down LFS > into 'modules' as Alan Lord suggested. It will all still be a part of > the same whole and the workload combined, but the modularity will allow > for choice. I have a zip archive from a php-mysql web apps manual that has a php based script designed for authoring articles / books with multiple authors. older script, so not fully current, would need a lot of updating. The book authors keep copyright, naturally, but allow for use as in open source software, so it can be used as an idea / foundation for building the website to support this. [ multiple scripts in the archive, yet less than 400 KB in size. ] These scripts currently send not quite standards compliant html to the browser, missing some header elements for compliancy, which is an easy fix. They do not stop anyone needing assistive technologies from accessing the site as is. if anyone wants them, just send me a message and I'll attach the archive and send it to you. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: What if the book wasn't a book anymore
Alexander E. Patrakov wrote: > 2008/2/28, J. Greenlees <[EMAIL PROTECTED]>: >> Ok, how about something completely different then, go multimedia in a >> lot of the presentation of information. >> recordmydesktop, and the gtk interface for it will create ogg video >> clips of what you are doing on your desktop, with audio track for >> describing it verbally. A 20 Minute clip of installing PCLinuxOS is 25.7 >> MB, 5 fps and 33% audio video quality settings in the recording, looks >> and sounds just fine, you can even hear keystrokes used during the >> recording. > > And that costs $5 here to download. yup, and more in some areas of the world. > >> Use these to fill the website with what each application is used for, >> why it's configured the way it is to help draw more people to the >> project as well. It seems most people want their "learning" to be >> through video, with sites like http://showmedo.com/ being a prime example. > > Correct, that's a way to deliver information. It does work for a > single author. However, here you are wandering into the unexplored > territory of collaborated video editing. not really, collaborative video proofing, since if there was a set format that everyone followed there wouldn't need to be editing of it. >> This type of presentation would draw a lot more people who have never >> looked at linux though, so the Theora Vorbis-ogg video format is >> problematical if they only have windows. Miro media player works on all >> platforms and handles it fine for them ;) > > Also this means that we would automatically lose blind people from the > audience. The included audio will work for most visually impaired, but that is a good point.. I wonder if subtitles could be pushed into a screen reader somehow to answer that concern. > (sorry if I sound too critical about every new proposal--just don't > take it too seriously, the current situation is also not ideal) Not a problem, it was just my immediate thought on reading Gerard's post, since I have been looking at doing new-to-Linux-end-user type video clips and making them available cross platform. I didn't expect it to be a perfect idea, just one to help break the box open for people. :) personally, the livecd as a demonstration distro for building your own distro idea has my interest, though my time is limited with new business startup. [ lots of questions filling my head on how to implement a from source installer, that works with tarballs rather than having to extract them first. said installer to also be the package manager, so you would only need to put the tarball into a specific folder for it to be available for the distro.. patches for updates etc same way. ( end user friendly ) ] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: What if the book wasn't a book anymore
Gerard Beekmans wrote: > What if LFS wasn't in book form anymore. What if it's an interactive > program instead. A 100% merge of LFS, BLFS, ALFS, LFS. > > It starts with running the LFS program (be it a real program or > collection of scripts). What is now the LFS book is on-screen instead. > You read the chapter portions as you work your way through an installation. > > You still have 100% control but you can decide fully manual (today's > style) or fully automatic style (when you've done it before and you just > want to get the end result). > > Or a different example, you know you need a program installed. You > install it. Then you are left hanging: "Okay, now what. It's installed. > Somewhere. There are configuration files. Somewhere. I'm sure there is > documentation that answers those questions. Somewhere." > > Just some more food for thoughts. While we're discussing let's also take > the time to think outside the box. Abandon, at least in theory, anything > that is currently LFS, pre-conceived notions and otherwise, and see what > happens when we re-invent LFS and the way we do things. Ok, how about something completely different then, go multimedia in a lot of the presentation of information. recordmydesktop, and the gtk interface for it will create ogg video clips of what you are doing on your desktop, with audio track for describing it verbally. A 20 Minute clip of installing PCLinuxOS is 25.7 MB, 5 fps and 33% audio video quality settings in the recording, looks and sounds just fine, you can even hear keystrokes used during the recording. Use these to fill the website with what each application is used for, why it's configured the way it is to help draw more people to the project as well. It seems most people want their "learning" to be through video, with sites like http://showmedo.com/ being a prime example. distributing your proposed application on a live dvd would give space to include a lot of video clips about the software installing handing them the information you mention as lacking in not being presented. This type of presentation would draw a lot more people who have never looked at linux though, so the Theora Vorbis-ogg video format is problematical if they only have windows. Miro media player works on all platforms and handles it fine for them ;) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: What next? [Was: Re: LiveCD or No LiveCD?]
TheOldFellow wrote: > On Tue, 26 Feb 2008 14:29:43 -0700 > Gerard Beekmans <[EMAIL PROTECTED]> wrote: > >> True, LFS isn't targeted to those people > > It's always intrigued me to wonder: 'what if LFS was targeted at > Windows users?' or, 'how would a grade school kid build a linux > system?' > > Richard. > hmm, just think about the possibility.. a grade school computer class where they build lfs onto a system. we might actually have people knowing something about computers if they did that ;) Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: What next? [Was: Re: LiveCD or No LiveCD?]
Jeremy Huntwork wrote: ~snip~ > > I could let this thread continue for some more time, but I get the > impression that the ratio of votes will continue approximately the same. as with the last time this subject came up :) seems that while majority like the livecd project, getting more support isn't easy. > So the real question now becomes, where do we go from here? There have > been a few suggestions put forward as to what may help future > development and what will alleviate the original concerns brought up. I > will try to lay down what I recall: > > * Go back to the drawing board, so to speak. Start a new CD from scratch > that is minimal (and minimal means minimal, not just 'without X') and > re-define core concepts that the CD will adhere closely to. (For > example, as proof of the soundness of LFS, the CD should strictly adhere > to LFS. If we adopt this one aspect, we should also be able to make use > of ALFS development to produce the CD, instead of maintaining a full set > of separate scripts.) minimal software, maximum hardware supported? Even the no-source cd is viable, if the nic on the system is supported. Not every system has physical interface to add driver sources to the hd when running the livecd, laptops frequently have no floppy drive and damaged usb ports. My own old Dell insiron has both a floppy and cd, but if running the livecd there is no access to floppy, since they use the same bay in he box, the one usb port is damaged from usb devices being knocked around while plugged in, so the 4 thumb drives are not readily functional. From talking with the guys at Vancouver Laptop, that latter is an extremely common problem. ~snip~ > * Add an LFS-style document to the project that teaches how to create a > LiveCD from scratch. That sounds like a very useful addition to the whole LFS project set, expanding the "remasterme" from the livecd into a full blown book on building a livecd. I'm guessing one that is a minimal lfs system, so that additional functionality would be more in keeping with the overall design of lfs-blfs. > * Devise methods for users to more easily provide feedback and make it > easier to contribute as a whole. increasing participation levels is probably the hardest thing to do. most people online currently seem to be focussed on the social networking type activities, implementing any of which would require redesigning the website to draw people into activity there, rather than the email lists. > What are your thoughts on the above? And are there any other > suggestions, either new ones or ones that I missed? My only comments in addition, I'm going to be fairly busy for the next while, I'm in the midst of starting up my own web hosting business. Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD or No LiveCD?
Alexander E. Patrakov wrote: > 2008/2/25, Jeremy Huntwork <[EMAIL PROTECTED]>: > > Here is a problem: in order to support both accessibility (for blind > users) and UTF-8 at the same time, the CD has to boot into GNOME and > start Orca. There is no console-based solution that understands UTF-8. Odd, I just tested and in cli only I was able to create a text file, using touch, edit it to add content and it's encoding is utf-8 edited using ed I purposely make utf-8 the default encoding in every package, it seems to have enabled utf-8 in bash for me. Jaqui [ attached file is the file I made as a test ] This file, created with touch on my 64bit system. everything on the system, from local up set to. UTF-8 I'm pretty sure it will be UTF-8 encoded text file.-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD or No LiveCD?
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: > >> we can look into updating it when a change makes it necessary. > > Sorry, this doesn't work. Such change may be artificially delayed to the last > moment before the release (as it was the case with ata_piix pretending to > pick > up support for intel IDE controllers but actually failing for laptop drives > with > a host-protected area). Nobody will test it, and the end result would be a > faulty CD that, e.g., doesn't boot at all or doesn't see a hard disk for a > large > percentage of users. > Until two weeks ago I was short one power supply to test it on the laptop. though I have never had the ata_piix bug actually show up. [ gotta love having hardware die for laptops :( ] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Which list for Ticket reports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 M.Canales.es wrote: ~snip~ > I don't care about to what list the ticket posts are send, but please, send > it > to only one of them. > I agree, but also the cross posting that people do can be problematical. Since some people use the To and CC fields interchangeably it seems, it took a month of work to get filters to sort messages correctly for all the lists. [ which I lost when the athlon xp system crashed a month ago. :( ] Jaqui -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7QDjylMakk+oQ1oRAoOXAJ43XmniazbgYdC0ikB3kQhrkEWypwCfRTkb 31z5djG8G2LAZXrziNdvLWk= =ZdgF -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0 Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TheOldFellow wrote: > On Thu, 30 Aug 2007 11:14:37 -0700 > "Dan Nicholson" <[EMAIL PROTECTED]> wrote: > >> Now that 6.3 is finally done, I wanted to think about things that >> could be done for the 7.0 release. These are in addition to the normal >> updates/bug fixes/etc. > >> * LSB bootscripts - I'd like to shed the current custom bootscripts >> and move to the standardized LSB style. The advantages (to me) are >> standardization, removal of crufty custom functions and entry points >> in our current implementation, and managed service levels >> (dependencies in the script header mean you don't have to guess run >> numbers). > > > Just remember that there are a few of us who don't use sysvinit, and > don't want complex bad-standard (LSB) bootscripts. I want my system > up, fast, accepting login, and then all the other cruft (networking > for instance) can start while I'm typing my secure password :) > > R. > SSHH!! don't be mean about the loco standard boo-boo. After all a BASE standard is required, to bad the FSF's LSB group went about 10 billion light years beyond a base standard. [ when they started specifying applications they left a base standard behind. ie: should have a package manager, not MUST HAVE RPM SUPPORT. ] about the only part of LSB I'll implement is the file-system hierarchy, the rest is to far beyond a base standard to be usable as such. Jaqui -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG18z+ylMakk+oQ1oRAvMrAJ44m0VzLU0I8n5OVhX4pFFSp772lACfae9P qcIXXl88kVOoCq8ssDW0CkM= =42Ff -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
