Re: [lfs-dev] Bump Linux Kernel Requirement
On Sat, 06 Jul 2013 15:22:01 -0500 Bruce Dubbs wrote: > Armin K. wrote: > > On 07/06/2013 09:53 PM, Bruce Dubbs wrote: > >> Armin K. wrote: > >>> We probably missed this one: > >>> > >>> https://git.kernel.org/cgit/linux/hotplug/udev.git/plain/README > >>> > >>> Requirements: > >>> - Version 2.6.34 of the Linux kernel with sysfs, procfs, > >>> signalfd, inotify, unix domain sockets, networking and hotplug > >>> enabled > >> > >> These all seem reasonable. > >> > >>> I suggest we build everything for 2.6.32 kernel from now on > >>> (glibc's --enable-kernel switch). Why 2.6.32? Well, It appears no > >>> distro yet builds with anything higher than that. > >> > >> Setting --enable-kernel='' in glibc only specifies what > >> compatibility to include in the glibc libraries. I have no > >> problems with adjusting it, but think that 2.6.34 would be > >> better. The only reason to not have --enable-kernel=current is to > >> allow users to boot an LFS system with an older kernel. There > >> appears to be a udev requirement for 2.6.34, so it would make > >> sense to me that the --enable-kernel value should be the newer of > >> the distros kernels and udev. Since udev needs 2.6.34, then the > >> user shouldn't try to use the LFS system with a kernel older than > >> that. > >> > > > > Sure, do what you think is okay. I was thinking about the > > > > " --enable-kernel=2.6.25 > > OK, I'll change it to 2.6.34 > Wouldn't be prudent in chapter 5 to set it to the running kernel, so there is less probability of a glitch in chroot. Chapter 6 may be OK. --- Dave -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.16 gcc omit-frame pointer
On Wed, 01 Dec 2010 15:54:32 -0600 Randy McMurchy wrote: > Bruce Dubbs wrote these words on 12/01/10 14:50 CST: > > In Chapter 5, we are not doing a full bootstrap, so we add > > -fomit-frame-pointer so it will produce the same codes as if it was > > a full bootstrap. > > > > In Chapter 6, we do the same thing. I think, but I'm not sure, > > that -fomit-frame-pointer is the default for x86_64. If this is > > correct, perhaps we can tweak the text a little to clarify. > > I seem to recall reading in the GCC mailing lists that > -fomit-frame-pointer is the default on all builds now. I don't recall > what version this was started. It would be easy enough to find out. > Anyone with a x86 could start a GCC build and look at the first few > times in the log where something is compiled and see if the flag is > in the line. If you see it once, you will know it is now default. > I have tried that, no the flag does not appear. But why would it if the default was otherwise? I have tried no flag, '-fomit-frame-pointer' and '-fno-omit-frame-pointer' with no difference in the cpp binary. I don't understand the whole thing. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.16 gcc omit-frame pointer
On Wed, 01 Dec 2010 11:38:06 -0600 Bruce Dubbs wrote: > David Jensen wrote: > > > The point of the thread is that the 'chapter 5 gcc pass 2' and the > > 'chapter 6 gcc' instructions and explanations are inconsistent, > > confusing and wrong for all but i?86. Maybe even completely > > outdated. > > I'm not an expert on compilers, but the GCC instructions in Chapter 5 > and Chapter 6 need to be different for our purposes. > > What we have now works. I'm reluctant to change the instructions on > such an important component unless there are clear advantages. > >-- Bruce Well, maybe I'm nitpicking but 'chapter 5 gcc pass 2' says if you have an x86 do this, while 'chapter 6 gcc' says for consistency do something else. The 'chapter 6 gcc' instructions do not work to give consistency on x86_64. IMHO --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.16 gcc omit-frame pointer
On Tue, 30 Nov 2010 22:59:35 -0600 Stuart Stegall wrote: > On Mon, Nov 29, 2010 at 11:09 AM, David Jensen > wrote: > > Note: Section 5.10, “GCC-4.5.1 - Pass 2” does not use a case > > statement for the frame-pointer. Problematic for x86_64? Perhaps > > both sections should be: > > > > gdb on AMD64 uses stack unwind instead of the frame pointer. The > default on x86 is still to use the frame pointer. The frame pointer > is really unneeded unless you have a compiler that doesn't put enough > stack info into the binaries. > > http://www.yosefk.com/blog/getting-the-call-stack-without-a-frame-pointer.html > <<-- more than you ever wanted to know about the call stack, frame > pointers, and unwind. > > gcc-4.6 will make -fomit-frame-pointer the default on Linux/x86. a fedora thread on debugging/profiling issues at: http://lists.fedoraproject.org/pipermail/devel/2010-November/144952.html but I am not, and I don't believe most LFS users are interested in *system wide* debugging/profiling. Thus omitting the frame pointer generally is a plus. The point of the thread is that the 'chapter 5 gcc pass 2' and the 'chapter 6 gcc' instructions and explanations are inconsistent, confusing and wrong for all but i?86. Maybe even completely outdated. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
6.16 gcc omit-frame pointer
Note: Section 5.10, “GCC-4.5.1 - Pass 2” does not use a case statement for the frame-pointer. Problematic for x86_64? Perhaps both sections should be: case `uname -m` in i?86 | x86_64) sed -i 's/^T_CFLAGS =$/& -fomit-frame-pointer/' \ gcc/Makefile.in ;; esac --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grammar correction chap 4.1 LFS 6.6
On Tue, 09 Mar 2010 14:02:20 -0600 Bruce Dubbs wrote: > > There is still an implied 'command' there, as in: > > as when doing a suu [command] to root. > > I used suu here to emphasize the pronunciation. > I always use 'an' before soft consonents. It 'may' be incorrect but it flows off the tongue better. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: klogd and System.map
Bryan Kadzban wrote: > Bruce Dubbs wrote: > >> To stop klogd from trying to read System.map, it requires passing -x >> in the command line. We can do that easily in the boot scripts. >> > > Which I would suggest if we want to silence the warning. Given the > (total lack of) need for System.map for the past seven years, I think we > should also expunge any reference to it from the book, but whatever. > > from slackware rc.syslog # '-c 3' = display level 'error' or higher messages on console # '-x' = turn off broken EIP translation so, I'm using loadproc klogd -c 3 -x --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: I got error at chapter 8.4. GRUB-0.97
On Thu, 22 Oct 2009 16:05:19 +0800 (CST)
kevin631012 wrote:
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry "GNU/Linux, Linux 2.6.30.5" {
> insmod ext2
> set root=(hd1,2)
> search --no-floppy --fs-uuid --set
> e4adbac2-a338-4305-bafe-73f2adb307da
> linux /boot/lfskernel-2.6.30.5 root=/dev/sdb2 ro }
should be set root=(hd1,1) partitions start at 0, same as drives.
maybe
---
David Jensen
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: The time has come
On Sat, 25 Apr 2009 10:00:52 -0700 Dan Nicholson wrote: > Hi everyone, > > ... > it's time that I step away from my duties as an editor for LFS and > BLFS. > Dan, I will miss your input! Please keep in touch. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Changes in the LFS build procedure
On Tue, 03 Jun 2008 17:10:00 -0500 Bruce Dubbs <[EMAIL PROTECTED]> wrote: > 1. Both bootscripts and udev-config directories have been moved to be > under the BOOK directory. > I see the bootscripts/ChangeLog is not ASCII, and hasn't been for four years: failure in the init.d/checkfs script. Tested with the help of Andre Müller. Fix suggested by Zack Doesn't really matter, but it should be ASCII. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: dhclient in LFS
On Thu, 22 May 2008 18:15:40 -0600 Gerard Beekmans <[EMAIL PROTECTED]> wrote: > One of the solutions that came from the udev discussion the last few > days was to move dhclient from BLFS to LFS. Or leave it in BLFS but > also install it in LFS. > > I know we've had the discussions before in the past. I'm honestly not > sure anymore what the outcome of that was. > > Gerard I need ppp, I have no use for dhcp. ymmv --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Format for the future LFS
Alexander E. Patrakov wrote: > > Unfortunately, the current DocBook toolchain is meant to produce a > single book with instructions that are meant for copying and pasting. > It is not suitable for generating both the non-PM-aware instructions > and spec files from the same source, and is not able to modify the > surrounding text accordingly. Worse, we don't even have a mockup HTML > of how this should look like! > As Gerard suggested, the instructions should not be considered relevant to the content displayed. "Who, What, Why, When and Where". "How" can be discovered by just viewing the (chosen PM) spec and invocation script as they are, plain text. Whether the chosen spec is RPM, DESTDIR or NONE should ideally affect only the "Where" text. In other words the text could be a simple "toXML markup". Script and PM selection are where the problems are. All supported PM's in all Packages/Modules: That is a great endeavor. That's my take. David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Gettext-0.17
I saw in a Genntoo newletter: Gettext-0.17, in LFS-SVN, includes a subset of libXML. Investigating, it includes a small subset of glib, a large subset of libXML and all of libcroco. Rebuilding using the installed packages is broken, configure doesn't correctly detect libXML and mangles the -Iinclude for libcroco so that it won't compile. I gave up on rebuilding it. YMMV --- Dave Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Clearing things off and getting going - again...
Alexander E. Patrakov wrote: > I am very surprised the nobody replied to my mail with the subject > "RPM: proof of concept". It is lost in the thread. With threading on, I am struggling to find it again. You might start a new thread. I haven't tried your method but I expect it works as advertised. It is complete to start a deployment POC. Note though: Agnostic PM's including a 'basic no pm' need be supported in the POC. we already know it can be done. Where is Manuel? His input would be helpful. As always, your insight and productivity amaze me. --- David Jensen -- 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: > > [~] I am an editor of LFS or one of the related projects > [X] I use LFS as my primary Linux system > [ ] I use LFS on more than one PC (including virtual machines) > [ ] I deviate a lot from LFS (not counting package updates as deviations) > [ ] 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! > (~) I trust the lists of files in the book > (X) 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 > (X) Other I scripted a 'Paco' chapter-6 build, but, I didn't get the habit for BLFS. In the end, I had all the wrong packages logged. > I use the following features provided by a package manager: > [X] Knowing where each file comes from > [X] Clean uninstallation of a package > [X] 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 > [~] Will clobber configuration files wen upgrading package versions > [X] Doesn't explain how to package software beyond BLFS > [ ] Requires learning another language/syntax besides bash shell syntax > [ ] Exists at all > --- David Jensen -- 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
George Makrydakis wrote: > You know what? This can work on windows as well. LOL, and joe-sixpack visits LFS and clicks install ubuntu clone now! --- David Jensen -- 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
George Makrydakis wrote: > Actually, what is necessary is to have a system that deals with dependency > resolution outside and over any package manager involved in this process, for > obvious reasons. Transforming the content from a new "book" format into RPM, > DEB, TGZ or requires a system comprised > of filters so that we have the following: > > xmldatabase (XML contents) --> RPM filter --> rpm build instructions > xmldatabase (XML contents) --> DEB filter --> deb build instructions > ... > xmldatabase (XML contents) --> A filter --> A package manager filters. > > but also: > > xmldatabase (XML contents) --> xhtml filter --> xhtml format for instructions. > > xhtml filter => can be customized by the end user. > > In a few words, the essential representational unit of this problem is the > following: > > XML Database --> filtering() --> Filter result > > Where one important aspect is that the various filtering() calls can > cooperate > with each other before final output. What is important is that they dump to a > format that can be understood by a package manager, a browser, a text editor > or a video player (to make an extreme but unpurposeful example). > > > Providing means to create these filters waives the need from the community to > have to do support on different dependency resolvers, resulting in further > LFS fragmentation. However, it also allows end users to refine the process if > the xml database upon which the system relies is complete enough. The single > link then, is the verbosity of the XML to be used. > > In a few words, the engineering and design tasks you are to undertake are not > resolvable by a script - oriented language without resorting to multiple > dependencies that will cause maintenance break ups. Not to mention the > performance issues. > > Relying on a more suitable language like C++ about this also has the > advantage > that it is possible to reuse the same code and craft it into an Apache module > ( http://www.zarfmouse.us/apache-cplusplus/ ). This can have several > consequences on the design of a web platform and stand - alone. > > In stand - alone for example, because of its nature, it is easy to make it > interact via the right bindings with other more "user friendly" languages for > a quick end result. Many projects use bindings for this. Through JNI you > could work with Java as well if you want to do that. And if you want to work > with the terse but efficiently put Haskell flavours, you will be welcomed to > do so, if anyone is interested in providing these bindings. > > In web - oriented mode, and we are talking about web applications, the same > can be said with the use of apache dedicated modules. Use everywhere, easily. > Rapid development. And of course, performance. > > One solution to all the problems is would be to have a single implementation > for these things that makes things easy to develop further once there is a > need, without having to rewrite everything. > > This is what I am trying to do, firstly, with odreex. > > Tell me what you think. I think you're on track. Excepting only that 'I' think XML is 'cutting butter with a chainsaw'. XML is unambiguous and if auto-generated I won't object. That said, are you thinking a lib and or libs and implementations or just the mod/standalone implementations. Gui? --- David Jensen -- 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
TheOldFellow wrote: > On Wed, 27 Feb 2008 16:06:41 -0700 > Gerard Beekmans <[EMAIL PROTECTED]> wrote: > >> What if LFS wasn't in book form anymore. What if it's an interactive >> program instead. A 100% merge of LFS, BLFS, ALFS, LFS. > > > I like this. > > The design could be quite difficult as it probably will > need to run in a number of environments (X11 and not, for instance), and > could allow for various multimedia presentations during the > installation - sound, flash, html, as well as text, come to mind. The easiest interface would be adding a .alfs handler to Firefox. Configuration of defaults done the same way. I'm not sure about text browsers. > There needs to be a non-interactive switch, a quiet switch, and a > dummy-run switch too. Buttons could be added? > How to handle upgrades? The discussions on PM's have been interesting, > I favour using an existing PM, but other than that, I'm easy. Also handling overlapping dependencies between modules requires a PM that checks what is already installed. --- David Jensen -- 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
George Makrydakis wrote: > On Saturday 01 March 2008 00:55:04 David Jensen wrote: >> If I might suggest: Use Gerard as an arbiter, it is his project. >> > > Glad to hear about this. > Don't mention it. At my age, I need reminded, can't say if Gerard does. --- David Jensen -- 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
George Makrydakis wrote: > > This means that there is always the benefit of the doubt. If you want this > settled, you know where and how to find me. If this is a misunderstanding ,it > is a long standing one and I propose we resolve this now before everything > else. It would be of mutual benefit. In private. > If I might suggest: Use Gerard as an arbiter, it is his project. --- David Jensen -- 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
Bryan Kadzban wrote: > On Fri, Feb 29, 2008 at 03:31:28PM +, [EMAIL PROTECTED] wrote: >> I would like to see UTF-8 in LFS. > > I thought it was? Or at least, I thought LFS was UTF-8-ready. (I don't > think we want to enforce UTF-8 on everyone, though.) > >> I'm not sure I like using XML for building packages. I prefer reading >> scripts. However, I do see some benefits and I am not opposed to it. > > With a perfect setup, the XML could produce some scripts that you could > read. In fact, I bet this is what several of the *alfs projects do (or > did, or can do). ;-) > > Of course, hacking on the scripts and then trying to merge the results > back into the XML might be painful... > > I would rather see the scripts in a much simpler form. For display, XML probably could be generated with an 'asciidoc' filter, but such scripts don't need formatting anyway. I don't believe XML is intended to be hand written. --- Dave Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gtk+-2.8 tombstone
Randy McMurchy wrote: > David Jensen wrote: > >> Until we update glib, cairo, atk, pango and gtk everything is behind the >> 8-ball. >> > > Agreed. I will update all the above packages by the end of the > upcoming weekend. I'll also place a note in the GNOME instructions > that currently the GNOME instructions are broken and to use the > stable book for proper packages to support BLFS GNOME (I'll also > mention that to use the updated BLFS support packages (glib, etc.) > you'll need to use GNOME >2.14.3. > > And in response to a question later in the thread, we will skip > GNOME-2.16.1 and move straight to 2.18. This probably requires > updating HAL as well (not sure). We'll need to create some sort > of plan on who will do what in what timeframe. > > I could have GNOME updated to 2.18.1 in about a week after its > release. But I'd also like to have all the support packages > updated as well when GNOME is updated in BLFS > > I can start on some of the support libs, etc libgsf, librsvg libwnck libgtop vte intltool I'll hold them for your gtk update. and good night to all! --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
medit text editor
Has anyone else tried this. In my opinion it is the best GTK+-2 editor, and I've tried a few. From the author: But, I am not going to have more dependencies than needed. E.g. python is cool and provides lot of useful stuff, but the core works without python. The dependencies are: gtk, obviously (gtk-2.6 minimal; gtk-2.2 could work if one tried really hard, I did it in past when had systems with gtk-2.2; gtk-2.8 is the best because of important gtk bug fixed; gtk-2.10 is needed for printing); libxml2 is not a hard dependency, but highlighting needs it. http://mooedit.sourceforge.net/ Though it is CMMI, documentation is scant, and some notes on run-time configuration files could be a help. Any way I think it could be added to the book, or just noted in other editors. thoughts from editors? --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: ImageMagick "make check"
David Jensen wrote: grrrlgeek wrote: make check should only be issued after make install. It barfs spectacularly if run before install. Hmmm, it didn't barf here. I'll try it again on a partition were it isn't installed. It still didn't barf here. I moved it anyway, obviously it is a problem for others. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Dependency on libiconv in J2SDK-1.4.2 ?
Matthew Burgess wrote: Tushar Teredesai wrote: Perhaps we should have a note in the glibc instructions that libiconv should not be installed since it is incompatible with glibc. CCing lfs-dev for their consideration. Well, I'm still sitting firmly on the fence with this one :) Do we know roughly how many packages might cause one to think that libiconv is required? Here's how I currently see it: I believe AbiWord has it in the README. Gnome used to have it on their pre-requisites page, it may still be there. 1. All affected packages are outside LFS Yes, probably should be in BLFS. It's not a FAQ but there was a thread last month (fontconfig) and again now this month. If a person installs in /usr the iconv.h header is a goner. Probably it could be pulled from he glibc tarball, I haven't looked. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New BLFS Editor
Bruce Dubbs wrote: Please help me in welcoming Richard Downing (aka TheOldFellow) as a new BLFS Editor. Richard has been contributing to the lists since 2002 and will be a valuable asset to the BLFS Team. -- Bruce Sure, welcome aboard Richard! Remember to keep a sense of humor, KDE-3.4.2 is out, Bruce committed 3.4.1 yesterday! :-) -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
File-4.14
While downloading File-4.14 I saw there is an official patch in. ftp://ftp.gw.com/mirrors/pub/unix/file/ It appears to fix 2 minor nits in the mime types.. I can re-diff it to LFS standards and commit it to Patches. I can't add it to the BOOK(s) though. fwiw -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
ALSA-Plugins-1.0.9
They have pulled the jack plugin from alsa-lib, creating a new package, alsa-plugins. They added an OSS plugin, so that native ALSA will run on OSS. However, you cannot disable jack. Therefore, you cannot build the OSS plugin without installing jack. I will proceed anyway. Anyone else tried this? Feedback? -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
automake-1.9x
I have /usr/bin/automake and /usr/bin/automake-1.9 and /usr/bin/aclocal and /usr/bin/aclocal-1.9. Maybe some symlinks would make sense here? I also have /usr/share/aclocal and /usr/share/aclocal-1.9. LFS programs installed before automake install m4's in /usr/share/aclocal. Later LFS packages install in /usr/share/aclocal-1.9. BLFS packages seem to prefer /usr/share/aclocal. There seems no method to the madness. I do not know what I'm doing, but maybe when creating directories, usr/share/automake-1.9 and aclocal-1.9 could be created, then symlinks usr/share/automake and aclocal. Version maintenance definitely required. Whatever, it's messy as is. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
sed-4.1.4
A very minor nitpick. Recent versions of sed install sed.html in /usr/share/doc. I'd rather see it in a sub-dir. Attached is a svn diff. fwiw -- David Jensen Index: chapter06/sed.xml === --- chapter06/sed.xml (revision 6491) +++ chapter06/sed.xml (working copy) @@ -30,6 +30,12 @@ Installation of Sed +Install the HTML docs in a sub-directory of +/usr/share/doc, instead of +the base: + +sed -i 's:/doc:&/sed-&sed-version;:g' doc/Makefile.in + Prepare Sed for compilation: ./configure --prefix=/usr --bindir=/bin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Small error in the emacs section (BLFS Chapter6, sect 2)
David Jensen wrote: Kim McCall wrote: In BLFS, Chap6, sec2, " Emacs-21.4a," which I access as http://www.linuxfromscratch.org/blfs/view/svn/postlfs/emacs.html under "Short Descriptions" you list "b2m" twice, with different descriptions. I'm reasonably certain that the second one wants to be "ctags" instead. Fixed. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Small error in the emacs section (BLFS Chapter6, sect 2)
Kim McCall wrote: In BLFS, Chap6, sec2, " Emacs-21.4a," which I access as http://www.linuxfromscratch.org/blfs/view/svn/postlfs/emacs.html under "Short Descriptions" you list "b2m" twice, with different descriptions. I'm reasonably certain that the second one wants to be "ctags" instead. Thanks for all your incredible work, Kim Wrong list, But I will CC blfs-dev, and fix it. Thanks for the report. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: pkg-config-0.18.1
Randy McMurchy wrote: Can't we just keep the current version until a new release that doesn't contain the bastardized name is released? Is there any great compelling reason to update to a *broken* package? There was a small bug fix, a missing else. it could be added to 0.18 with: sed -i 's:pkg_failed=yes]):&\nelse:' pkg.m4 I will add that. And I will continue with but not commit the name change, just to be doing something. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
pkg-config-0.18.1
They changed the name of the package. They also changed the library directory name to /usr/lib/pkg-config. Most if not every package has a hard coded pkgconfig. From GTK2+ Makefile.am: pkgconfigdir = $(libdir)/pkgconfig I suppose it is best to add /usr/lib/pkgconfig, and X116 and opt/, until everyone is caught up. More likely, they will revert it. Any one have an opinion? I think I may change the bug to unassigned :-) -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: lfs breaks
[EMAIL PROTECTED] wrote: Hi Developers, I am working on an up to date Fedora core 3 sytem. I have been trying to build LFS-6.1.*etc and have repeated failures when I get to tcl8.4.9-src.tar.gz. Each time I try to build it fails on this error: ./../compat/strstr.c : In function `strstr': ./../compat/strstr.c : 67 `NULL' undeclared (first use in this function) Is this just my system or have other people experienced this. Odd that is building this standard C library function. try: export CFLAGS=-I/tools/include ./configure --prefix=/tools make unset CFLAGS or maybe just: unset CFLAGS maybe -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gawk-3.1.4 and glibc-2.3.5: broken combination?
Matthew Burgess wrote:
OK, could someone who has a few spare cycles and a machine to do so
please build an LFS-6.1-pre1 system by the book?
I have a build of 6.1 Version TESTING-20050616
I don't think there have been any changes other than text.
{ 7, "GPG_ERR_E2BIG" },
{ 114, "GPG_ERR_EALREADY" },
{ 52, "GPG_ERR_EBADE" },
{ 9, "GPG_ERR_EBADF" },
{ 77, "GPG_ERR_EBADFD" },
no error! with Andersen's "EOF" not EOF.
--
David Jensen
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: libstdc++
Tushar Teredesai wrote: Does anyone know why these libtool files are useful? I have been deleting all the .la files without any problems. I *guess* for libs in /usr/lib they are 'hood ornaments'. ymmv -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libstdc++
Matthew Burgess wrote: I'd be prone to just leave it alone for now, seeing as it hasn't caused us any real problems so far. Here is what I did on a new LFS-BOOK-SVN-20050625: 6.13.Binutils-2.16 after 'make tooldir=/usr install' sed -i "s:^\(dep.*=\).*:\1' -liberty':" /usr/lib/libbfd.la 6.14. GCC-3.4.4 after 'make install' sed -i "s:^\(dep.*=\).*:\1' -lm -lc -lgcc_s':" \ /usr/lib/libstdc++.la /usr/lib/libsupc++.la All .la's are now nice and clean and I find no problems, I'm happy. To me this seems a short-coming of the supplied ltmain.sh's. However I have not been successful hacking them. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libstdc++
Matthew Burgess wrote: David Jensen wrote: I noticed on linking a gtkmm app that the gcc source directory is listed as a library directory. e.g. (snip) -L/tools/build/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src -L/tools/build/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/tools/build/gcc-build/gcc This is http://bugs.linuxfromscratch.org/show_bug.cgi?id=884. I'd be prone to just leave it alone for now, seeing as it hasn't caused us any real problems so far. Regards, Matt. I removed the noise from both libstdc++.la and libsupc++.la then rebuilt Aiksaurus. It worked as I'd hoped. LibAiksurus.la now : dependency_libs=' /usr/lib/libstdc++.la' and the libtool linking did not have the noise I may build a new system with that change, though I'd like to wait for the 2.6.12 headers. fwiw -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
libstdc++
I noticed on linking a gtkmm app that the gcc source directory is listed as a library directory. e.g. (snip) -L/tools/build/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src -L/tools/build/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/tools/build/gcc-build/gcc (/snip) I build in /tools/build, yours will say /sources or whatever you used. Cat /usr/lib/libstdc++.la and libsup++ to see what you have. I expect this is pulled into the .la all c++ libraries, I have 28 more with the noise now. Just wondering if we should remove it when we install gcc. thoughts? -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Balsa stable/devel
Updating to use user/root instructions: Balsa-2.2.6 wont compile. I'm using gcc-3.4.4. address.c: In function `libbalsa_address_get_edit_widget': address.c:399: warning: nested extern declaration of `N_' address.c:399: error: initializer element is not constant address.c:399: error: (near initialization for `labels[0]') and so on. Balsa 2.3.3 is good, 2.3 branch is said to be *semi-development* should we use it. Do you want me to test it. :-) thoughts? -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SBU calculations
David Jensen wrote: I don't think it's a big thing, BLFS sbu ratios would then be *slightly* high. Few would notice. actually I think all the values could be grep'd, cut, adjusted with a ratio and sed'd, all in a for loop. Anyone up to the script? -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
Archaic wrote: Now for the sake of current BLFS svn, I see no need to change this in 6.1, but for future releases I propose the entire build instructions be used which would add: make -C ld clean make -C ld LIB_PATH=/tools/lib Now there is no reason to add this *except* that section 4.5 of the book (which explains SBU's) can explicitly state that all commands in grey text should be encapsulated in the time command if you want to measure the SBU value for that package. Then it leaves little to chance and helps keeps all the developers and readers on the same page. Again, I am proposing this for post-6.1. I don't think it's a big thing, BLFS sbu ratios would then be *slightly* high. Few would notice. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: flex-2.5.31
David Jensen wrote: Yes, but it is huge, see the size of the flex-2.5.31-debian_fixes-4.patch, it is all in there. 924K. It seems easier, perhaps 'more pure' to regenerate locally. Wait, there is more in the -4.patch than needed. So it's not that bad, skel.c and scan.c patch is only 152K, and parts of them are already included. Still large though. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: flex-2.5.31
Matthew Burgess wrote: David Jensen wrote: 1. The order of the files in flex-2.5.31-debian_fixes-2.patch may sometimes trigger regenerating scan.c, which causes the build to fail if flex is not already installed. -- Solution: Move the scan.c section of the patch to after the scan.l section. Build and install per the current instructions. OK, see http://www.linuxfromscratch.org/~matthew/flex-2.5.31-debian_fixes-3.patch for the updated patch. I realise Alexander posted another solution, but I'm worried folks get so accustomed to *not* having to use the '-Z' switch, they'll miss it out on this one, then get bitten by what is a pretty obscure error. Great, I'll look at it. 2. Now there is a flex installed but it does not incorporate the patched scan.l and flex.skl. -- Solution: touch scan.l flex.skl; ./configure --prefix=/usr; make; make install. the ./configure, again, is required to pick up the newly installed flex, else scan.c is destroyed and it bombs. OK, you've lost me here. If I understand correctly, we've just changed the patch from updating scan.l *after* scan.c to have it update scan.l *before* scan.c so that scan.c doesn't get rebuilt, thus requiring a host-installed flex to be present. Now you're saying that we need scan.c to be rebuilt anyway, so that it includes the patched contents of scan.l? Is there some way we can change the patch so that it changes scan.c only, but includes all the changes from scan.l too? Yes, but it is huge, see the size of the flex-2.5.31-debian_fixes-4.patch, it is all in there. 924K. It seems easier, perhaps 'more pure' to regenerate locally. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: flex-2.5.31
David Jensen wrote: I'll try to find the livecd scripts and see if the other problems are addressed. Nope: problems 2 and 3 are not addressed. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: flex-2.5.31
Alexander E. Patrakov wrote: David Jensen wrote: -- Solution: Move the scan.c section of the patch to after the scan.l section. Build and install per the current instructions. Goto 2. patch -Z -Np1 -i flex-2.5.31-debian_fixes-2.patch Note the "-Z" option which causes dates to be set from the patch. Thanks for that. Simpler, and I learned a switch. I'll try to find the livecd scripts and see if the other problems are addressed. -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
flex-2.5.31
I poked at this for a couple days, and there are problems with the current flex build instructions: 1. The order of the files in flex-2.5.31-debian_fixes-2.patch may sometimes trigger regenerating scan.c, which causes the build to fail if flex is not already installed. -- Solution: Move the scan.c section of the patch to after the scan.l section. Build and install per the current instructions. Goto 2. 2. Now there is a flex installed but it does not incorporate the patched scan.l and flex.skl. -- Solution: touch scan.l flex.skl; ./configure --prefix=/usr; make; make install. the ./configure, again, is required to pick up the newly installed flex, else scan.c is destroyed and it bombs. 3. The flex++ link has not been created since the switch to 2.5.31. I didn't miss it in nearly a year, but maybe it is supposed to be there. -- Solution: ln -s flex++ /usr/bin/flex I could file a bug. David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Flex compilation issue...
David Jensen wrote: touch -t 0303311951 scan.l make make install touch scan.l make make install Still blathering. Looks like we also need to touch flex.skl before the second make. Alternately the scan.l and flex.skl patch fragments could be moved to a second patch, then applied before the second make. That would get rid of the 3 added touches? fwiw -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Flex compilation issue...
Archaic wrote: On Tue, May 31, 2005 at 05:22:46PM -0500, Randy McMurchy wrote: If Flex is required to build itself, then it probably should be put back into the book in Chapter 5. I'm cc'ing the -dev list with this message, so the dev guys can determine if it really needs to be added back. I'm going to run a trunk build tonight with flex removed and see what happens. This is a known solid host so any error should denote a problem. Here is what I think is happening: after the patch if we: ls -la --time-style=full-iso scan.* --- -rw-r--r-- 1 dave users 136584 2005-06-01 18:44:55.0 scan.c -rw-r--r-- 1 dave users 21045 2005-06-01 18:44:55.0 scan.l --- the resolution of the timestamp is insufficient to trigger the scan.c rebuild if scan.l is written during the same rtc second as scan.c. Actually we want scan.c regenerated as we have patched scan.l. But it's luck of the draw if the timestamps differ, and we have no flex at that point anyway. I think we must: touch -t 0303311951 scan.l make make install touch scan.l make make install IMHO, sorry if I am posting some of this twice, just clarifying! -- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Flex compilation issue...
David Fix wrote: I don't copy anything... I work in the /working directory and simply do a "tar zxvf /sources/blah.tar.gz" or whatever... No other modifications, I just follow the book. :D Dave At this point I have more confidence in your install than mine! If I rebuild now, the flex bin is the virtually the same as my build. If I touch 'scan.l' before make, both scan.c and the flex bin are significantly larger. I'm going to change my script to: touch -t 0303311951 scan.l make make install touch scan.l make make install till someone says different. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Flex compilation issue...
Randy McMurchy wrote: Anyway, I use a "working" directory called "build" which is a subdir of an unprivileged users home directory to do *all* building. I'm not sure the working path really is an issue that can cause a package to build or not build successfully. If the untar'd dir were copied with 'cp' rather than 'cp -a', the timestamps would be all wrong. That would force the flex attempt. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
fsf ? binutils
I'm guessing current development has moved to fsf, but the download link is still to kernel.org which i think is hjl? It should be fixed? --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
