Re: [lfs-dev] No IRC on the new server
On 31/01/12 14:37, Gerard Beekmans wrote: > > If the LFS IRC channels are to continue a new home will need to be found > for them. I'd like the current channel admins to give this some thought. > Let me know if you have any suggestions you would like to see implemented. Freenode seems to be where everyone else hangs out; and I'm sure they'd host the LFS project. "Freenode provides discussion facilities for the Free and Open Source Software communities, for not-for-profit organizations and for related communities and organizations." http://freenode.net/ Al -- Libertus Solutions http://www.libertus.co.uk -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
On 27/07/10 05:01, Jeremy Huntwork wrote: > It's interesting what logs will show. > > For instance, the access logs for community.linuxfromscratch.org show 117 > unique IP addresses viewing the site yesterday, and 76 unique IPs today. > Combine the two lists and there are a total of 167 unique IPs. Even taking > into account robots and individuals viewing the site from multiple locations, > that's still a lot of readers who were curious enough about it to go have a > look. > > And yet, we have very few people writing in to express their opinion. So it > appears that either they don't really care, or they're holding back from > speaking their mind because of some expectation of what will happen when they > do. Hi Jeremy et al :-) I had a quick look over the redmine site and thought it looked great. As I am not really involved in LFS at all any more I didn't feel as though I had any position to comment, but seeing as you asked I think it looks like a good step forward. I tend to just lurk here now and watch what is going on. The dialogue that is on-going between you, DJ & Bruce etc. is very interesting reading though - it's a great way to learn about apps; by reading others implementation experiences. Cheers Al (Alan Lord) LFS ID: 216 :-) -- The Open Learning Centre http://www.theopenlearningcentre.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
J. Greenlees wrote: >> >> 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 > I'm on a fairly old AMD 3200+ with 1G DDR2 and SATA2 hdd. My OS is Ubuntu Hardy (and whilst on Gutsy too) and I don't notice any performance impact. I just did a quick test. I was running the following apps before starting Eclipse: * Thunderbird apprx 20,000 messages and Lightning > 8 calendar collections on a caldav server. * Firefox 3 Beta 5 (8 tabs open, extensions: Firebug and Webdeveloper) * Skype * A VirtualBox VM running Hardy. * And of course all the desktop crud (compiz etc) that comes with Ubuntu. From raw, Eclipse loaded to fully working and connected to two remote SVN repos in about 45 seconds. (My Eclipse perspective had 6 tabs open and has loaded 8 plugins of it's own including). So it ain't that bad... Al -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
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 -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS (Educational Content)
Bruce Dubbs wrote: > Gerard Beekmans wrote: > >> Take a look at http://wiki.linuxfromscratch.org/lfs/wiki/LFSFuture > > In some cases, the changes proposed only require general agreement of what to > do > and the accomplishment of the task would be relatively easy. In others, the > changes would be pervasive throughout the book. > > This is my take on the issues: > > 1. Educational content > > This is still the most important aspect of the book. Adding more educational > content is always good. A couple of things that I would like to see is > elaboration of the meaning of what the configuration of packages mean with > the > emphasis on udev and the kernel. A discussion of modules vs compiling in > drivers would be useful. Can I also chirp in here? During the previous bout of words about LFSng, I made some suggestions regarding how the education aspect could be enhanced. There was some positive comments from a few other readers/contributors so I'd like it to be considered/discussed further please. This would change the structure of "the book(s)" and the way the groups are currently setup (LFS/BLFS) considerably. Here is the original text from 29/02/08: So perhaps the LFS project becomes some sort of "course" (and I use the term loosely). The "modules" of which, could be something like: * Learning the basics (Command Line, cmmi, security, toolchain, blah blah) * Scripting/Automating (A subject about how LFS gets built, the tools, the processes involved etc) [This is where PM would probably go too] * Basic Useful Applications (A sort of mini BLFS where we get networking, X and maybe Firefox/TB type apps installed) * Building your Distro (Completing the core build-out adding your chosen apps and utilities and configuring) * Making your Distro distributable (How to make a liveCD of "your distro", how to make an installer script...) So, I was trying to think at high level about how to keep, and hopefully improve, the educational value of LFS and to separate the current process into "course modules" at sensible points to allow them to be done "standalone" as it were. By splitting up it this way, I think we could get a wider community involvement as interested parties can 'scratch their own itch' without having to know about everything else. You never know, if we got something like this right, there could follow a financial opportunity to support the not-for-profit foundation idea by providing on-line testing/certificates etc... Just a random thought. Al -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS (Other comments)
Here's a few further comments "for the record". Bruce Dubbs wrote: > > 2. Package management and automation > > This is one of two difficult areas to address. How to present PM and how to > integrate it into the book will take a lot of time to reach consensus on the > approach to take. It would basically affect every page in Chapter 6. > It is PM (or rather lack of one) that drives users of LFS away, eventually at least. PM definitely "should" be optional rather than mandatory. > 3. Linux Standards Base > > This is more of a BLFS issue, but should be addressed in LFS as it sets a > foundation for the user's "distro." Things like FHS should also be discussed > as > a part of the intro to LSB. This is really not a large effort for LFS as it > would probably be one new page introducing the issue plus some additional > text > in appropriate places like paragraph 6.5.1 (FHS Compliance Note). > Agreed and it provides an opportunity for more educational benefits and encourages the reader to do some "further reading/research"... > 4. 64-bit LFS > > This is the other difficult area. How should the topic be presented and > integrated into the book will require a fair amount of discussion. Whether > to > add multilib is also important as a pure 64-bit system has problems with some > packages. I would propose a page with an introduction to 64-bit processing > to > provide the user a basis for choosing the desired configuration. Integrating > the instructions in a seamless manner will be difficult. > Hmmm, I still haven't moved to 64bit and see little reason to currently. I'd have this low down the priority list personally. -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS - DESTDIR Style
Randy McMurchy wrote: > > Thoughts from others? > And there's me thinking you were just playing with your chopper... That sounds great - I'd be really interested in seeing some of the meat. It seemed that the great enthusiasm we had here a few weeks ago for a LFS-ng had died almost as fast as it came, but maybe not. Al -- The way out is open! http://www.theopensourcerer.com -- 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
Ioan Ionita wrote: > FUD. No examples. What issues? What applications? of those, how many > are closed-source? In my experience, Flash works flawlessly with > nspluginwrapper, so no need for 32-bit firefox. Anything else > problematic? Skype? Not FUD - This isn't some kind of OOXML war. I'm just explaining my experiences. > > > I'm a regular kind of Desktop user myself and I'd never move back to > 32-bit. I've been on x86_64 for almost 2 years now and it's been > wonderful. My benchmarks have shown a 20% performance gain on some > workloads. That's great - I'm glad you are comfortable with 64bit. For me it was unusable. > of course, distro comes into play too. I used to be a devoted LFS > user. Until I tried to build a x86_64 LFS. Never got it working and > gave up. I installed Ubuntu Feisty x86_64 a while later and I've been > running it and upgrading smoothly all the way to Hardy beta. It's been > absolutely great. > > So don't blame 64bit, blame LFS for not properly supporting it. I wouldn't blame LFS at all, that's a strange remark... In fact if you read my original post, you would see that it was actually Ubuntu 64 that I tried and gave up with after a just a couple of hours of trying. Al -- The way out is open! http://www.theopensourcerer.com -- 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
Phillip Huang wrote: > Hello folks, > > I want to build LFS on my new 64bit platform(Intel EM64T), and I googled > CLFS, > while according to another link: http://lwn.net/Articles/243695/ > I hope this isn't teaching you to suck eggs, but my experience with various 64bit versions of Linux is - frankly - don't bother currently. 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. 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. This even applies to Ubuntu 64bit which I have tried. I removed it within a few hours when I couldn't load Acrobat reader, various media codecs and several other apps... Hope this helps. Alan -- The way out is open! http://www.theopensourcerer.com -- 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:
> Please reply to this message (please, limit this to the lfs-dev list
> only) and mark with "X" the items that apply. If the answer is not the
> same on your different Linux systems, write numbers of systems to
> which each answer applies instead of a simple "X" mark. The resuts may
> or may not be used for determining the future course of LFS. They will
> certainly be used to verify or disprove my guess about the way the LFS
> community is now split.
I'm interested in where this is going?
>
> [ ] I am an editor of LFS or one of the related projects
> [ ] I use LFS as my primary Linux system
> [X] I use LFS on more than one PC (including virtual machines)
> [ ] I deviate a lot from LFS (not counting package updates as deviations)
> [X] I deviate a lot from BLFS (not counting package updates as deviations)
>
> I use the following package management technique:
> (X) It's all in my head!
> (X) I trust the lists of files in the book
> ( ) I rebuild everything every three months or less, so there is no
> need to manage anything!
> ( ) Installation script tracing with installwatch or checkinstall
> ( ) Installation script tracing with some other tool
> ( ) Timestamp-based "find" operation
> ( ) User-based
> ( ) RPM
> ( ) DPKG
> ( ) Simple binary tarballs produced with DESTDIR
> ( ) Other DESTDIR-based method of producing binary packages
> ( ) Other
>
> I use the following features provided by a package manager:
> [ ] Knowing where each file comes from
> [ ] Clean uninstallation of a package
> [ ] Removal of obsolete files when upgrading to a new version
> [ ] Ability to upgrade toolchain components (most notably, glibc) painlessly
> [ ] Ability to revert mistakes easily and quickly by installing an old
> binary package
> [ ] Ability to compile once, deploy on many macines
> [ ] Scripting the build
>
> I will ignore the future LFS advice on package management if it
> [ ] Can't be applied on a busy machine where many files are
> accessed/modified everyy minute
> [ ] Can't be used to transfer packages to another machine
> [ ] Interferes with config.site files described in DIY-linux
> [X] Will clobber configuration files wen upgrading package versions
> [ ] Doesn't explain how to package software beyond BLFS
> [ ] Requires learning another language/syntax besides bash shell syntax
> [ ] Exists at all
>
Interesting set of questions... What are you trying to determine?
In the "I use the following package management technique:"
For {B}LFS I do not use any PM. I only use {B}LFS on my servers as they
tend to be much more static. "IF" there was a decent PM, I would use
{B}LFS on my desktop too!
In the final set of questions I'd like to have this feature:
[ ] Doesn't explain how to package software beyond BLFS
but it certainly wouldn't be a show stopper...
HTH
Alan
--
The way out is open!
http://www.theopensourcerer.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Clearing things off and getting going - again...
Alexander E. Patrakov wrote: > 2008/3/3, Alan Lord <[EMAIL PROTECTED]>: >> * PM (This is very a technical issue and an emotive one, probably one of >> the most important too as it may affect everything that follows in LFS-NG) > > I am very surprised the nobody replied to my mail with the subject > "RPM: proof of concept". Personally, it's a bit over my head, sorry. ;-). Also, I have a purely emotional bias against RPM. Give me anything else but RPM. (And don't ask me why... I tried Redhat some time ago and didn't like RPM. I use Ubuntu daily and think apt far superior. But whether it is right for LFS or not is *not* something I feel able to comment on. Yet.) > >> * Presentation (How we deliver/provide LFS-NG to the community, e.g. >> Book, Dynamic web based, LMS, local machine-based application? More than >> one?) > > I think that a "local machine-based application" option is the worst > of them all. Reason: it is the least reliable, and the only one that > doesn't allow easy changes of the presentation. For me, LFS must stay > as "data" from the user's viewpoint, not "data+program", because bugs > in the program will prevent the use of the data, and the reader is > supposed to be able to discard or fix wrong data, but not fix errors > in a program. Think about the recently reported jhalfs breakage in > French locales as an example. No program, no bugs in it. Totally agree. +n (n=as many as possible) >> * Structure (The modular courseware approach, or something else?) > > This can only be defined after deciding about the target audience(s). Probably you are right, although making it modular means that it "should (This should be a "must" thinking about it more) be possible for the more experienced user to skip the early sections. That's my thought about it anyway. >> Perhaps some simple poll or voting system on the Wiki for areas of >> contention be set-up and some basic rules about voting decided before we >> start? (Having been closely following the MSOOXML fiasco, let's not look >> like ISO please?) > > IMHO, voting should be used only as a last-resort method to come to an > agreement, because the minority's opinion is completely ignored. > Polls, on the other hand, are a good method to throw away options that > nobody likes. > Good point. A last resort solution is fine by me (But when do we decide that we are at that point?). A consensus is usually the best outcome, however we have already seen some of the personalities on here getting rather bruised or inflated. At least a vote - on a particular proposal/decision - reduces it to a solely numbers game... Al -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Clearing things off and getting going - again...
Randy McMurchy wrote: Positive support for Jeremy... > > If you mean that, then you won't go. Plain and simple. > +1. Well said Randy. I also do not know who Richard meant, but I didn't take it to be about Jeremy either. Now, forwards please... We have had many great comments and suggestions from many people. The following is all IMHO and suggestions. It is not meant to sound like instructions. Just in case someone else grabs the stick the wrong way round ;-) Perhaps one of the "senior" editors and/or Gerard should try and aggregate those suggestions into manageable "tasks" and create some working groups for each. Discussion can and should continue on-list and in-public but results/working docs etc should probably go on the wiki. Here's my suggestion for some of the initial tasks * PM (This is very a technical issue and an emotive one, probably one of the most important too as it may affect everything that follows in LFS-NG) * Presentation (How we deliver/provide LFS-NG to the community, e.g. Book, Dynamic web based, LMS, local machine-based application? More than one?) * Structure (The modular courseware approach, or something else?) I would think that once these areas are pretty stable, the decisions about what a core LFS build looks like, what parts of BLFS/CLFS and whatever else needs to go into it, should be relatively painless. Perhaps some simple poll or voting system on the Wiki for areas of contention be set-up and some basic rules about voting decided before we start? (Having been closely following the MSOOXML fiasco, let's not look like ISO please?) And, anyone who blogs, should start blogging about this too. I will be writing a piece in the next day or so. Generate some more traffic to the project, get some fresh ideas, hopefully contributors too... blah, blah, blah... Al -- The way out is open! http://www.theopensourcerer.com -- 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: ... Lots of stuff about George's crazy email(s). Jeremy, I really don't know what George is on. I didn't plan to respond to his mail at all. I don't think it deserves any more bandwidth to be frank. Ignore it. Let's just move on - or get back - to discussing the way forward. Al -- The way out is open! http://www.theopensourcerer.com -- 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
Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> 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. > > I'm having a problem understanding this concept. If one wants a web > server, then you only need LFS and a few packages from BLFS. If you > want a workstation, then you need LFS and quite a few more packages from > BLFS. What's a "module" besides a list of packages for a particular > application? BLFS is set up to be able to jump around as necessary. I > must be missing something because I see a "module" as fundamentally LFS > and a list of links in BLFS. Bruce, my "modular idea was more about "training modules" rather than sets of packages... Here's the original suggestion I made: --- So perhaps the LFS project becomes some sort of "course" (and I use the term loosely). The "modules" of which, could be something like: * Learning the basics (Command Line, cmmi, security, toolchain, blah blah) * Scripting/Automating (A subject about how LFS gets built, the tools, the processes involved etc) [This is where PM would probably go too] * Basic Useful Applications (A sort of mini BLFS where we get networking, X and maybe Firefox/TB type apps installed) * Building your Distro (Completing the core build-out adding your chosen apps and utilities and configuring) * Making your Distro distributable (How to make a liveCD of "your distro", how to make an installer script...) So, I was trying to think at high level about how to keep, and hopefully improve, the educational value of LFS and to separate the current process into "course modules" at sensible points to allow them to be done "standalone" as it were. By splitting up it this way, I think we could get a wider community involvement as interested parties can 'scratch their own itch' without having to know about everything else. I think Jeremy summed up the current thinking well at the start of this thread and I basically agree. I do think however, these modules need to be given careful thought. Anyone in the (higher) educational sector care to comment? Forget about the technicalities for now, just concentrate on thinking about what would make a really fantastic learning project, with something that you get to keep and develop at the end of it! A bit like Lego, or Meccano (http://www.meccano.com/about/index.php). PHP has cropped up a few times. It's probably the best choice as *so many people* know about it. We might want to take a look at something like Moodle (http://moodle.org/), a Learning Management System (LMS) which is used very widely in schools and FE colleges as a possible delivery platform. Why re-invent the wheel? Thanks for all the positive comments about the module suggestion, that makes me feel all useful and everything :-) Al -- The way out is open! http://www.theopensourcerer.com -- 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
DJ Lucas wrote: > > OK, so a more pronounced idea has been expressed, and I do like where > it's going. Now where to start? Proposals to solidify those ideas? > > But I think this should have waited...one thing at a time here. I'm > kind of thinking that it's easiest to start from the package manager > since everything else will have to meld around it. What are the goals > for the package manager? Is it a complete installation tool, or is it > something minimal along the lines of install-log? There is already a > thread about this. I almost posted it here. I really don't think > anybody can provide anything better than "it sounds goo" or "it doesn't" > without the PM thread hashed out. > > -- DJ Lucas I haven't tried this tool yet, http://www.gnu.org/software/sourceinstall/ but the goals and overall description for this could be a very good fit for LFS-NG. http://www.gnu.org/software/sourceinstall/ The project looks quiet, but not inactive. Perhaps this could make a good starting point? Al -- The way out is open! http://www.theopensourcerer.com -- 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: > > Think outside the current HTML box for a minute. Not for technical > reasons but convenience. I've been wondering for a while if there's a > case to be made for seeing installation output and the book's > (replacement) text in the same window. I can see this be a nice change > for installation modes where you are text-only. > > While you wait for "make" to finish (we all know how long that can > take), you can shift your eyes up a few lines and start reading up on > what you're actually doing in one (hopefully?) convenient location. > > G Remember nALFS? That was one of the greatest features IMHO, the split screen, where you could look at and monitor the "progress tree" and below, actually still see something useful was happening... Al -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: What next?
WOW! where have all these people come from? Jeremy asks about the LiveCD and suddenly we have more posts to these mail lists in two days than in the last 3 months! I have been thinking about this since the "Happy Birthday LFS" post from Gerard a few days ago. Since then, Jeremy's quest has certainly stirred up some terrific energy. I think that the LiveCD debate is fairly clear-cut in that the majority want something to stay. The recent posts about What next are more relevant and will probably help to determine what a LFS CD might actually look like. So below, I post a fairly high level, non-technical suggestion about the LFS project. Firstly, Gerard is definitely on the right track in his recent posts, and DJ also hit the nail on the head too with some of his concerns. To paraphrase Gerard's ideas (I hope correctly): * combine the resources/knowledge of the various projects into something more coherent, * Implement PM (Oh yes, oh yes) * Move away from the manual cmmi to an automated build system (Sounds a bit like Gentoo) * Make the LFS book more informative and less "techy/geek" speak. The last point is a great one and where we can *all* get involved. You don't need to be a software hacker, XML guru (where is Manuel BTW?), or whatever to help with writing good material. My own thoughts on where LFS needs to go have been going on for quite some time as I have seen the list activity dwindle and I myself have become more accustomed to using Ubuntu . However, this last few days it really looks like there could be some momentum to actually make some changes and bring life back to the project. I keep coming back to education... That was the goal of LFS and should continue to be it's overriding objective. So perhaps the LFS project becomes some sort of "course" (And I use the term loosely). The "modules" of which, could be something like: * Learning the basics (Command Line, cmmi, security, toolchain, blah blah) * Scripting/Automating (A subject about how LFS get built, the tools, the process etc) * Basic Useful Applications (A sort of mini BLFS where we get networking, X and maybe Firefox/TB type apps installed) * Building your Distro (Completing the core build-out adding your chosen apps and utilities and configuring) * Making it your Distro distributable (How to make a liveCD or "your distro", how to make an installer script...) I'm sure you can get the idea: the modules might not be quite right, but breaking the process up into manageable chunks, where knowledge can be given/gained that is pretty mandatory before going onto the next step. I'm sure that it's the educational aspect of LFS that can keep it apart from the usual distributions, but there should be *no* reason why a competent user of the LFS instructions can't end up with a perfect Distro, for their needs that is maintainable and repeatable. In fact this could spur a great many new ideas and innovation... I'd be happy and willing to support this project with some of my time and my somewhat limited skills ;-) Alan LFS ID: (216 2.4.x) -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Happy Birthday LFS
Gerard Beekmans wrote: > That makes LFS nine years old this month. It still boggles my mind some > days that LFS grew into what it has. > > Ciao! > > Gerard Hi Gerard, For me, this has been one of the most important Open Source projects ever. It got me interested and excited, and taught me more than I'd have thought possible. Thank you. But, there is a definite "lull" in the community currently as I am sure you will be aware. As a personal observation, I think the project needs to go back to it's roots and emphasise the educational angle more strongly than as of recently. To create some impetus, we (all of us on this list and our acquaintances) need to promote the concept of LFS for what it is. There is a virtually unlimited path for the direction/coverage of the LFS project as a whole, but it needs more promotion. It makes me sad to see how quiet these lists are right now. I run a business in the UK providing knowledge and experience on open source software. Without LFS I probably wouldn't have a job. I suggest we start a thread, or even a new "marketing" list, to discuss and develop a plan to stimulate this project further. Best Regards Alan LFS ID: (216 2.4.x) -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Fwd: Re: [LFS Trac] #2111: Adding PACO to LFS]
Can I just throw in my opinion on this subject? I read the ticket and this subject in general has come up on many occasions before... As a long time user of LFS/BLFS I would really LOVE to have a "management" tool for my systems that allowed me to update/upgrade and, probably most importantly, remove components in an organised and "safe" way. But I do not believe this should be an integral part of LFS, and probably not BLFS either. It is a subject that warrants - in my opinion - another book/project in the LFS family. If it was developed to offer the kind of system management tools that many of us want to have, the main books (LFS/BLFS) might need changing to support it, or might not, and if the "books" are followed *to the letter* then the LFS Manager could be dropped even after your system is built (Obviously I can see some circumstances where this could fail spectacularly, but guidance in the main books should make it clear how to build to support the management tools or what to watch for if you decide to deviate...) Could this be a way to stimulate some more life here? Develop a new book for the LFS family that provides system management tools. I'm sure PACA is a fine tool (not used it but not heard much ever said in a bad light about it) and maybe that becomes the foundation for such a book? Or something else... At least it would get some dialogue and some activity on here. A few blog comments and articles around the net might bring in some new blood with good ideas too. It may be that by trying to get the LFS and BLFS systems into such a position that a management tool could be dropped in before, during or after a build, that the books' structure becomes a better platform to develop the jhalfs type tools too... So perhaps some sort of architecture description and requirements specifications are needed first and then see what needs to be changed with what we have to suit what we need going forward. Sorry if this is noise or way off the mark... Alan -- The way out is open! http://www.theopensourcerer.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: mktemp, tempfile & coreutils
Bruce Dubbs wrote:
> I ran a modified version on quantum:
>
> find {,/usr}/{,s}bin -type f -exec sh -c "file {} | grep text | \
> grep -viq perl && grep tempfile {} /dev/null | cut -d: -f1 | uniq " \;
>
> and got:
>
> /sbin/generate-modprobe.conf
> /usr/bin/updatedb
> /usr/bin/tempfile
> /usr/bin/vimtutor
> /usr/bin/mysqlaccess
> /usr/bin/sa-learn
> /usr/bin/spamassassin
> /usr/sbin/grub-install
>
> Actually /usr/bin/spamassassin and /usr/bin/sa-learn are perl scripts,
> but file thinks they are awk scripts.
>
> So that matches what you have.
>
> -- Bruce
LFS-6.3, Some recent BLFS packages and some non-blfs: mainly asterisk.
root [ ~ ]# find {,/usr}/{,s}bin -type f -exec sh -c "file {} | grep
text | \
> grep -viq perl && grep tempfile {} /dev/null | cut -d: -f1 | uniq " \;
/sbin/generate-modprobe.conf
/usr/bin/updatedb
/usr/bin/tempfile
/usr/bin/vimtutor
/usr/sbin/grub-install
root [ ~ ]#
Alan
--
The way out is open!
http://www.theopensourcerer.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LiveCD list on Gmane.org
TheOldFellow wrote: > On Sun, 19 Aug 2007 13:50:02 +0100 > Alan Lord <[EMAIL PROTECTED]> wrote: > >> TheOldFellow wrote: >> > Konnichiwa, >>> The archive is up now. Thanks for this, Jeremy. >>> >>> R. >>> >> Arragato! >> >> Alan >> > Do itashimashite. > R. :-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD list on Gmane.org
TheOldFellow wrote: > Konnichiwa, > > The archive is up now. Thanks for this, Jeremy. > > R. > Arragato! Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.3/Hints
Luca wrote: > Hello. > > I'm thinking about writing a Hint to build a XEN-Lfs (when I'll be back) > since, at least, there's one user who asked me how to build it. > So I've got a couple of questions: > 1) Is LFS-6.3 going to be released sometime during next two weeks and, > if not, could I use it safely (I mean no expressive changes) instead of > 6.2? > 2) What about Hint Project? I mean, after writing and testing the hint, > posting to hint mailing list will be picked up or what? I ask because > state of hint project. > > Regards, > Luca > Might want to check out VirtualBox - XenSource has just been acquired by Citrix for a very cool $500m! I don't know if this will affect xen much but Citrix are hardly known for the Open Source contributions... ;-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: > On Wed, Aug 15, 2007 at 02:56:45PM +0100, Alan Lord wrote: >> Perhaps therefore, making the LFS PM friendly and then having a separate >> project which would develop and provide on-going maintenance tools would >> be a way to look at this... It too would also be a "learning" tool >> demonstrating [perhaps] such things scripting or system admin skills >> that would enable the whole LFS project to grow. > > This is some of what I had in mind when mentioning the other > possibilities that such a development model on the LiveCD could effect. I > wanted to wait and see if someone else would see it too. The LiveCD > could be at the core of the development, with official build recipes, > but if we play this right, a new sort of project as you suggest could be > born out of the LiveCD, one that incorporates the best of LFS and BLFS. > > -- > JH This is pretty much what I said in the "LiveCD users" thread you started on the 18th of last month on the general list... In fact here's my comments from that. "I would make it more of a proper LFS project with a "book" and suchlike so everyone can learn the process of how to build a live CD or make their own distro that they can copy and give to friends... It is one of the most widely asked questions on the lists: How do I make my LFS portable/put it on a cd/put it on another pc blah blah blah... This would also encourage others to get involved and the project could then evolve/develop at a faster pace. Perhaps getting to a Gentoo type scenario where you can learn how to build a liveCD that will either just install like most distros or automatically build a new LFS a bit like Gentoo. > > Of course any other thoughts or comments are welcome. We really just > > need to get an idea of how useful our project is to the community. If > > it's too much work to answer the above, just a short reply saying you > > use the CD would be helpful, too. > > In a way, the whole LFS(all projects within the umbrella) thing is made up of many transient users/contributors. I have used and learned from LFS for many, many years now (my LFS ID is 216) but I now find myself using Ubuntu as my main desktop system because it works painlessly and upgrades are automatic. I guess many others will migrate like this. But I know how to fix it when things go wrong and how to install packages that aren't pre "deb'ed"... I still feel a great empathy towards the project and still read the lists almost daily. I don't build LFS much now though... It has done it's job :-) " -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: > Jeremy Huntwork wrote these words on 08/15/07 07:20 CST: > >> I would love to see some sort of proper support for PM go into LFS, but >> that all depends on the community... > > I'll go on record as -1. > > I feel we should mention it, provide links to the various alternatives, > and drive on. We are not a distribution. We are a book that shows how > to compile Linux from scratch. Let's don't forget that. You are correct of course. As a reader/user of LFS/BLFS it has done exactly that. Provided a fantastic learning tool. The unfortunate consequence of LFS is that it also teaches the user how great a lean/mean Linux system can be (and most would want it to stay that way if it *was* a distribution). I would hazard a guess that most people who grok LFS would love to use it for their everyday distro. Unfortunately it is beyond my skills (and available time) to be able to continue using LFS for the PITA upgrade/maintenance issue. > > Package management is beyond the scope of showing how to compile > packages (and which packages to compile). > Perhaps therefore, making the LFS PM friendly and then having a separate project which would develop and provide on-going maintenance tools would be a way to look at this... It too would also be a "learning" tool demonstrating [perhaps] such things scripting or system admin skills that would enable the whole LFS project to grow. I feel that this is why the core contributory community of LFS remains quite small and a large proportion of it transient. Once the "learning" is done we hit a metaphorical brick wall of how to maintain our system. If I could maintain mine I would not be using Ubuntu Al -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote:
> Hello,
Hello
> Essentially, the LiveCD is a distribution. But it is a distribution
> without something that nearly all others have: package management. Up to
> now, there hasn't really been a need. But, if the CD incorporated PM at
> its very heart, developers could focus more on tightening individual
> components instead of always building the entire CD in one shot.
> If you like the sound of this new approach, please share your thoughts
> on what might help make it work. Details need to be discussed, such as
> the exact development model, package management tools, updated
> development scripts, tracking dependencies and standards for
> development. I'll wait until there is some discussion before I speak any
> further on some of the details that are already forming in my head.
Disclaimer: Please take my comments as those of a lurker - rather than
anyone with any actual authority on this subject.
Jeremy - that sounds like a cracking idea but I strongly believe that it
should go much further than the LiveCD...
The idea of PM for {L,B}FS is one of the frequent questions to pop-up on
these lists. There has also been discussion recently about how to
"invigorate" the community and the project.
I have been "doing" LFS for many years (LFS ID#216) but in the recent
past now use Ubuntu for daily use. The reason why I don't do {L,B}FS
much now? Because it is such a PITA to keep up-to-date. [Me dons an
asbestos suit].
From a personal perspective, if there was an "easier" and more
integrated way to maintain a {L,B}FS system I'd still be using it; with
Ubuntu, that just works.
I believe that if {L,B}FS (and the LiveCD) are developed to provide an
integrated package management tool (but let's do it in the LFS style) or
more like an automated build/upgrade tool, it would be a real boost to
the project as a whole and garner a lot more support from the community
at large. Maybe this should/could be the goal for LFS 8 or perhaps 10 ;-)?
> Lastly, I'm posting this to {,b}lfs-dev because I'd like to make sure
> those current groups of readers have the opportunity to comment. If
> possible, though, please send discussion to the livecd list.
Sorry - I get in via gmane and the livecd list isn't on there - never
has either to my knowledge...
Alan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: x86_64 build method
Jeremy Huntwork wrote: > Hello Everyone, > > I'm trying to decide how best to alter the x86_64 branch. If we adopt > the basic principles from DIY-Linux, it would mean that as far as build > instructions go, we only have to add 3 things: > Even with all the above, it seems much simpler than trying to maintain > two separate books. > > -- > JH Forgive the intrusion but I thought this worth saying... Of course it might be complete hogwash in which case please enlighten me ;-) (I'm quite thick-skinned too) A while ago now I looked at building CLFS for my AMD 64 processor. But after doing some research, IIRC I discovered that there was almost no gain to be had from building LFS as *pure* 64bit and there were quite a few problems, namely: * Bootloader, or rather lack-of * Building BLFS on top of a pure 64b LFS was - at the time - impractical and untested * Several apps and closed-source binaries widely used were not available for 64bit architectures. Unless this has significantly changed (in which case I'll be building a new LFS64 next week ;-)) I think some rather bold and legible text at the start of the book needs to make it clear that there may be little point in doing this unless you know what to do next. Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: svn access
Bruce Dubbs wrote: Jeremy Huntwork wrote: Hey All, Would anyone mind if I helped out a bit with the development here again? If not, I would require svn access. If so, well, fair enough. :) Can't keep away, eh? Any help is appreciated. You are good to go. -- Bruce It's good to see you back contributing Jeremy. Just don't wind up Randy too much ;-) Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Users Hint
Chris Staub wrote: As I recently mentioned in a reply to the lfs-support list, I believe package users is really more trouble than its worth. The paragraph describing it, in the "Package Management" page, should be removed from the book. Note: A similar warning should be added to the ALFS webpage, saying that you should not even attempt ALFS until you can successfully build a system manually without errors and without any help from support channels, and that any user who does try ALFS without this prerequisite will not get any help from the support channels. [Please forgive my intrusion here, and this is not intended to be a dig or attack on anyone - just my immediate thought...] Whilst I understand your sentiment above; seeing this thread directly following from Randy's "Dead Project?" seems a bit ironic... Surely, with the current slow/small userbase, scaring people off from trying things out is exactly what isn't required? Shouldn't the community be trying to be a bit more 'inclusive'? I understand the support issues, but there are plenty of people who could help with the replies - sometimes the editors/main contributors are just too quick to respond. Remember this is free stuff, there are no guarantees and no-one is actually paid to help others either! I've been a long-time follower/user of LFS (ID: 213 IIRC) and occasional contributor to these boards. I don't have any authority here but I am very fond of this project as a whole and would like to see it continue; and indeed grow... Thanks and viva LFS! Alan PS - George and Manuel are doing a bloody fantastic job on jhalfs. More power to them I say. PPS - What ever happened to Jeremy Huntwork? PPPS - on holiday for a week now so I'm not ignoring any replies (if there may be any), just not around ;-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS vs BLFS -- udev rules
Jeremy Huntwork wrote: Give them the basics, show them how to extend, warn about possible pitfalls and provide an example. Doing this we're not leaving them with a half-baked system, as some have said already - we're teaching them how to complete the system themselves which is what LFS has always been about first and foremost. As another lurker/user rather than a contributor, I'd also concur with Joshua's POV. It seems to me however that for the way most "regular" users of LFS do things (I mean a customised, scripted LFS/BLFS system) it would make perfect sense to have a L/B/C/H/X/LFS standard set of users, groups and rules. This might potentially need a separate project so that all contributors could assist. Just my tuppence worth... Al -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
Uli Fahrenberg wrote: Archaic, Apr 7, 13:30 -0600: However, this sort of information seems most useful to developers and the more highly advanced readers. it is sort of like an index of knowledge gained and applicable to development, but not really applicable to following the book to produce a working system. Comments? So far I've only seen 3 other people say anything in this thread. I'm a lurker and not a developer but I do build LFS/BLFS frequently for fun :-) This dependency information seems to me to be very valuable (and not just for the book itself...) - perhaps an appendix in the book would be a suitable place??? Al LFS ID: 216 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
OOo, Xorg7.0 etc etc etc
Hi all, I just wanted to give you an update on my build success (or lack of) with the above apps. (Please see earlier threads for details of failures and fixes) My host is a very recent LFS (20060203 or similar). Xorg-7.0 was built successfully according to DJ's instructions. Firefox-1.5 was built & installed against system installed NSS/NSPR libraries. The JDK is a binary install of 1.5.0_06. Unfortunately, after about 5 days of trying, I have given up... After switching to a recent snapshot (2.0.155) the OOo build was getting quite far (about 4hrs and 4Gb!) but would consistently fail around some Java and Language binding (this is a plain US install - I removed my "UK" centric switches). I'm sorry I couldn't complete the task but I have just run out of time for the moment... Alan PS - It took me about 5 minutes to use rpm2targz and install the binary of OOo 2.0.1. Thanks for that link Richard :-) -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR
Bruce Dubbs wrote: They come form the nas package. http://www.linuxfromscratch.org/blfs/view/cvs/multimedia/nas.html -- Bruce Thanks Bruce, but I thought by adding --without-nas I wouldn't need them? Perhaps they are a dependency anyway... -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR
I know - posting to my own message but... Just d/l the OOo linux-intel-x86 package and it's all in bloody RPMS!!! Aghh Oh well looks like I will be building from source somehow - now where did I put audiolib.h... Al -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR
Alan Lord wrote: Alan, sorry for not getting to this sooner in BLFS, life has once again stepped in the way. :-/ Unfortunately, I don't see it any time in the next couple of weeks unless another editor can grab it. If it wouldn't be too much trouble, when the build completes, would you mind posting a quick summary of what has changed in your 2.0.1 installation vs. the 2.0.0 in BLFS? It'd be nice to have a working recipe on list in case others ask about 2.0.1. Yes it would :-) If you get one let me know LOL. (See below) Basically, it seems pretty much everything you install on top of xorg 7.0 (if you follow the instructions and build it in /usr/X11R7) needs the --x-includes= and --x-libraries= switches set, if they are used, or you need to set CPPFLAGS and LDFLAGS. It's still chundering through... I have had to restart the build repeatedly and as yet it does not complete. It has failed again! Despite the fact that I explicitly disabled nas support with the --without-nas switch, my build has stopped once more during something to do with nas... Here's the error: ==make error= Making: ../../../unxlngi6.pro/slo/nassound.obj g++ -Wreturn-type -fmessage-length=0 -c -I. -I. -I../inc -I../../../inc -I../.. /../unx/inc -I../../../unxlngi6.pro/inc -I. -I/home/alord/OOA680_m1/solver/680/u nxlngi6.pro/inc/stl -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc/external -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc -I/home/alord/OOA680_m1/sol env/unxlngi6/inc -I/home/alord/OOA680_m1/solenv/inc -I/home/alord/OOA680_m1/res -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc/stl -I/home/alord/OOA680_m1/ solenv/inc/Xp31 -I/opt/jdk/jdk/include -I/opt/jdk/jdk/include/linux -I/opt/jdk/j dk/include/native_threads/include -I/usr/X11R7/include -I. -I../../../res -I . -Os -fno-strict-aliasing -Wuninitialized -fvisibility=hidden -I/usr/include/ startup-notification-1.0 -pipe -Wno-ctor-dtor-privacy -fvisibility-inlines-hi dden -fno-exceptions -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DGXX_INCL UDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../include/c++/4.0.2 -DCV ER=C341 -D_USE_NAMESPACE -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D _USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE - DUNIX -DCPPU_ENV=gcc3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_L EVEL=0 -DOPTIMIZE -DEXCEPTIONS_OFF -DCUI -DSOLAR_JAVA -DOOA680 -DUSE_BUILTIN_RAS TERIZER -DVCL_DLLIMPLEMENTATION -DUSE_NAS -DUSE_PASF -DHAVE_LIBSN -DUSE_XINERAM A -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../unxlngi6.pro/slo/nassound.o /h ome/alord/OOA680_m1/vcl/unx/source/app/nassound.cxx /home/alord/OOA680_m1/vcl/unx/source/app/nassound.cxx:41:28: error: audio/audiolib.h: No such file or directory /home/alord/OOA680_m1/vcl/unx/source/app/nassound.cxx:42:28: error: audio/soundlib.h: No such file or directory /home/alord/OOA680_m1/vcl/unx/source/app/nassound.cxx: In static member function 'static void vcl_sal::NASSound::callback(void*, void*, void*, void*)': ==End make error= I'm probably going to have to give up for now - two days trying to get OOo to build succesfully is just too much. Here's the configure line I used: ==configure= ./configure --prefix=/opt/openoffice-2.0.1 --x-includes=/usr/X11R7/include --x-libraries=/usr/X11R7/lib --enable-libart --enable-libsn --enable-xsltproc --disable-mozilla --disable-fontooo --without-fonts --without-nas --with-system-stdlibs --with-system-jpeg --with-system-curl --with-system-freetype --with-system-expat --with-system-libxml --with-system-zlib --with-system-mozilla --with-firefox --with-system-db --with-db-jar=/usr/lib/db.jar --with-system-python --with-build-version=BLFS --with-package-format=native --disable-binfilter --disable-cups --disable-gnome-vfs --with-lang="en uk" --with-dict=ENGB,ENUS ===End configure=== I'm a bit out of my depth now and am probably going to have to give up! Here we go to a binary for now...:-( Cheers Alan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR (Long)
Jürg Billeter wrote: On Mit, 2006-02-08 at 20:58 +, Alan Lord wrote: In the Perl script set_soenv the offending line is: ToFile( "MOZ_NSPR_CFLAGS", "@MOZ_NSPR_CFLAGS@", "e" ); Am I being thick? Should I have only applied the nspr patch? On first glance it looks like you didn't regenerate the configure script after patching configure.in. Call autoconf in the config_office directory. Jürg That seems to have done the trick! Thanks Jurg. Alan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR (Long)
Jürg Billeter wrote: > OOo doesn't strictly require imake. IIRC it's just NAS which requires xmkmf and imake. I can certainley build OOo 2.0.1 (using ooo-build-2.0.1) without xmkmf and imake when disabling NAS. Thanks - that's good to know for next time round :-) HTH, Jürg [1] http://cvs.gnome.org/viewcvs/*checkout*/ooo-build/patches/src680/buildfix-system-nspr-m112.diff?rev=1.1 [2] http://cvs.gnome.org/viewcvs/*checkout*/ooo-build/patches/src680/buildfix-system-nss.diff?rev=1.2 I applied these patches but now the end of the configure routine (set_soenv) barfs: checking whether to statically link to Gtk... no checking whether to use custom image sets... no * * * Setting up the build environment variables.* * * checking solver path... default configure: creating ./config.status config.status: creating set_soenv Possible unintended interpolation of @MOZ_NSPR_CFLAGS in string at ./set_soenv line 1727. Global symbol "@MOZ_NSPR_CFLAGS" requires explicit package name at ./set_soenv line 1727. Execution of ./set_soenv aborted due to compilation errors. [EMAIL PROTECTED]:/home/alord/OOA680_m1/config_office# In the Perl script set_soenv the offending line is: ToFile( "MOZ_NSPR_CFLAGS", "@MOZ_NSPR_CFLAGS@", "e" ); Am I being thick? Should I have only applied the nspr patch? Alan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
OOo-2.0.1, Xorg 7.0, Firefox-1.5 and System NSS/NSPR (Long)
Hi all, some notes about building the above apps... I have a nice new xorg 7.0 and Firefox 1.5 with the system NSS/NSPR install all working fine. When I get to OOo is where the trouble starts... OOo needs imake :-( To build OOo I found that one has to install (at least) these xorg utility files: imake-X11R7.0-1.0.1.tar.bz2 , gccmakedep-X11R7.0-1.0.1.tar.bz2, xorg-cf-files-1.0.1.tar.bz2 ... The site.def file installed into /usr/X11R7/lib/X11/config (I used ~dj's build method for xorg 7.0) has a hardwired reference to PROJECTROOT=/usr/X11R6! This needs to be changed or the build of nas-1.6 barfs with the "No such file" Imake.tmpl error. I had built Firefox using Randy's new method of the system NSS/NSPR libraries. During the OO build it barfs because it can't find "prtypes.h" which resides in /usr/include/nspr. Now I can't for the life of me work out why it can't find it. During configure, it correctly sets a couple of env vars: Here's the relevant output from configure: ==configure.log= checking whether to enable build of Mozilla/Mozilla NSS-using components... no checking whether to build Mozilla addressbook connectivity... no checking whether to build XML Security support... no, since Mozilla (NSS) disabled but needed checking whether to build LDAP configuration backend... no. Either Mozilla or OpenLDAP needed. checking which mozilla to use... external checking whether to use Mozilla or Firefox... Firefox checking for firefox-xpcom ... yes checking MOZILLAXPCOM_CFLAGS... -I/usr/include/firefox-1.5 -I/usr/include/firefox-1.5/xpcom -I/usr/include/firefox-1.5/string -I/usr/include/nspr checking MOZILLAXPCOM_LIBS... -L/usr/lib/firefox-1.5 -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl checking for firefox-nss ... yes checking MOZ_NSS_CFLAGS... -I/usr/include/nss -I/usr/include/nspr checking MOZ_NSS_LIBS... -lnss3 -lsmime3 -lssl3 -lsoftokn3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl checking for PK11_GetCertFromPrivateKey in -lnss3... yes checking which sane header to use... internal checking for X... libraries /usr/X11R7/lib, headers /usr/X11R7/include ===end configure snippet== Here's my configure line: === ./configure --prefix=/opt/openoffice-2.0.1 --x-includes=/usr/X11R7/include --x-libraries=/usr/X11R7/lib --enable-libart --enable-libsn --enable-xsltproc --disable-mozilla --disable-fontooo --without-fonts --with-system-stdlibs --with-system-jpeg --with-system-curl --with-system-freetype --with-system-expat --with-system-libxml --with-system-zlib --with-system-mozilla --with-firefox --with-system-db --with-db-jar=/usr/lib/db.jar --with-system-neon --with-system-python --with-build-version=BLFS --with-package-format=native --disable-binfilter --disable-cups --disable-gnome-vfs --with-lang="en uk" --with-dict=ENGB,ENUS = And here's the error log: == cd ./unxlngi6.pro/misc/build && cat ../../../mozilla-source-M16-stub.patch | patch -b -p2 && touch so_patched_npsdk patching file mozilla/include/npapi.h patching file mozilla/include/npupp.h patching file mozilla/plugin/oji/MRJ/plugin/Source/makefile.mk patching file mozilla/plugin/oji/MRJ/plugin/Source/npunix.c patching file mozilla/plugin/oji/MRJ/plugin/Source/npwin.cpp patching file mozilla/sun-java/stubs/include/jri.h patching file mozilla/sun-java/stubs/include/jri_md.h patching file mozilla/sun-java/stubs/include/jritypes.h touch ./unxlngi6.pro/misc/build/so_patched_npsdk touch ./unxlngi6.pro/misc/build/so_configured_npsdk mkdir ./unxlngi6.pro/misc/build/mozilla/plugin/oji/MRJ/plugin/Source mkdir: cannot create directory `./unxlngi6.pro/misc/build/mozilla/plugin/oji/MRJ/plugin/Source': File exists cd ./unxlngi6.pro/misc/build/mozilla/plugin/oji/MRJ/plugin/Source && dmake product="full" && touch so_built_npsdk -- Making: ../../../../../../../../../unxlngi6.pro/misc/npsdk.dpc dmake subdmake=true -f makefile.mk product="full" depend=t ALLDPC Making : Dependencies touch ../../../../../../../../../unxlngi6.pro/misc/npsdk.dpc -- Making: ../../../../../../../../../unxlngi6.pro/slo/npunix.obj gcc -Wreturn-type -fmessage-length=0 -c -I. -I/usr/include/firefox-1.5/nspr -I/usr/include/firefox-1.5/java -I/usr/include/firefox-1.5/plugin -I../inc -I../../../../../../../../../inc -I../../../../../../../../../unx/inc -I../../../../../../../../../unxlngi6.pro/inc -I. -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc/dont_use_stl -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc/external -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc -I/home/alord/OOA680_m1/solenv/unxlngi6/inc -I/home/alord/OOA680_m1/solenv/inc -I/home/alord/OOA680_m1/res -I/home/alord/OOA680_m1/solver/680/unxlngi6.pro/inc/dont_use_stl -I/home/alord/OOA680
Re: ImplementingTrac - Logo
John Miller wrote: I noticed an extra forward slash in a few tags, could IE be having problems with them? "href="http://wiki.linuxfromscratch.org/lfs/";>src="/lfs/chrome/site/lfs-logo.png" width="192" height="75" alt="Linux From Scratch" />" at end of the alt field, and in the hr tag and several slashes at the end of the input fields following the logo line. Isn't that just Xhtml? I thought that this is the correct way to write tags which do not have a separate closing tag (stuf). Like the tag for example. I wouldn't have thought the IE would barf at this although stranger things have been known with M$oft... Al -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
So, if you're following this thread and you have a strong feeling that you'd like the UTF-8 changes to be added in as the default or prefer them to be stored in an appendix, please make your opinion known. -- Dan Yes to default please. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD 6.2-pre2 Bug?
Alexander E. Patrakov wrote: Alan Lord wrote: Bringing down the loopback interface...[OK] cpio: /lib/libreadline.so.5.0: No such file or directory cpio: /lib/libhistory.so.5.0: No such file or directory Kernel Panic - not syncing: Attempt to kill init! Hope this helps someone I thought I have fixed this! The bug was in /usr/bin/shutdown-helper, replace the strings "/lib/libreadline.so.5.0" and "/lib/libhistory.so.5.0" with "/lib/libreadline.so.5" and "/lib/libhistory.so.5" Thanks. It isn't a big problem for me at the moment (at least it only occurs at shutdown :-)), but I thought it should be highlighted. Al -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD 6.2-pre2 Bug?
Justin R. Knierim wrote: I remember the discussion (I think), but the bug was more of a 'if you have 2 cdrom drives and some other CD is in the first one and LiveCD in the second, it would fail to find the LiveCD." Not sure if that was fixed yet. You are correct. I have just tried again and the LiveCD does boot if it is in hdb as long as there isn't a CD in hda... On this PC, /dev/hda is a DVD_RAM drive which I normally leave in permanently and use for backup purposes - this machine currently runs Windows. I can't confirm your problem. I have tried the LiveCD on a multiple-cdrom system and besides the above noted bug, it worked. I just had to remove the CD from the first drive until booted. We need to take a look at that for sure. But the init program will look for a /dev/hdb: Can you tell us about your system? What drives, ide/sata/scsi etc. It is a fairly recent machine built by me - Asus A8N-SLI Deluxe Mobo (Nvidia NForce 4 SLI chipset) AMD 64 3200+ Proc 1G DDR Ram in Dual Channel configuration 2 Hard Disks, both on the Nvidia SATA driver: The first Disk is an 80G Hitachi SATA2 Drive. The second is a 160G Samsung Spinpoint SATA IIRC. The first CD is the DVD_RAM drive The second is an LG 16x DVD/DC R/W Does the init program put out an error message or say thing when it fails to find the CD? With the RAM disk installed in /hda and the LiveCD in /hdb the init script looks for the LiveCD but fails to find it and after the third attempt is shuts the PC down... As a slight aside, there are quite a few errors regarding IRQs and things when the kernel is loading (dmesg log attached and I have also attached a copy of the output of lspci -v) When I instruct the LiveCD to "shutdown -h now" or "reboot" it barfs after: Bringing down the loopback interface... [OK] cpio: /lib/libreadline.so.5.0: No such file or directory cpio: /lib/libhistory.so.5.0: No such file or directory Kernel Panic - not syncing: Attempt to kill init! Hope this helps someone Al Linux version 2.6.12.5 ([EMAIL PROTECTED]) (gcc version 4.0.2) #1 SMP Tue Dec 20 00:49:53 GMT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fff (usable) BIOS-e820: 3fff - 3fff3000 (ACPI NVS) BIOS-e820: 3fff3000 - 4000 (ACPI data) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f59c0 On node 0 totalpages: 262128 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32752 pages, LIFO batch:15 DMI 2.3 present. ACPI: RSDP (v000 Nvidia) @ 0x000f7d70 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff30c0 ACPI: SRAT (v001 AMDHAMMER 0x0001 AMD 0x0001) @ 0x3fff9900 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff9a00 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff9840 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:15 APIC version 16 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:a000) Built 1 zonelists Kernel command line: initrd=initramfs_data_cpio.gz BOOT_IMAGE=linux mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2010.432 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1031524k/1048512k available (4306k kernel code, 16132k reserved, 1678k data, 348k init, 131008k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrati
LiveCD 6.2-pre2 Bug?
Hi, forgive me posting to this list but I use gmane and there isn't a group for the LiveCD. Anyway, a little while ago (November?) I reported a problem with the liveCD (I think it was a 6.1-preSomething version) which was that it failed to boot correctly if the CD was in /dev/hdb rather than /dev/hda. Basically when the booting script checks for the CD's existence, it can't find itself when it is in /dev/hdb. I thought that this was confirmed by Alexander and Jeremy at the time and fixed, but I have just tried it again with the 6.2-pre2 and this version also fails when in my 2nd CD drive. Hope this helps someone... Al LFS ID: 216 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
jhalfs: Ready to go.
Manuel Wrote: >Hi! > >I'm very happy to announce that jhalfs is now able to build a full LFS SVN >system (or any other LFS XML sources based in current LFS SVN) in a very >simple way and using the actual commands found in the XML sources. >The sources can be downloaded via >svn co svn://svn.linuxfromscratch.org/ALFS/jhalfs/trunk Snip... Hi, I have been reading this thread (about jhalfs) for sometime now. Might I ask two questions? Is this an alternative to alfs or something more different [sorry about the English there - yeuckkk!] than that? Is it suitable for "non" LFS Developers? I re-build my LFS quite frequently (just for fun) and use have sucessfully used ALFS in the past. I would be happy to try this on my systems. Thanks for a great product and experience. Alan LFS ID: 216 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Randy McMurchy wrote: > Jim Gifford wrote these words on 04/18/05 16:03 CST: > > >> Another issue will be after the tools are built we will be building a cross-compiled kernel, so we can boot into the architecture we are building for and complete the build process. There are a few pitfalls to this. =snip= Hello, I'm a (normally) silent observer - been building LFS since 2.x... and having lots of fun. Having read the discussion regarding cross-compiling I'm a bit confused... How are you supposed to get the new cross-compiled tools and kernel onto the "other architecture" (Presumably this is a different machine? Will this process require the making of a CD or something? Will this new methodology work with nALFS? I use it all the time. I'd also like to concur with Randy. I build a new LFS fairly regularly just for fun and would probably give up if I couldn't use xterms and cut-&-paste. Just my twopenny's worth. PS - I have three machines here: A very old AMD K6-450Mhz which has got me to LFS6.0 and runs fine. An old Dell (upgraded) P4 400Mhz FSB 2.6Ghz with RDRAM (This is the machine I now use for LFS). And a shiny new AMD 64 3200+. I'd be interested/happy in trying to build a 64bit version for that as it only has M$oft on it at the mo and I've a 200Gb disk to fill. Thanks for everyone's hard work in the LFS team - it has opened my eyes to linux and helped me find an alternative to M$. Alan Lord - LFS ID: 216 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
