Re: Xorg7 sub sections
Bruce Dubbs wrote: TheOldFellow wrote: No, it's a lot of applications that together provide a windowing system. It certainly isn't ONE application, since you can miss lots of it out and still have functionality. I disagree. It is a lot of *programs* and *libraries* that together compose one *application*. You don't need all the pieces, but then you don't need all the libraries in kdelibs or programs in kdebase either. Sorry about this Bruce, but I think KDE is completely wrong to bundle everything into these mega-packages. They are just a lot of programs that are designed to work well together. That's the original UNIX paradigm - lots of individually simple programs that can be combined to do complicated things. KDE breaks the paradigm, and so did monolithic X. At last we now have X distributed 'proper', so we can exploit the UNIX paradigm again. I would like to see the full dependency information, please, but since I'm not contributing to the book any more, it's just a 'like'. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gcc-4.1
Archaic wrote: On Mon, Apr 17, 2006 at 07:15:15PM +0100, Andrew Benton wrote: Is that wise? As it stands LFS is out of date. Old gcc, old glibc, old kernel headers. As soon as trunk moves to a newer toolchain everyone will start using that. Why waste effort releasing a book that's already obsolete? You have a really odd concept of obsolete. You should get a job at Redhat where their motto is We leave the bleeding to you. :) Or Microsoft: We're bleeding you dry, upgrade or die -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: slrn S-Lang2 fixes - patch or development snapshot?
Dan Nicholson wrote: On 4/4/06, Randy McMurchy [EMAIL PROTECTED] wrote: On Tue, 2006-04-04 at 16:58 -0700, Dan Nicholson wrote: Assuming the patch works as advertised, how should the change be implemented? If the patch is deemed too large, we can always use the development snapshot: I've never heard anyone was worried that a patch was too large. Heck, if it works, run with it. That's good to hear. As far as I can tell, it does work. Unless there are no objections, I will commit this tomorrow. Later we can have a discussion on whether slrn or Tin or both should be included in the book as UTF-8 aware console newsreaders. -- Dan My two-pennies. Although I reported it failing to build, and subsequently built their snapshot, I found that I didn't like the package, so I can't help validate it for you. Sorry. I'm afraid my atrophied old brain can't remember keystrokes any more, so I had to go back to the dead-rodent. :-) R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Supports Total Healthy Lifestyles
Leila Downing wrote: Diet Pill Breakthrough!!! What if you could actually shed 10, 15 or even 25 pounds quickly and safely in less then 30 days? Actually, cutting your head off works quite as well in practice - you can do it in under a second with a professionally built French ex-government device available cheaply on ebay. It also solves the problem of further weight gain. No relation. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #1847: There is no UTF-8 aware console newsreader in the book
Alexander E. Patrakov wrote: Richard A Downing wrote: In a fit of 'I can't stand another moment of thunderbird !' a few days ago I built both slrn-cvs (slang-2) and tin. I have to say how good thunderbird and pan are. If I had to run a system without X, then I might just manage with tin, but it would be a struggle. This is quite strange, since I quite like mutt, and thought that I would be happy with either - the main problem is their cache management, not the interface. You could install leafnode for caching the articles. Thanks for that. I did it and it works well. It doesn't convince me to use slrn or tin however. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #1847: There is no UTF-8 aware console newsreader in the book
Bruce Dubbs wrote: There is a proposal to replace slrn with tin in the book. In a fit of 'I can't stand another moment of thunderbird !' a few days ago I built both slrn-cvs (slang-2) and tin. I have to say how good thunderbird and pan are. If I had to run a system without X, then I might just manage with tin, but it would be a struggle. This is quite strange, since I quite like mutt, and thought that I would be happy with either - the main problem is their cache management, not the interface. This is sad, as the gmane mirrors of mailing lists are much easier on the bandwidth/storage than subscribing to mailing lists. So, IMO, ditch slrn, and use your editorial effort in a more fruitful area than console newsreaders. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: K3b Installation
Randy McMurchy wrote: Richard A Downing wrote these words on 03/15/06 11:09 CST: There appear to be at least three kinds of so called KDE applications: 1) Those that use QT, but don't depend on KDE at all. 2) Those that use KDE libs, but don't depend on the whole of KDE to operate (and none of the KDE infrastructure gets started when they run) 3) True KDE applications that depend on all the KDE infrastructure. Even when they are called Kthing, I install type 1 apps in /usr. Clearly type 3 apps go in $KDE_PREFIX, I would say. The issue is with type 2 apps, and I guess I'd go for $KDE_PREFIX. Good observation, Richard. Now to figure out where K3b stands. :-) I believe it to be a cross between 2 and 3, perhaps leaning to 3 more than 2. Here is some additional info that may make it easier to make a decision where to install it. randy16228 1 0 12:01 pts/900:00:00 /home/rml/k3b/bin/k3b randy16230 1 0 12:01 ?00:00:00 kdeinit Running... randy16233 1 0 12:01 ?00:00:00 dcopserver [kdeinit] --nosid --suicide randy16235 16230 0 12:01 ?00:00:00 klauncher [kdeinit] randy16237 1 0 12:01 ?00:00:00 kded [kdeinit] randy16287 16230 0 12:01 ?00:00:00 kio_file [kdeinit] file /tmp/ksocket-randy/klauncher This indicates to me that it wants to be a full KDE (Type 3) app. Even though it doesn't fail to build if KDEBASE is missing doesn't mean that the next version won't. Interesting analysis - thanks. $KDE_PREFIX for me. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: `backticks` or $(command) syntax
Randy McMurchy wrote: Hi all, I was thinking about perhaps replacing the backticks (`) in the configure commands of the GNOME packages to $(command) syntax, but it occurred to me that $(command) might be a bashism and other shells (zsh, csh, etc.) might not understand them. Does anybody know right offhand if $(command) syntax is a bash-only thing? I didn't have an answer to the question, so left my comment to now. Backticks appear to be a support nightmare, particularly so as they are one of the variable position keys on even English keyboards - A UK keyboard has them in the far top left corner, unshifted. If you can move to $() without too many [csh etc.] users suffering then you should. Comments are good, and a stern warning in the intro also useful. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: QCAD 2D Drawing Package.
Richard A Downing wrote: Bruce Dubbs wrote: Richard A Downing wrote: I've been using this package for some time to draw my cabinet making projects. It's a good 2D package that can read/write Autocad dxf format drawings. http://www.ribbonsoft.com/qcad.html If there is interest I'll write up (as a hint or patch) the somewhat complicated process by which it can be built on an LFS system. It's dependent on qt-3.3.5 built a la BLFS. I'd like to see it in the wiki and/or a hint right now. We can probably put a link to the wiki in Chapter 37, Other X-based Internet Programs. Good idea. I hadn't thought about the wiki, it being so new and all. I'll see what I can do there. It won't be today though (Sunday). There are a couple of other application that I use that might usefully go there too. It's easier than a patch or a hint, as well as less formal. R. http://wiki.linuxfromscratch.org/blfs/wiki/InstallQcad I lied about not doing it today. :) R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: QCAD 2D Drawing Package.
Alexander E. Patrakov wrote: Richard A Downing wrote: http://wiki.linuxfromscratch.org/blfs/wiki/InstallQcad Thanks. A few notes: 1) A package installed in /opt is not allowed to have files outside /opt and /etc/opt 2) It would be nice to add some links, so that it this page is reachable from http://wiki.linuxfromscratch.org/blfs/wiki/BlfsNotes Alexander, Thanks for this. Very helpful suggestions. I'll fix it later today. Although I don't accept any 'rules' - this is my build and the FHS guys never asked my opinion :-) ... I was thinking that the single executable should probably go in /usr/bin anyway. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: QCAD 2D Drawing Package.
Bruce Dubbs wrote: Yes. I've been wanting to do the whole book, but I haven't made time for it. I want links in the book to the wiki and internal links within the wiki. I was very pleased how well the wiki formatting lines up with Manuel's style for the current book too. Sufficiently different so that you realise clearly that it's a wiki page, and yet familiar. It's significantly easier to write too. Of course, the wiki mark-up is just for formatting so you give up the index and glossary etc.. I'll definitely be revisiting my hints though. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: New BLFS Editor
Bruce Dubbs wrote: I would like to announce that Dan Nicholson has been appointed as the newest BLFS Editor. Please help me in welcoming him to the project. -- Bruce Oh dear, another lamb to the slaughter... Dan - Be afraid, be very afraid. (but Good Luck). R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
QCAD 2D Drawing Package.
I've been using this package for some time to draw my cabinet making projects. It's a good 2D package that can read/write Autocad dxf format drawings. http://www.ribbonsoft.com/qcad.html If there is interest I'll write up (as a hint or patch) the somewhat complicated process by which it can be built on an LFS system. It's dependent on qt-3.3.5 built a la BLFS. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: QCAD 2D Drawing Package.
Dan Nicholson wrote: On 2/25/06, Richard A Downing [EMAIL PROTECTED] wrote: I've been using this package for some time to draw my cabinet making projects. It's a good 2D package that can read/write Autocad dxf format drawings. http://www.ribbonsoft.com/qcad.html It looks cool to me, Richard. I like to see mature office-type apps in the book. Out of curiosity, how is it resource-wise? The binary is about 6M, and uses around 24M of virtual memory when running - the library list is quite long as with all qt apps. Of course the more complex the drawing the more memory it uses, I've seldom seen it over 28M though. CAD programs are always memory hogs, or they are two slow to use. Build takes about 8 SBU's, and the installed size is the 6M plus about 13M for fonts and pattern files - this can rise significantly if you want to have a big part library. It uses around 40M to build. Is this what you were interested in? R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Does anybody use text mail/news clients?
Bruce Dubbs wrote: Alexander E. Patrakov wrote: Hello, I was going to report two issues in the current BLFS, but when expanding snip OTOH, I have used nail on occasion, but certainly not regularly. It is most useful in sending messages from scripts, so that package should stay. Other opinions? I'm like you, nail on an infrequent occasion that I want to send an email from a script (like reporting success to a package author), but the others no. I've often thought of doing an User Agent: headers survey, but never got a round tuit. However, a quick dip into the recent postings here, shows quite a few mutts :-) Mutt is very well served with HowTos and other helpware too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
nss instructions and Domainname nitpick.
It's not so much a valid domain name that needs to be inserted as a domain name such that host.domainname will result in a valid DNS lookup. I, for instance, have a local DNS server that recognises 109bean.org.uk (which is valid, registered, responds to whois etc..) and my host, rad1, looks up fine as rad1.109bean.org.uk behind the firewall. However, I also own langside.org.uk (also valid, etc) but the host, being behind the firewall, can never be valid as rad1.langside.org.uk. I think the wording should say: 'a domainname such that host.domainname will be recognised by DNS'. Otherwise, my little test of the new instructions worked very well, thanks Randy. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Dependency Viewing
It was pointed out on Greg's DIY-Linux list that make can be used to print a dependency list - not nearly so beautifully as Nico's dependency graph, but as a useful list. I think it should be possible to generate the makefile directly from the BLFS Book XML, but I'm not competent to do this myself. A sample makefile was suggested here: http://mail.gnome.org/archives/gnome-hackers/2001-May/msg00120.html All that is needed is a simple list in the form, e.g.: libmng: libjpeg lcms for each package and a blank list for those with no deps. libjpeg: lcms: bc: all wrapped up with a bit of makefile magic. You can then type: 'make libmng', and get a list in the right order to build. Anyone suggest how to do this? R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GNOME IDE for Other Programming Tools
On Mon, 30 Jan 2006 17:16:25 -0800 Dan Nicholson [EMAIL PROTECTED] wrote: For example, I'm betting Alexander knows where some solid documentation for UTF-8 and udev are. But it's probably UTF-8 encoded - and in Russian! :-) R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: A2PS installation
On Tue, 31 Jan 2006 20:38:47 +0500 Alexander E. Patrakov [EMAIL PROTECTED] wrote: Hello, The make_fonts_map.sh script uses sort -0 +1 construction that doesn't work with Coreutils-5.93. Please adjust this script before installation: sed -i 's/+0 -1/-k 1,2/' make_fonts_map.sh Other notes are available at: http://wiki.linuxfromscratch.org/blfs/wiki/A2PS I changed the wiki to: sed -i 's/+0 -1/-k 1,2/' afm/make_fonts_map.sh since seds should assume that you are in the driectory where the source was unpacked. Otherwise - Good call. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Automated package building
On Sun, 29 Jan 2006 18:49:21 -0600 Randy McMurchy [EMAIL PROTECTED] wrote: Please, all, tear it apart and let me know where it needs fixing. I like it. Apart from the personal touches, of course. Does 'Cool, huh?' translate into Russian, Chinese, English? Perhaps 'Impressive, don't you think?' might be better. Also, most American style books say the the construct: clause 'which' qualifying clause, is wrong and 'that' should be used. However, 'which' is perfectly correct in modern English. (I hope I'm not being unecessarily nit-picking here?) Tongue firmly in cheek, BTW. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Wiki
On Fri, 27 Jan 2006 18:46:32 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: I just updated the book to add a chapter on the BLFS Wiki in Chapter 1. I also added a link to the appropriate page on the wiki to openssl as the end of the install section. I would appreciate readers of this list taking a look at the changes and provide me feedback. I am doing a special render of the book now and the changes will be abailable at http://www.linuxfromscratch.org/blfs/view/cvs/ in about 10 minutes. Thanks. Just an idea: Questions with your specific installation problems should be made by subscribing and mailing to the BLFS Support Mailing List at mailto:[EMAIL PROTECTED] This mailing list is mirrored as a newsgroup at news:gmane.linux.lfs.beyond.support. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Wiki
On Sat, 28 Jan 2006 11:42:51 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: Richard A Downing wrote: On Fri, 27 Jan 2006 18:46:32 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: I just updated the book to add a chapter on the BLFS Wiki in Chapter snip Just an idea: Questions with your specific installation problems should be made by subscribing and mailing to the BLFS Support Mailing List at mailto:[EMAIL PROTECTED] This mailing list is mirrored as a newsgroup at news:gmane.linux.lfs.beyond.support. Maybe we need to readd the news server page in the introduction. We never removed it from svn, but commented it out of welcome.xml. The orginal file had: paraAll the mailing lists hosted at linuxfromscratch.org are alg/ accessible via the NNTP server. All messages posted to a mailing list will be copied to its correspondent newsgroup. Note, however, that as this is written, it is not possible to write to the mailing lists via the NNTP service./para Is this still valid? No. The LFS news server was taken down as no-one could get it working reliably. The gmane newsservers have the same fuctionality and cover most, but not all,LFS mailing lists. There are some slight name changes though, so beware. You could add this: paraThe BLFS mailing lists are also accessible via the gmane NNTP server. All messages posted to a mailing list will be copied to its correspondent newsgroup. It is also possible to post to BLFS mailing lists via the gmane newsgroup, however you will be asked to verify your first such mailing. This service is not provided by the BLFS team, so see http://gmane.org/ for full details./para paraThe following table lists the newsgroup corresponding to each mailing list:para bulleted-list-cant-remember-the-tag itemblfs.dev gmane.linux.lfs.beyond.devel/item itemblfs.book gmane.linux.lfs.beyond.book/item itemblfs.support gmane.linux.lfs.beyond.support/item /bulleted-list-cant-remember-the-tag or something along those lines. But I think I'd rather you did the sort of thing I had in my first post. Just for info, although I'm subscribed to the (b)lfs mailing lists, I have delivery set 'off' and read and write the lists entirely via gmane. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tool to generate BLFS dependency graph
On Wed, 25 Jan 2006 14:27:11 +0100 Nico R. [EMAIL PROTECTED] wrote: I wrote a small program that allows you to get a graphical representation of the BLFS dependencies. snip Awesome! Thanks Nico. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Scripting Xorg-7.0
On Mon, 23 Jan 2006 10:48:28 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: Richard A Downing wrote: On Sun, 22 Jan 2006 23:17:24 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: I'm not opposed to adding a section on scripting packages. Chapter 2 seems to be the appropriate place for that. This seems a worthwhile project, I'll take a look at it. ( invites contributions ) As far as Xorg7 goes, there are two aspects to consider. The first is the LFS user who has no X installed. Most users will want to build everything at first. If a user is quite experienced, then he might want to build a subset of Xorg. Good thinking - I'd not considered these aspects. The second user is someone who has X installed and only wants to update a specific package or small set of packages. I think the right approach for BLFS is to provide a relatively efficient set of instructions that builds everything This implies a script to my mind, or at least a big chunk to be CP. I'm not a fan of big-chunk CP though - it's too easy to miss subtle things. It would be even better if any script was upstream supported - there must be projects on this. As a question, can one build 6.9.0 and then use the 7.0 packages to update parts of it? Do Xorg forsee a Garnome-like installer for Xorg-7.+ ? It would seem to be important. and also provide a discussion on how to build individual packages. This later explanation should be something like the explanation in the Perl Modules section where there is a generic set of instructions for the packages. Yes, the Perl modules page is a good model - it's exactly what I was getting at. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Scripting Xorg-7.0
On Sun, 22 Jan 2006 23:17:24 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: Probably not much, but it is a lot different from the rest of the book. There is also not much difference in just executing the commands in the proposed script. I don't know about you, but I script most of my packages. This is so I can reproduce the commands and instrument them for data needed by the book. It also facilitates logging of the output. We don't publish my scripts (or any of the other editor's scripts), but do publish the commands that go in the scripts. We need to keep this general 'feel' of the sections of the book so users can be comfortable and be able to learn what they need easily. I prefer to avoid a change in this paradigm as much as possible. I think we can do a good job with Xorg7 by just publishing the commands necessary. Users who want to script them, will do it on their own. My view (for what little it's worth) is that the BLFS book currently has about the right amount of information for someone who has built LFS to build packages. There might be mileage in (either a hint or) a preface/appendix section in BLFS on 'how to script (and log)', or 'approaches to scripting (and logging)', but it shouldn't intrude into the substance of the book. I see Xorg-7 as the division of X11 into 200-odd packages, no longer a whole. Each package provides useful functionality in its own right (to the same extent as the Gnome packages, anyway), and the impetus to the modular build is a way of letting each develop to their full. I, thus, would like to see BLFS with a chapter on providing X11 functionality that builds each package independently. To make this manageable you'll want to have some pages with lists of packages that can just be CMMI-ed after the build environment has been established. On those pages I would expect for each package: a URL, and a one-line description. If somewhere else we had a repository for useful scripts, thats another matter R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: popt's debian patch
On Mon, 16 Jan 2006 14:30:19 + (GMT) Ken Moffat [EMAIL PROTECTED] wrote: Agreed. AFAIK, nobody using the lfs family of books builds on m68k [ shout now if I'm wrong! ], I did have a certificate saying that I can program this beasty in assembler, but have never done so in anger. The certificate's date is interesting - 1976 I think. I also do Intel 4040. Hasn't cosmic-ray bombardment done for them yet? :-) R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg 7.0
On Mon, 9 Jan 2006 19:08:48 -0600 Tushar Teredesai [EMAIL PROTECTED] wrote: On 1/9/06, Bruce Dubbs [EMAIL PROTECTED] wrote: Tushar Teredesai wrote: Agreed, it should either be /usr (my preference) or /usr/X11R7 (the appropriate version). My preference is /usr/X11R7. Though that will break a lot of packages that hard code the paths to X (I think most of them check /usr, /usr/X11R6, /opt/X11R6, ...). This, IMO, is a 'Good Thing' (tm). Packages with hardwired paths are evil and need to be fixed upstream. From our perspective it should only be a sed to fix in the mean time. I like /usr as I don't see why x-windows is any different to, say, bash. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg 7.0
On Mon, 09 Jan 2006 18:22:22 -0600 Randy McMurchy [EMAIL PROTECTED] wrote: DJ Lucas wrote these words on 01/09/06 18:09 CST: I'll put up a more recent set if anyone would like to look at them that accounts for the issues that have been found recently. At this point, I can't help but think that 6.9.0 is the only way to go. Unless there is some good way to keep the building of Xorg in the spirit of BLFS (not completely automated), I can't see any value going to the 7.0, if 6.9.0 affords the same exact code with an installation method we all know and trust. Of course, we need to keep working towards the modular Xorg, but right now, I'm not sure this first release is really ready for us. The LiveCD notwithstanding. :-) I agree to some extent, but I actually learned a few new things from the samples pages in ~dj/blfs-xorg7. It's sometimes nice to break the mould, so that other approaches get better airings. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
On Mon, 9 Jan 2006 12:11:07 + Richard A Downing [EMAIL PROTECTED] wrote: On Sun, 08 Jan 2006 18:55:57 -0500 Jeremy Huntwork [EMAIL PROTECTED] wrote: I would really like to get everyone's opinion. All things being equal I think this looks like a good candidate for a complete replacement (1), but it isn't my call. Introducing the idea that the website would not be mirrored changes my preference - I had not realised this. It's not a good idea to rely on one server. Consider my support for (1) withdrawn. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Expansion
On Thu, 05 Jan 2006 00:59:12 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: The way I look at it, we have four possibilities: 1. Ignore the issues. 2. Add i18n / CLFS issues to each package as they come up. 3. Have a section or appendix in the book to address the issues and link each package to the appropriate part. This is the approach that has been taken for i18n so far. 4. Link each section of the book, as required, to an external wiki/web page to address i18n or non-x86 issues. #1 is not really acceptable because it is not being responsive to the community. #2 and #3 are essentially the same with the location within the book different. They do nothing to address the workload issues. I lean toward #4 right now because it would basically take the BLFS editors out of the non-mainline issues and let the experts in each area update as needed. We also have additional servers available that can distribute the load away from belgarath if necessary. I would like to open up a dialog of how to best handle the desires of the community. Also, the above list is not necessarily exhaustive. Other proposals would certainly be appropriate as a part of the discussion. I'm no longer an editor primarily because I am uninterested in the full pain of maintaining the xml, with the full testing of the packages, with the need to maintain a LFS-compliant system to test it, with the sysVinit bootscripts and a whole lot more, that I shall not bore you with right now. :-) I'm also not really interested in hints any more for similar reasons, plus 'I hate text documents without diagrams'. But if there is a wiki which can be used to contibute ideas and fixes then I would hope to be active in the areas that I feel myself competant. There are even a number of packages that I don't think should be in the BLFS book, but that are quite hard to build/install/configure that would look good in a wiki. A wiki would give people like Alex a place to explain why our ideas don't work in UTF-8, and we might even learn a bit about that. I realise that I didn't directly address Bruce's question which is strictly speaking just about i18n/clfs issues (and I can't, as a x86 English speaker, contribute much there), but the same infrastructure might (with your permission) be used to extend BLFS seamlessly into areas that it can't cover well, such as alternative booting schemes, and their impact on the BLFS packages. So I like #4. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Expansion
On Thu, 05 Jan 2006 20:09:04 + Andrew Benton [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote: I think I still prefer the wiki. And re-establishing a properly moderated and full-featured wiki could benefit the entire LFS community once again, not just BLFS. The only reason our old wiki was dropped was because of lack of use and poor moderation. If we have more regular users and a tighter setup, then the wiki could become invaluable to all projects. Yeah the wiki idea has it's strengths. People have more freedom to post stuff that they know about. But the experience of the LFS wiki suggests that it may not fit in with the culture of the LFS community. I remember going to the wiki a couple of times, there wasn't anything there worth reading, so I didn't go back. The only time I've found a wiki to be any use at all was when I was trying to get my tv card to work. Google I found a page in Ubuntu's wiki that told me stuff I hadn't found out in weeks of trying on my own. It was like gold dust. But still, I have my doubts because of the history of the LFS wiki There were several problems with the LFS wiki. 1) It was a solution looking for a problem - the people that pushed it wanted to play with wiki technology. There was no serious rationale for it in the LFS development process. 2) I tried to use it for Hint development, and because it was an unrestricted wiki - no registration enforcement - unknowledgeable Oiks kept screwing with my pages. 3) In the early days it didn't have page version tracking, and even later when it did, it didn't work properly. 4) Others used it for LFS book extensions (e.g. which distro's worked), but since it couldn't be part of the printed version - that was never going to work. A Wiki, and this goes for all collaborative writing really, only works if all the authors want to use it, and it supports the work they want to do. For BLFS the wiki needs to be a tool for trusted contributors, not open season. The way in should be 'Please Bruce, can I have write access to the wiki becuase I'm an expert in XXX?' not 'I filled in the web page with my nom-de-plume, and now I'm gonna write ungramatical drivel'. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Seasons Greetings
I shall be shutting down my systems tonight for the Christmas Holiday, back on Wednesday. SWMBO and I have to deliver Seasonal Cheer to various parts of the UK over the next few days. It has been an interesting year, moved house, became a BLFS Editor, started renovating said house, gave up editing, got tendonitis, took up Randy-baiting as a new hobby But seriously though folks, thanks for another fantastic year, well up to Scratch. Special thanks to Randy for putting up with me - I'll get you next year. A Happy and Holy Christmas to you and yours. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Firefox/T-Bird/Moz (looking for community input)
On Tue, 20 Dec 2005 15:49:48 -0600 Randy McMurchy [EMAIL PROTECTED] wrote: long and ugly Here we go: 1) +1 2) +1 3) The way I see it, the following dependencies can be adjusted as they either are a)not practical or b)cannot be used: A) +1 B) +1 - need Firefox to read book to install GNOME, damn it! C) Thank God. D) +1 4) +1 except: ac_add_options --enable-official-branding I like to see which Firefox I'm running - the precompiled one or one I built. 5) n/a 6) OK 7) not competent to comment. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Firefox/T-Bird/Moz (looking for community input)
On Tue, 20 Dec 2005 17:49:45 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: I did want to raise a related issue. Should we discuss adding plugins to support many of the pages on the web? Things like flash, audio and video, etc. Perhaps these should be on a separate page for plugger. I have to say that getting plugins working, which bits go whwre, which needs a symlink and musn't be a copy, etc, etc, etc... is the biggest learning curve on Firefox. Because FF has become so popular there are now too many guides out there and they contradict. I mostly find answers by searching the moz forums, but I have forums! A liitle clear 'this works - do it this way' for Java, Flash, PDF would be very useful. It's not necessary, but useful. A bit like explaining fonts for X11. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Firefox .mozconfig
On Tue, 20 Dec 2005 23:39:40 -0600 Randy McMurchy [EMAIL PROTECTED] wrote: Yeah. Functionally. But WTF is a Deer Park? A place you hunt old dears. Most Stately Homes in England have one, killing animals for sport is an old aristo tradition. At least they've given up hunding ph^heasants R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Font locations
On Fri, 16 Dec 2005 21:24:22 -0600 Randy McMurchy [EMAIL PROTECTED] wrote: Bruce Dubbs wrote these words on 12/16/05 21:15 CST: OK, we keep it for now, but I don't see the many reasons to keep it. Only because you have blinders on, and you have been the strongest, and only, proponent to remove XFree86. :-) Nop. I think it's a waste of resources and bookspace too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Why the lndir creation in Xorg/XFree86?
On Sat, 17 Dec 2005 21:49:16 -0600 Bruce Dubbs [EMAIL PROTECTED] wrote: Chris Staub wrote: In the build instructions for Xorg and XFree86, it is recommended to compile the lndir program and use it to create a shadow directory of symbolic links where you will actually built the package. Why is this done? Why not just a separate build dir? I think the BLFS book should have more of an explanation for this. Its what the developers recommend. See the BUILD file: So, in fact, if we obey our own rules and say 'Always unpack a fresh copy of the source for each build': we don't need to do this. Still, I've never tried it, has anyone? R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libungif and giflib
On Sat, 10 Dec 2005 23:50:12 -0600 DJ Lucas [EMAIL PROTECTED] wrote: Bruce Dubbs wrote: I am not very familiar with the libungif and giflib packages. the imlib instructions says one or the other. Are there any conflicts if both packages are installed? Is one preferable over the other, and if so, why? snip giflib is/was the way to go, so long as it was kept to date with the libungif version, which hasn't been an issue since 4.1.0b (again IIRC sometime in early/mid 2004?). All but the dates are mentioned in the intro for libungif in the book. Time was, when you could only use libungif without falling foul of the patent. Since 2004, as DJ says, there has been no reason to avoid giflib. I have not built libungif since about 2003, and everything works - you could thus easily drop libungif from the book. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ALSA modules and restore volumes
Alexander E. Patrakov wrote: Richard A Downing wrote: I'm sorry I started this again now. I have to say I am more confused than ever. Do the guys (I use the term loosly, as 'imbeciles' seems more appropriate right now) upstream have any idea of the difficulties they are creating by this almost undocumented mess? No, the major part of the mess comes from the premature desire to remove the hotplug package before upstream provides a patchless way to do so and doesn't declare it obsolete for at least a month (as happened with udevsynthesize). I didn't have a clue how to answer Alex's question. Where (or when) is the document you read to find out. (anyone replying 'read xyz mailinglist archives' may fall on his sword without further ado...) Enough information is contained in my message that contains the question. The key phrase is that one hotplug event corresponds to one directory in sysfs. I assume that you are able to find entries in your sysfs that correspond to each of your devices. For a USB printer with linux-2.6.14-rc4 there will be the following hotplug events (recorded with udevmonitor --env): First event: . Alex, Thanks for taking the time to write this. It is much appreciated. I am going to go very quiet for a few days while I make sure I completely understand it. It looks like experimental evidence is needed. All, I used to take the view (before I retired) that if: you found the right expert; were convinced they understood the problem; and then took their advice - that you didn't need to fully understand the topic yourself - indeed there were more complicated things about than one person could understand completely. Although I'm minded to trust Alex on this, perhaps it needs just a little more understanding on my part than usual. Thanks to all for their forbearance with the old fellow. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
ALSA modules and restore volumes
Guys, The method documented in the svn book doesn't work for me. The script that the 15-alsa.rules file associates with udev's discovery of a control interface is never apparently called (Udev-063). I also don't seem to be able to get the snd_pcm_oss module loaded, which is required for realplayer. I read though the long threads on this, and I'm not convinced that a proper solution has been found yet. Or is it perhaps that something necessary has been left undocumented. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ALSA modules and restore volumes
Alexander E. Patrakov wrote: Richard A Downing wrote: Guys, The method documented in the svn book doesn't work for me. The script that the 15-alsa.rules file associates with udev's discovery of a control interface is never apparently called (Udev-063). Now I have it working, and all I did was to to mv the rules file elsewhere and back again. This has me completely baffled :-) Of course, now that it works I can't do any more reseach into why it didn't. End of story. Sorry for the noise. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ALSA modules and restore volumes
Randy McMurchy wrote: Richard A Downing wrote these words on 10/25/05 10:51 CST: and that doesn't change anything. It still never calls the script. Now I'm out of ideas. You could always go back to the way it was by having it restore the volumes at boot (from /etc/rc.d/init.d/alsa): start) boot_mesg Starting ALSA...Restoring volumes... loadproc /usr/sbin/alsactl restore ;; Of course, create appropriate symlinks as well. Works for me. Yes, but I was TRYING to help debug the book's method. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ALSA modules and restore volumes
Jeremy Huntwork wrote: Richard A Downing wrote: Now I have it working, and all I did was to to mv the rules file elsewhere and back again. This has me completely baffled :-) Gremlins. -- JH Heck, do you think so? I saw that movie. Maybe I should burn the computer, or pehaps irradiate the harddrive! ;-) R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ALSA modules and restore volumes
Richard A Downing wrote: Alexander E. Patrakov wrote: Richard A Downing wrote: Guys, The method documented in the svn book doesn't work for me. The script that the 15-alsa.rules file associates with udev's discovery of a control interface is never apparently called (Udev-063). Now I have it working, and all I did was to to mv the rules file elsewhere and back again. This has me completely baffled :-) Of course, now that it works I can't do any more reseach into why it didn't. End of story. Sorry for the noise. Richard. Sorry to add to this. I guess the thing that hid the problem from me was the fact that the 25-lfs.rules file ALSO sets the group for alsa devices and places them in /dev/snd. This seems to be aberant behaviour, given that LFS doesn't install alsa. It convinced me that the 15-alsa.rules file WAS being processed, and that it was just the RUN+= that wasn't working. Had the 25-lfs.rules file not had and alsa in it, I would have seen the nodes in /dev with root perms. (Yes, I should have checked out the 25-lfs.rules file, but I didn't) Should we ask the LFS guys to take that out of their rules, so that we can deal with it in BLFS? This kind of relates to my comment that the explanation for some of this is buried in the LFS book (well the alsa modules stuff anyway). Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: UTF-8 in {,B}LFS
Bruce Dubbs wrote:
In some non-list traffic, there has been some discussion of UTF-8 for
{,B}LFS. I'm posting this discussion to the wider community for comments.
The question is: should {,B}LFS support UTF-8? If so, who will be
responsible for the UTF-8 specific portions of the books and how should
the material be presented?
I've always been in favor of making the LFS book 'UTF-8 ready'. I
supported Alex in his first attempt - which resulted in a partial
solution via the console bootscripts - and I continue to support what he
is doing with the UTF-8 fork (or whatever the official phrase is).
It seems to me that this is as much a political question as a technical
one. LFS is a global effort, despite its origins in the
Canadian-Nederlander past, and has taken contributions and enthusiasm
from many quarters, admitedly mainly from those who can join-in in
English. I note names that are clearly East Asian, as well as those
using St Cyrill's Fonts. It seems somewhat imperialist to ignore a
technology that could widen the project's inclusivity among those using
different characters - most especially Cyrillic, Chinese and Arabic.
However, that we need here is a framework that allows us all the work
from the same base. Not a Universal-LFS where everything works out of
the box in every character set in the known universe. The only people
who can validate, or even develop, a solution for their language are
native readers. The aim has to be to get the infrastructure support
technology right, not the detailed implementation. UTF-8 seems to be
the right balance, and I think, therefore that UTF-8 should become the
LFS baseline (in trunk) as some near date.
This implies that BLFS needs to change a little too, but as Alex says,
this is more to do with informed user's making sensible selections,
rather than throwing out perfectly good packages that just don't happen
to work with UTF-8 locales (or even with UTF-8 enabled systems) - there
may well be some packages we should add that ONLY work in Chinese or
Japanese in the longer term (we may be asked to do this by new friends,
and we should be open to that idea). I emphasise though that this needs
to be driven by those who can validate it, not by expecting Randy and
Bruce and the rest of us to understand how Chinese syntax works (I can
do Japanese at a pinch, though).
R.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: UTF-8 in {,B}LFS
Alexander E. Patrakov wrote: Richard A Downing wrote: there may well be some packages we should add that ONLY work in Chinese or Japanese in the longer term (we may be asked to do this by new friends, and we should be open to that idea). I emphasise though that this needs to be driven by those who can validate it, not by expecting Randy and Bruce and the rest of us to understand how Chinese syntax works (I can do Japanese at a pinch, though). Could you please download the latest UTF-8 livecd: http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r1-nosrc.iso and verify that Japanese (via Anthy + SCIM) works correctly in X? The setup differs from what is described in jlenv.txt hint because I wanted to aviod daemons as much as possible. Sorry for not including jfbterm. Alexander, When I say 'at a pinch', I mean: with quite a lot of trouble to set it up. It's not something I want to do - and I really do believe that a native Japanese speaker (not some westener who happens to have learned elementary Japanese and can read Hiragana, Katakana and a few hundred Kanji) needs to validate it. I'm not a fluent japanese speaker, and certainly not a fluent Japanese reader/writer. If there isn't a native japanese speaker in the user group, we shouldn't worry until there is. And I'm also busy with other things right now. Sorry. My mail to the list was meant more as a philosophical/political statement than a specific course of action. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: UTF-8 in {,B}LFS
Alexander E. Patrakov wrote: Richard A Downing wrote: Alexander E. Patrakov wrote: Could you please download the latest UTF-8 livecd: http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r1-nosrc.iso Is there a way of booting an iso without writing it to a CD? I have several spare partitions, but ATM no CD writer. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS package
Filip Bartmann wrote: Why isn,t one package with other packages in tar archive(as package lfs-packages.tar) for BLFS? Filip Bartmann Of course, you could volunteer to build and maintain (after every commit to SVN), and host (with good bandwidth) such a thing, Filip. If you work out the costs, I'm sure you'll see why no one else will do this. Cheers, R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Epiphany - PITA or worth it?
Randy McMurchy wrote: it seems so pointless to install Epiphany when it itself requires a Gecko rendering engine (Mozilla or Firefox or Thunderbird) as a required dependency. Despite not being a GROAN user myself, I can't see the point in putting all the rest of it in the book and then missing out it's preferred html viewer. I think you have to 'bite the bullet' and include all the deps. too. It's particularly important if they are not CMMI. I can't imagine someone who is already prepared to install the gazzillion things needed to get GROAN core running bitching at a couple more. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Remove GTK+-1?
Randy McMurchy wrote: Dan Nicholson wrote these words on 10/05/05 13:16 CST: As for gnome-1, I'm not sure why anyone would be using that. It is a must for GnuCash. Which is a really, really good financial/cash manager application. Of course, you have to have some cash R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Nothing Doing (longish).
sash wrote: All I do for the project is keep order, common courtesy and consideration on IRC and occasionally offer a grammar suggestion or find a typo in the book However, Gerard values my contribution even though it seems meager me. I value everyone's contributions and enjoy learning from all of you. We're a community project and you're an important part of this community. I hope you won't go away. Each of us is important in our own way. Kind regards, sash Richard A Downing wrote: To put it simply, I just don't enjoy being an editor - and I'm embarrased that I have not felt able to do more. Sash, I think you are on the right track (as usual). Occasional contributions are fun and seem worthwhile. Being a BLFS editor means responsibilities that I'm not sure I want. I like encouraging the cleverer people, like Jim - although I don't use his Cross-LFS book at all. And I don't intend to stop doing that, or writing hints when the mood takes me. If no-one minds me being an occasional editor though, maybe I'll just stay like that. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Creating users that don't need a specific group
Archaic wrote: On Mon, Sep 26, 2005 at 01:15:46AM -0500, Randy McMurchy wrote: Thoughts from the group would be appreciated... A generic users groups seems like it could be a security nightmare for a sysadmin. People who do need to share files generally belong to a descriptive group such as research, marketing, admin, etc... and they are put in those groups deliberately and not because useradd said 'x' gid was where they should go. I think that means that Randy is right, and we need a short explanation. Your reasoning should go in it. But in the end it's a sysadmin decision and will depend on the situation, and that needs to be made clear. There will always be a minority of BLFS readers who want a 'prescription', but we should tell them forcibly that they are going to have to 'think' rather than 'cutpaste'. I'd then change the package instructions to take out the prescriptive groups and say 'Create a unique group and unpriviledged user...'. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gcc-4.x installation
Randy McMurchy wrote: Richard A Downing wrote these words on 09/20/05 02:10 CST: For the record, I am still running a 200 Mhz Pentium MMX as my firewall, and don't plan to retire it any time soon. I also run a 133Mhz laptop, which is perfectly usable. And you compile fortran, java, ada, whatever compilers on these machines? If not, what is your point? I think that BLFS should just say how to build software. And I think that, in the case of GCC the BLFS instructions should use make bootstrap, becuase we can't guarantee that an identical version is being used to build it. My point is that I don't like people telling other people what to spend their money on. I always react badly to such statements on the LFS lists - sometimes I even post - as in the this case. Your post was an emotional outburst (Quote: Geez, this is just a couple tanks of gas in my Chevy pickup these days. ) So was mine. I'm real pleased you've agreed not to make further posts on this topic. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GTK-2.8.x
Kevin Jordan wrote: On 9/13/05, Richard A Downing [EMAIL PROTECTED] wrote: I just got though building it on the GCC-4 system. It appears to work well. (gtk+-2.8.3/glib-2.8.1/pango-1.10.0/atk-1.10.1/cairo-1.0.0) I was kind of surprised that nothing already linked to gtk/glib broke either :-) (firefox-1.0.6/thunderbird-1.0.6/bluefish-1.0.2) Gnome/KDE is too big for me, [Openbox-3.2]. R. -- Had you linked firefox to cairo previously? No. This was the 1st time I built cairo on that system. Which explains it I guess - it's not trying eithe or the APIs. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Recommended dependencies.
Bruce Dubbs wrote: Seems reasonable to me. Want to take a stab at it? It should go in the Important Information chapter, but I don't know if it should be a new section or a subsection of Notes on Building Software. -- Bruce Done. Perhaps someone will check that I used the most appropriate markup, and that the definitions agree with prior art. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: kde dependencies
Bruce Dubbs wrote: snip I'm inclined to add these to the book with the exception of krb4 (because we already have krb5). Opinions? There seem to be a lot of new packages going in recently. I thought (but this might hark back to Larry-days) that there was pressure to exclude things that are both obvious-to-build and of-minority-interest. Personally, I like to see packages in the book, but remember the support and maintenance load. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS 6.1 is released
Bruce Dubbs wrote: Tushar Teredesai wrote: We were on break for the last couple of weeks :) So now it is B2W. Not *all* of us. :) -- Bruce Ah! The priviledges of rank. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Chapter 1 ordering/contents
Bruce Dubbs wrote: The dicussion on blfs-dev and lfs-dev about the changelog has brought up an issue that I'd like to discuss. Is the order of topics we have in Chapter 1 optimal? Do we need to add or delete any topics? Right now we have: snip Comments? I'm happy with the consensus on your suggestion achieved by the colonists and night-owls :-) but would like to add this into the idea melting-pot: One of the enduring FAQs on BLFS is the build order/dependency sequence. I note another discussion of it in the thread 'GCC-3.3.6' between Greg and Randy. I've often thought it would be nice if there were a few sample builds, say 'Office Workstation', 'Author's Workstation', 'Secure Mail Server' or similar. These would be a selection of the BLFS pages hyperlinked with a narative showing the new reader how these are typically built using the BLFS instructions. We could then use the samples as QA scripts. I would be quite keen to write some of these myself. I have more to say on this is it meets general acceptance, but I'll reserve that if the idea is rejected (and so save my fingers ;) Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Editors' Guide Updates
Bruce Dubbs wrote: I've just committed several changes to the Editors' guide. Please take a look and see if thee is more needed. I specifically addressed the issues in bugs 1480 and 1486. http://www.linuxfromscratch.org/blfs/edguide/index.html -- Bruce I'm still reading and digesting - looks good so far... :-) But here are a few typo's that need fixing when you can spare a moment - or should I just commit them? Chapter 1: You can see that the files is ... You can see that the file is ... Chapter 4: If it's just t temporary If it's just a temporary Chapter 5: It's assume you have already logged It's assumed you have already logged Select the proper Version. You most always will choose the CVS version. (Note: SVN will be added to the options. Use that if you see it.) Select the proper Version. You most always will choose the SVN version. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GCC-3.3.6
Randy McMurchy wrote: Any help would be appreciated. I patched it too (gcc-3.3.6 on my gcc-4 system). Script say: patch -Np1 -i ../gcc-3.3.4-no_fixincludes-1.patch patch -Np1 -i ../gcc-3.3.4-linkonce-1.patch Log say: patching file gcc/Makefile.in Hunk #1 succeeded at 2341 (offset 6 lines). Hunk #2 succeeded at 2376 (offset 11 lines). patching file gcc/config/alpha/alpha.c patching file gcc/config/arm/pe.h patching file gcc/config/avr/avr.c patching file gcc/config/darwin.h patching file gcc/config/i386/cygwin.h patching file gcc/config/i386/i386-interix.h patching file gcc/config/ip2k/ip2k.c patching file gcc/config/mcore/mcore.c patching file gcc/config/rs6000/xcoff.h patching file gcc/doc/tm.texi Hunk #1 succeeded at 5930 (offset 28 lines). patching file gcc/final.c patching file gcc/output.h patching file gcc/target-def.h patching file gcc/target.h patching file gcc/testsuite/g++.old-deja/g++.other/comdat4-aux.cc patching file gcc/testsuite/g++.old-deja/g++.other/comdat4.C patching file gcc/varasm.c Works fine. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GCC-3.3.6
Randy McMurchy wrote: And your theory that it was applied to the 3.4.x and above branches make sense. Just noticed that in the 3.4.4 patch Jim Gifford says 'Upstream Status: Delayed till 3.4.4' ( it IS 3.4.4 !). So I guess it wasn't, and hence needs to be the LFS Ch6. My best guess is that it is still needed for those apps that needed it before - I'm not qualified to make that determination though. I tried to talk to Jim on IRC, but he is AWOL atm. I vote: leave it in and commit the patches. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: The trunk Changelog.
M.Canales.es wrote: Hi, Now that the trunk Changelog is yet small, maybe we can move on their format to the new layout used in the cross-lfs book. See, for example, the Changelog entries section in http://www.linuxfromscratch.org/lfs/view/cross-lfs/x86/introduction/changelog.html IMHO, that layout is more clean and easy to read. If the change is wanted, I can do it when accepted this propossal. I'm not in favour of this. I like the strict chrono order of the current changelog. IMO, the new one is more cluttered (more sections), and I find it more difficult to find what I want ( the list of changes since I last looked ). I'd go so far as to say I think LFS should go back to the BLFS way! -1 Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: The trunk Changelog.
Randy McMurchy wrote: M.Canales.es wrote these words on 08/17/05 13:43 CST: I'm speaking about the real changelog entries, the ones grouped by date and divided by editor/change. Oh, well why didn't you say so? :-) Seems to me the only difference is that the date is only listed once for each day there is a change. Everything for that date is then listed under that as a sub-bullet. Is that correct? If so, then I like that change. It does appear a tad neater without having the date on every line item. Me too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: The trunk Changelog.
M.Canales.es wrote: El Miércoles, 17 de Agosto de 2005 20:44, Richard A Downing escribió: M.Canales.es wrote: I'm not in favour of this. I like the strict chrono order of the current changelog. IMO, the new one is more cluttered (more sections), and I find it more difficult to find what I want ( the list of changes since I last looked ). The chrono order is already on that new layout. For each day, the more newest change should be placed above of the other ones. All I WAS objecting to was the sections BEFORE the changelog in the example cited. I don't like that even in LFS. I'm happy with the proposal to group all entries on the same date together if everyone else agrees. But consider this: The current format works well too - and has the advantage of being searchable in the rendered version with the results each containing a date. Of course one can always search the XML and get that functionality. Does this mean a big change in the markup that we have to edit - does it introduce any more error prone-ness? R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GCC-3.3.6
Randy McMurchy wrote: Richard A Downing wrote these words on 08/17/05 12:33 CST: Just noticed that in the 3.4.4 patch Jim Gifford says 'Upstream Status: Delayed till 3.4.4' ( it IS 3.4.4 !). So I guess it wasn't, and hence needs to be the LFS Ch6. My best guess is that it is still needed for those apps that needed it before - I'm not qualified to make that determination though. If so, this discussion needs to be moved to LFS-Dev. Keep trying with Jim, see what he says. Thanks for the research OldFellow. :-) OK, Jim says it should have gone in to 3.3.6 (bug #16625 and #16276 in gcc bugzilla), but for some unknown reason didn't. So keep the patch. The upstream status should probably be 'Accpeted, but implementation delayed', I guess. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Creating logs of builds (was - Re: Addition to Chapter 12)
Tushar Teredesai wrote: On 8/9/05, David Fix [EMAIL PROTECTED] wrote: Though I don't have an install.log file... Is that standard? (Aw crap, now I'm showing that I don't know how to create this file! :P) See the last paragraph in http://www.linuxfromscratch.org/blfs/view/svn/introduction/unpacking.html. I've become rather fond on the style shown in Bruce's SBU pages: http://linuxfromscratch.org/~bdubbs/about.html it neatly gets you: 1) a log 2) the time it took recorded in the log 3) a deeper understanding of how the shell works :-) My way now is never to type the commands directly, but create a scriptlet for each package built from a template that is essentially Bruce's script plus some checks. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Working towards 6.1 final
Bruce Dubbs wrote: Guys, As I review bugzilla, there are seven bugs against 6.1-pre1: 1491, 1497, 1507, 1508, 1510, 1512, and 1513. I know that MIT Kerberos (1350) has also been updated in the trunk and could be integrated into 6.1. Does anyone know of any other outstanding issues? I intend to fix the above bugs in the 6.1 branch today. I can then create a -pre2 or a final. Does anyone have a preference either way? -- Bruce Probably stupid New-Boy question: How are these -pre releases validated? Is it (1) just a matter of putting it up there for a bit to see if anyone finds a bug? Or is there (2) some rigourous methodology being followed by someone to ensure everything works (together)? In either case I think I agree with Randy. The bugs found seem to be quite interesting and are throwing up significant improvements to the book. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GCC-4.0.1
Randy McMurchy wrote: Hi all, I'm just about finished building the GCC4 branch of LFS which is (I believe) trunk using GCC-4.0.1. Me too (built LFS GCC4-20050730 on my Athlon XP). So I'm ready to help validate the branch. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GCC-4.0.1
Randy McMurchy wrote: However, I think you misunderstood the purpose of my message. No. I understood it completely, I was just making sure you knew about the link while I thought some more about your ideas. :-) I'm not so much looking for advice on *how* to get things to build, I'm more looking for a community decision (branch, whatever) on how we should go about *presenting* this information to the community. A branch is the right way. If I understood your plan 'a placeholder in place of the real instructions' in a branch, then many, probably working, packages will be ommitted. Of course, a user could just nip over to 6.1, but why make him bother. Can't we do a blanket 'WARNING not validated for GCC-4 yet - please report success to ...' insert into all package instructions? Essentially, I'm saying the placeholder should be the GCC-3 instructions with a warning. I think you will be surprised by the speed with which GCC-4 will become the mainstream for LFSers. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Firefox build [was: r4854 ... in -book]
Jeremy Huntwork wrote: Jeremy Huntwork wrote: The build method is pretty stable and I would venture to guess doesn't suffer from the same whitespace issue. Just realized that of course you'd still have to be careful for whitespace due to line-wrapping and presentation of the commands in the BLFS book - wasn't thinking too clearly there. However, we chose to used that particular build method over BLFS's as it's the officially suggested and supported method and it makes it easy to maintain with the numerous configure options kept neatly in a separate file. From my conversation with other random LFS users, I'd gather that most (especially those who have been doing this for a while) don't use BLFS's build-method for Firefox either. -- JH Well I have to say that, with the proviso noted above, I've always used BLFS with excellent results. That said there is a rising head of steam to change. I would suggest that we look at it, post 6.1 release. It will need testing against all the options (which the LiveCD doesn't use, e.g. gnomeVFS). Would we want to do the same for thunderbird and mozilla? Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Upcoming package freeze
Bruce Dubbs wrote: Bruce Dubbs wrote: Just a heads up. I will be going through BZ again tonight and re-examining the outstanding bugs for the 6.1 release. When that is done, I anticipate a package/bug freeze sometime tomorrow. After that, the only non-targeted changes should be P1 (security) bugs. When all the targeted bugs are fixed, I'll generate the -pre1 release. OK, I've gone through Bugzilla again and made a few changes. :) There are now 25 bugs targeted for 6.1. Most are text changes. I left the following packages that need updates. Bug Package 1420 iptables 1183 exim 1350 kerberos 1430 LIBPCAP 1443 Firefox 1444 Thunderbird 1459 Mozilla 1369 Tidy 1475 Ethereal I chose these because of either security issues or because of the popularity of the packages. Also, they are not, for the most part, dependencies of other packages. Note that I also added a 6.2 target to bugzilla and a separate 'Product' for the editors guide. As of this time, I would like to freeze all other package updates until after the 6.1 branch is cut. I am targeting Monday for the -pre1 release, so any help in hammering out the 6.1 bugs will be appreciated. If anyone thinks that I left out something critical or put in too much, please let me know. -- Bruce I'd like to add fcron-2.6.7 (Bug#1482) because I'm updating the text to fix bug#1472, and it has a fix for a nasty mailing bug. I have to text it anyway. Richard. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Evolution-data-server
This says that it has a dependency on Mozilla. In fact either Firefox or Thunderbird will do too (you might even be able to use Netscape). If you do use those then you need to add something like: --with-nspr-libs=/usr/lib/firefox-1.0.3 --with-nss-libs=/usr/lib/firefox-1.0.3 --with-nss-includes=/usr/include/firefox-1.0.3/nss --with-nspr-includes=/usr/include/firefox-1.0.3/nspr to the configure so that the script will find the libraries. This is, of course, covered by the note on optional dependencies, but I wondered if it was worth a special mention, since many people will be building 'fox/'bird instead of moz. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
