Re: Pending package updates
Matthew Burgess wrote: > Under these conditions, Russian man pages display correctly. There's a slight > issue with hyphen characters that are added automatically by line-breaking > rules in 'man', as can be seen in the en_GB.UTF-8 'preconv' image. This seems > to be because the 'sed' that is applied in the Groff instructions, > specifically > to handle this issue, no longer makes any changes to the source of > Groff-1.20.1 > due to a change in the conventions used in fonts/devutf8/R.proto. I've not > reported this upstream (bug-groff list) yet, but will do after I send this. Please don't. This is an issue with Linux console fonts supplied with the kbd package, not with groff. So this change is unacceptable upstream. > Also, that same hyphen character gets completely dropped in the > en_GB.ISO-8859-1 > locale due to a bug in Man-DB (reported upstream). OK, this is indeed a bug in man-db. > I'd like to think that I'll get a response back from the Man-DB maintainer > over the course of next week, at which point I'll decide how to proceed with > the rest of the package upgrades. OK, this seems to be the best plan. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Toolchain
2009/1/19 Greg Schafer : > Jeremy Huntwork wrote: >> Some weeks ago, Ryan proposed a somewhat alternative method >> that does not require any adjustment of the toolchain in chapter 5 > > I think this is a regression, actually, at least from an educational POV. Could you please explain why? (note: I neither agree not disagree, just want to see your thoughts about the educational component and compare with my own). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Greg Schafer wrote: > Sidenote: Now that some toolchain devs are apparently using *native* > sysroot builds, there is a temptation to pursue a whole new build method > that bypasses most of Ch 5. However, we would most certainly lose a lot of > the advantages of the current 2-phase approach, so gut instinct tells me > this won't be viable. Obviously, ICA verification would be *critical* to > such a build method. About good separation of the files between different stages that was previously achieved by using /tools: I think that using a package manager would solve this. The advantage about immediately gaining these temporary tools in $PATH is indeed lost. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jeremy Huntwork wrote: > Can we resolve any actual differences between the projects (and > individuals making up the projects) and put aside any perceived disputes > and work together in a more unified manner again? If so, what are we > willing to do to be more unified? What possibilities are there? IMHO, LFS should not blindly copy anything. Especially since the goals are different: CLFS can produce any architecture from any, DIY depends on the fact (or, in different words, essentially exploits the fact) that the host kernel can run target binaries. My point is that the goals are essentially different, and thus, for technical reasons, the techniques _should_ be different. [below I map all chapter names to LFS equivalents] Obviously, in the case where the host kernel can't run target binaries, cross-compiling the entire Chapter 5 (as done in CLFS) is indeed the only solution. However, by cross-compiling the entirety of Chapter 5, CLFS, paradoxically, becomes more dependent on the host binaries than DIY. To see what I mean, consider the following. In x86 -> x86 DIY, Chapter 5 Gawk becomes available as soon as it is built (this is a plus). In x86 -> x86 CLFS, Chapter 5 Gawk just sits there, and all subsequent packages use the host Gawk while building. To me, this looks like deliberately ignoring an advantage of host-target compatibility. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
Jeremy Huntwork wrote: > Check this out: http://wiki.debian.org/Grub/Grub2 Yes, they have good manual pages in Debian. Thanks for the link. Let's hope this documentation will be accepted upstream. It is still worth mentioning that Debian uses a SVN snapshot, not a release, because of various bugs. See (experimental) http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.96+20081201-1/changelog -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
2008/12/4 Alexander E. Patrakov <[EMAIL PROTECTED]>: > OTOH, since (B)LFS doesn't support LVM2 anyway, I don't consider the > failure of this test a showstopper. But the docs are still in too bad shape. E.g., the wiki page http://grub.enbug.org/CommandList doesn't really document the new commands, but refers to the documentation of GRUB Legacy even if it doesn't apply. Texinfo documentation does exist in upstream repository, but not in the tarball. Even more, the texinfo docs don't contain the word "lvm", i.e., are incomplete. I am afraid that it would be too irresponsible to throw a new undocumented package upon our readers. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving to Grub2?
2008/12/4 Jeremy Huntwork <[EMAIL PROTECTED]>: > Matthew Burgess wrote: >> That said, I've not tried it out myself yet. Maybe in my next build! > > Testing it out now... Please take time to create the following setup in a virtual machine: /dev/hda1 as the only partition LVM on /dev/hda1 GRUB2 in MBR Last time I tried this, it worked and then, on the next reboot, failed. See http://www.linuxfromscratch.org/pipermail/lfs-dev/2008-March/061078.html OTOH, since (B)LFS doesn't support LVM2 anyway, I don't consider the failure of this test a showstopper. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Bruce Dubbs wrote: > Even it it's poor hardware support, does the frequency of occurrence rise to > the > level of needing to be in the LFS book? As several comments in the ticket > suggest, initramfs would be more appropriate for BLFS, but I'm thinking that > even that is too much and an updated hint or wiki entry would be more > appropriate. BLFS would be OK if accompanied with a pointer on the kernel page in LFS. Hint or wiki entry is certainly not OK, because of the new LiveCD policy: packages beyond BLFS are not permitted. I.e., the new LiveCD will support LVM and RAID only if there is a corresponding page in LFS or BLFS. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libidn update
2008/12/2 DJ Lucas <[EMAIL PROTECTED]>: > Alexander E. Patrakov wrote: >> Testcase (I think it should even be put into the book): >> >> LANG=en_US xterm >> in that xterm: curl http://räksmörgås.josefsson.org/ >> > Thanks for the testcase Alexander. All of them have been invaluable to > my limited uni-lingual mind (is that even a word?). Might be nice if an > expectation was set. :-) I don't have curl installed yet so I haven't > tried it. > > I assume the expected outcome is something to the effect of 'Resolving > r\303\244ksm\303\266rg\303\245s.josefsson.org... failed: Name or service > not known.', as it does with an old wget if not working...otherwise > we'll be greeted with a raw copy of the index. The expected outcome is a portion of HTML. Obviously, this works only if you really have the en_US locale, i.e., the "locale" command in the xterm doesn't print any errors. And your locale setup is indeed incorrect, as "\303\244" appear, as if the paste resulted in UTF-8 bytes instead of ISO-8859-1, and as if bash treats these characters as unprintable (this happens only in the "C" locale). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.4 is released
Bruce Dubbs wrote: > The Linux From Scratch community is pleased to announce the release of LFS > Version 6.4. This release includes numerous changes to > LFS-6.3 (including update to Linux-2.6.27.4, GCC-4.3.2, Glibc-2.8) and > security > fixes. It also includes editorial work on the explanatory material throughout > the book, improving both the clarity and accuracy of the text. Big thanks to the Editors who made this possible. And congratulations to all with this new release! -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: development/chapter06/glibc
rae l wrote: > At the same time, I sugguest to add zh_CN.UTF-8 support, too, > > localedef -i zh_CN -f UTF-8 zh_CN.UTF-8 The list in the book refers only to locales that are used by the automated testsuites (i.e., not necessarily intended to be used by humans). The testsuite for coreutils explicitly uses zh_CN.GB18030, not zh_CN.UTF-8. Besides, zh_CN.UTF-8 is already covered by the sentence "In addition, install the locale for your own country, language and character set." -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: perl-5.10.0
2008/10/29 Bryan Kadzban <[EMAIL PROTECTED]>: > Useless warnings: who cares. Authors of CGI scripts, because users see the warnings, at least under thttpd. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils pass2, --disable-nls
Robert Connolly wrote: > Is there a reason Binutils pass2 has --disable-nls? Yes, the same as before: if someone wishes to use HJL binutils, this avoids the "gettext" host requirement. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
I wrote: > Bruce Dubbs wrote: >> Alexander E. Patrakov wrote: >> >>> So, please choose another word below. >>> >>>> When man encounters an unexpected encoding, it will display the >>>> contents as configured, resulting in completely illegible text. >> >> How about 'unreadable'. > > Yes, it is better. But it can be misinterpreted, see > http://linuxfromscratch.org/pipermail/lfs-dev/2008-October/062091.html Oops. The context here does exclude this misinterpretation. So let's go with "unreadable", as in "Man will _display_ ... unreadable sequence of characters", but not as in "unreadable manual page. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
Bruce Dubbs wrote: > Alexander E. Patrakov wrote: > >> So, please choose another word below. >> >>> When man encounters an unexpected encoding, it will display the contents >>> as configured, resulting in completely illegible text. > > How about 'unreadable'. Yes, it is better. But it can be misinterpreted, see http://linuxfromscratch.org/pipermail/lfs-dev/2008-October/062091.html If nothing better is suggested, we'll go with "unreadable". -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
DJ Lucas wrote: > Many other distributions ignore the on disk encodings completely, > leaving the end user with a mix of improperly encoded manual pages. Well, the end user doesn't care how the manual pages are encoded on disk. The only thing that matters is if they are displayed correctly. And I can't translate the sentence into Russian, because I don't know how an encoding can be ignored by the distribution. Issues can be ignored, and encodings can be mishandled. And you lost the important bit from your previous mail, that in such distributions some pages (that match the de-facto Man setup) are readable, while others display as completely "illegible" lines of craracters. And BTW, Lingvo (the leading online English<->Russian dictionary) doesn't even list your intended meaning among the list of available translations for "illegible". They think that this word can apply only to handwriting or typesetting, and is a synonym for "blurry", or "too small to read". I.e., it means something which can be characterized with a certain degree of "illegibility", while we are talking about perfectly displayed, but wrong characters (and one cannot talk about "more correct" or "less correct" characters). So, please choose another word below. > When man encounters an unexpected encoding, it will display the contents > as configured, resulting in completely illegible text. Man (original) doesn't _know_ the encoding. It just passes the manual page through a pipeline designed (deliberately or by copying others' setup blindly) to process text in a certain encoding. Garbage in, garbage out. Yes, that's essentially what you said, but not all Man implementations have enough brains to "expect" some encoding - the original Man just pipes text through the static user-configured pipeline. Sorry, it is too late here for me to try suggesting a better wording. I will do this tomorrow if you don't do it yourself while I sleep. >>> Man-DB uses a >>> built-in table (see below) to find the correct serach directory for >>> manual pages based on the user's locale settings. >>> >> No, it doesn't look into the table in this case. See add_nls_manpath() >> in http://www.chiark.greenend.org.uk/~cjwatson/bzr/man-db/trunk/src/manp.c >> >> It iterates over all subdirectories and tests whether the subdirectory >> is for the user's language, completely disregarding the encoding. >> > ...ships with manual pages in legacy encodings. Man-DB uses a built-in > table (see below) to determine the on disk encoding of the manual pages > found for a user's locale. If the directories found do not contain the > ".UTF-8" extension, Man-DB checks the table, and performs the necessary > conversion. E.g., because of "UTF-8" in the directory name... It doesn't work this way. Suppose that the user's locale is ll_CC.CODESET. Man looks for subdirectories of /usr/share/man that, after removing a possible suffix, reduce to either ll_CC or ll. For each of the directories found with a suffix, it uses the suffix as the encoding. If the directory has no suffix, Man-DB checks the table. "UTF-8" has no special meaning, but your text creates a false impression that it does. E.g., if /usr/share/man/ru.CP1251 existed, Man-DB would expect to find CP1251-encoded manual pages there. Again, please read the source. Oh, you did. > Some interesting reading in the source. Looks like at least > unpack_locale_bits() does not care what the codeset is, but it's checked > in encodings.c. So: > > ...If the directories found do not contain an extension, Man-DB checks > the table, and performs the necessary conversion. E.g., because of > "UTF-8" extension in the directory name... It always performs the necessary conversion (e.g., in ru_RU.KOI8-R locale, it can use manual pages from /usr/share/man/ru.UTF-8), so let's drop or move "and performs the necessary conversion". Also, in UTF-8 locales, it does _double_ conversion: first to the encoding from the table, then (after processing with Groff) back, because Groff doesn't understand UTF-8. Other than that, good. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
DJ Lucas wrote:
> DJ Lucas wrote:
>> Thank you again for the detailed critique, suggestions and examples.
>> You've been a great help. I'll have another go at it using your text above.
>>
>>
> OK, I think this is almost the final...
>
> http://www.linuxfromscratch.org/~dj/LFS-MANDB/chapter06/man-db.html
> Some packages provide non-English manual pages. They are displayed
> correctly only if their location and encoding matches the expectation
> of the "man" program. However, different Linux distributions have
> different policies (expressed in the choice of the man program, its
> configuration and patches applied to it) concerning the character
> encoding in which manual pages are stored in the filesystem.
>
> E.g., Debian previously required Russian manual pages to be encoded
> in KOI8-R and to be placed in /usr/share/man/ru. Now, in addition,
> their man program (Man-DB) searches for UTF-8 encoded Russian manual
> pages in /usr/share/man/ru.UTF-8. On the other hand, Fedora uses
> UTF-8 encoded manual pages exclusively. Russian manual pages are
> found in /usr/share/man/ru and their man program doesn't acknowledge
> /usr/share/man/ru.UTF-8. Many other distributions ignore the problem
> completely, leaving the end user with a mix of readable and
> unreadable manual pages, and even worse yet, unreadable error
> messages when a suitable manual page is not found.
"ignore the problem" => which problem? The text suggests that many
distributions ignore that fact that different distributions have
different policies. Some other word is needed. Maybe: "Many other
distributions ignore the need for a consistent policy, leaving the user
with ..."?
"a mix of readable and unreadable manual pages" - yes, very well
spotted, better than I formulated on this list! However, there is a very
low-priority wish: some people will misinterpret the word "unreadable"
as "no way to make the man program access this file" instead of "man
reads this file and displays garbage". Here a picture would be worth
thousand words, but pictures are not in the current LFS tradition.
"and, even worse yet, unreadable error messages" => no, unreadable pages
are worse. And this situation follows from a bug in the "man" program
(it uses the obsolete catgets interface instead of gettext), not from
misplaced or misencoded manual pages, so let's not mention it.
> Disagreement about the expected encoding of manual pages amongst
> distribution vendors, has led to confusion for upstream package
> maintainers. One package may contain UTF-8 manual pages, while
> another ships with manual pages in legacy encodings. Man-DB uses a
> built-in table (see below) to find the correct serach directory for
> manual pages based on the user's locale settings.
No, it doesn't look into the table in this case. See add_nls_manpath()
in http://www.chiark.greenend.org.uk/~cjwatson/bzr/man-db/trunk/src/manp.c
It iterates over all subdirectories and tests whether the subdirectory
is for the user's language, completely disregarding the encoding. IOW,
all of /usr/share/man/ru{,.KOI8-R,.CP1251,.UTF-8} are searched in all of
ru_RU.KOI8-R, ru_RU.CP1251 (unofficial, has to be localadef'ed manually)
and ru_RU.UTF-8 locales.
The rest is OK.
> ...I have a couple of questions:
> Was this an LFS
> only problem in that we didn't pass '+lang none' to Man's build?
It is a problem for all distributions that don't pass '+lang none'. No
distribution known to me passes '+lang none'. Fedora converts error
messages so that they look right in UTF-8 locales, but this makes them
incorrect in legacy locales.
> Also, I think the one line paragraph above the table can be removed
> completely since the table is explained in the paragraph above that, but
> I'm not sure.
Yes, remove it.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Please review for Man-DB changes
oving the note about the mess present in most distributions, but I don't see where to reinsert it. > There may be times, however, where one > encoding is preferred over the other. Without examples, this is a meaningless phrase. And I think it is not the encoding that is preferred, but we prefer one or the other way to modify the upstream installation process. To see what I mean, try converting MPlayer manual pages to UTF-8 after unpacking the tarball, and pretending that this is what upstream provided. You can either convert back, or move the installed manual pages (not very clean, but we do it for some binaries anyway), or patch the Makefiles. After seeing the steps needed to complete each of the ways, you will perhaps be able to come up with a better phrase. > Following LFS's previous policy, if upstream distributes the manual Not sure if the reference to our previous setup (not policy, as we couldn't change it!) is a good thing. The rest is OK. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
DJ Lucas wrote: > OK. But I am still under the impression that is the expected future. > That doesn't change the fact that it is totally incorrect as written and > needs to corrected to show the proper state. Well, Debian certainly won't switch to UTF-8 manual pages until they release Lenny. And, judging by their graph of release-critical bugs, this will happen in 9-10 months or so. What they are doing right now is preparing the infrastructure: a viewer that understands UTF-8 encoded manual pages, a perl patch so that pod2man can produce them, in the future they plan to write dpkg helper scripts that actually convert manual pages at package creation time. Only after that, the switch becomes possible. However, if I were Debian, I would delay the switch even further. Right now, ISO-8859-1 manual pages can be converted to PostScript directly with Groff. By converting manual pages to UTF-8, you lose the ability to print them. Isn't printing a really important feature? ;) >>> Upstream packagers will very likely drop legacy encodings in favor of >>> UTF-8, though adoption has been slow due to the hacks required to >>> make the current Man and Groff packages work correctly together. >>> >> I don't know how to comment on this. Modern desktop packages come with >> DocBook documentation, not manual pages. >> > :-) The point of both of the above points is to make known that we will > be seeing more UTF-8 encoded manual pages...especially with both Debian > and RedHat going that route. It still needs rewording, or removal. I vote for removal, especially because MPlayer (a package under rapid development) still ships with non-UTF-8 manual pages. And while UTF-8 manual pages may be the future, the timeframe is not defined. > OK. I thought about doing that too, but French man pages include shell > scripts to do the conversion before installation so it's not a good > place to show off convert-mans. Why not? Mention that the equivalent scripts exist in the package, but that for the sake of demonstration, out "convert-mans" script is used. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please review for Man-DB changes
hus broken. The leading and government-sponsored Russian distribution (Alt Linux) still uses 8-bit (KOI8-R) manual pages. The only distributions that converted fully are RedHat derivatives. Debian only starts to get ready. > Upstream packagers will very likely drop legacy encodings in favor of > UTF-8, though adoption has been slow due to the hacks required to > make the current Man and Groff packages work correctly together. I don't know how to comment on this. Modern desktop packages come with DocBook documentation, not manual pages. > The relationship between language codes and the expected encoding of > legacy manual pages is listed below. > > Table 6.1. Up to this point, nothing is said (except in the text I proposed at the very top of my post) HOW Man-DB determines the encoding of a manual page. Theory should be given before examples, not in examples. This worked before, because the whole theory was expressed in the table. > If upstream distributes the manual pages in a legacy encoding the > manual pages can simply be copied to /usr/share/man/. > For example, German manual pages can be installed with the following > commands: > > mkdir -p /usr/share/man/de cp -rv man? /usr/share/man/de OK > If upstream distributes manual pages in UTF-8 (i.e., “for RedHat”) > instead of the encoding listed in the table above, they can either be > converted from UTF-8 to the encoding listed in the table above, or > they can be installed directly into /usr/share/man/ code>.UTF-8. OK. Here the script would go. Also I'd like to see comparison of both approaches. E.g., if the manual pages are installed with a Makefile, it is often easier to convert manual pages before installation than to patch the Makefile. > For example, to install Spanish manual pages Let's drop this buggy package and explain both techniques with French manual pages. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Minimum Host Prerequisites
Jeremy Huntwork wrote: > Perhaps I'm not understanding your point. Certainly > --enable-kernel=current would cover that very circumstance? --enable-kernel=current breaks downgrades that are inevitable after any RedHat release, and introduces a new variable into the build. That's why I am against it. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Current state of i18n
Bryan Kadzban пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > DJ Lucas wrote: >> ## Test 4 >> [EMAIL PROTECTED] TESTS]$ export LANG=ru_RU.UTF-8 >> [EMAIL PROTECTED] TESTS]$ vimtutor >> === >> =Д о б р о п о ж а л о в а т ь в у ч е б н и к VIM - >> Версия 1.5 = >> === >> >> [EMAIL PROTECTED] TESTS]$ >> ## This in incorrect according to Alexander, however it does look plausable >> ## Can anyone comment? > > Well, the way I read Alexander's archived post at > http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055426.html, > "Russian characters" (i.e. what you got) is expected, while the "English > tutorial" is an acceptable fallback, and is what the book did at that > time. It *looks* like vimtutor -- or at least the way LFS installs it > now -- has simply gotten better. If that's correct: Yay! ;-) Yes, that's correct, and that's old news. Exactly because Vim has this bug fixed, we no longer remove the translated tutorials in LFS-6.3. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Future
Jeremy Huntwork wrote:
> Hello,
>
> I know that we've talked about this before but given the events of the
> past year or so, I'd like to revisit this briefly.
>
> Alexander and I have been talking and we're trying to take a very
> realistic approach to any efforts made to re-enliven the LiveCD project.
>
> Without going into too many details of our own concerns and ideas about
> the future of the project (yet), I'd appreciate some feedback/opinions
> concerning the usefulness of the LiveCD.
>
> This thread is not designed to spark feature requests. Whatever
> direction we pursue, the LiveCD (or at least the main one) will aim to
> be fairly simple. The purpose of this thread is to see at what level are
> LiveCDs beneficial or useful to the community, especially the {,B}LFS
> editors so that we can modify the core goals and aims of the project for
> future efforts.
Let me explain the reasoning behind the original feature creep. The
problem is that there are many communities with different needs (and not
all of them read {b,}lfs-dev), and that they WILL spark feature requests.
English-speaking editors can do well with a console-only CD. They can
read the book, run jhalfs, and use or download packages, because a
static IP behind the router or DHCP is a common setup in
English-speaking countries.
OTOH, in Russia, many people prefer reading Russian documentation, e.g.,
from opennet.ru. Thus, they need some means to enter and read their
characters - i.e., kbd and a script to choose the keymap, screen font
and locale at boot time. Many Russian ISPs require authenticated
connections like PPPoE or, even worse, PPTP. In rural areas, GPRS is the
only way to get connected, so it should be easy to set up. Note that,
without a network connection, the CD is useless for those wanting to try
an updated version of the book.
In China and Japan, I guess, the same preference for reading
documentation in the native language applies. But one needs X, fonts
and input methods in order to perform this task. Vesa-only setup is not
good for people with CRT monitors (and there are still such people),
because 60 Hz refresh on CRT can cause permanent damage to the eyes (and
if I ship such setup in Russia, I will be fined by the Ministry of
Healthcare). Thus, there is a need for video driver autodetection. The
one built into Xorg is not reliable enough on ATI cards, thus I had to
write my own script.
Then there appeared blind people who need brltty and/or speakup, that
required a kernel patch from GIT or changing the kernel version, and
this software came with its own bugs to patch out.
The bottom line is that you either have to answer "yes" to all doable
feature requests, or set a different policy and send some people
somewhere else (e.g., to Knoppix). But the second alternative
immediately brings up the question "why do we need LFS LiveCD when
Knoppix exists and can be made to work as a host?", and I think that
defining this balance (and thus establishing the criteria of the future
LFS LiveCD usefulness) is the real question to discuss.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Ticket 2156 - LFS LiveCD is dead
Bruce Dubbs wrote: > http://wiki.linuxfromscratch.org/lfs/ticket/2156 > > I have changed my copy of the book to read. > > As an alternative to installing a separate distribution onto your machine, > you > may wish to use the Linux From Scratch LiveCD. The CD works well as a host > system, providing all the tools you need to successfully follow the > instructions > in this book. Unfortunately, development of the LiveCD has not progressed > recently and it only contains older versions of the source packages, patches, > and this book. For more information about the LFS LiveCD or to download a > copy, > visit http://www.linuxfromscratch.org/livecd/. > > Note > > The LFS LiveCD might not work on newer hardware configurations, failing to > boot > or failing to detect some devices, like SATA hard drives. > - > > The web page that is the link target will also need to be updated. > > Should I commit this? Probably yes, but after some fixes. 1) "It only contains older versions of the source packages, patches, and this book" - overly optimistic. The -nosrc and -min versions don't contain any sources or patches (but they do contain the old book). 2) The text gives the LFS LiveCD unustified preference WRT other LiveCDs. Basically, I want the book to say "if you don't to install a distribution, use a LiveCD that qualifies as a host distribution. Here are some examples: ..., ..., old LFS LiveCD", not "if you don't want to install a distribution, try LFS LiveCD". -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2156 - LFS LiveCD is dead
DJ Lucas wrote: > No. IIUC, it doesn't contain m4 and cannot build current trunk until m4 > is moved up in chapter 5, however, as soon as that happens, the text > above should work nicely. False. It uses autoreconf on some packages, and this can't work without m4. And indeed, it does contain /usr/bin/m4. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Util-linux-ng nitpicks
Matthew Burgess wrote: > On Tue, 07 Oct 2008 14:52:24 -0500, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > >> partprobe is very useful. If you create a new partition, you can use >> partprobe to make the current system recognize it without rebooting. > > But partprobe comes from parted, not util-linux :) > >> One determining factor is if those programs are required by the LSB or >> not. I >> don't have time to check today. I'd have to install the test suite and >> run it. > > I've done a search of the LSB-Core-Generic-3.2 and LSB-Core-IA32-3.2 PDFs and > didn't find any mention of 'addpart', 'delpart' or 'partx'. > > Looking at the man pages for each, I'm having a hard time > understanding the use-cases for each of these programs. Why would > one need to tell Linux about partitions if no changes have been made? One can dd the whole disk image (including the partition table) from some NFS server where such images are stored, and then one should tell the kernel about the new partition table. Although blockdev --rereadpt works just fine for this particular task. > Likewise, if one is making changes to partition tables, why would the > program that is making those changes not inform Linux about those > changes? dd, see example above, It just doesn't know that it modifies the partition table :) -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Groff
DJ Lucas wrote: > Ken Moffat wrote: >> On Tue, Oct 07, 2008 at 05:59:14PM -0500, Randy McMurchy wrote: >> >>> Hi all, >>> >>> I'm way on the downhill side of getting all the package >>> updates in. Groff is sort of a bugaboo, however. The >>> DJ book uses the Groff-UTF8 package, but I'm not sure it >>> does much. >>> >>> Please give some input if you have any on this subject. >>> It would be an addition to LFS Chapter 6. Do we need it? >>> >>> Note that the plans right now are to still include the >>> man-db package and not the man package which DJ used in >>> his version. >>> >>> Any and all input in this internationalization stuff would >>> be appreciated, as I'm a totally English speaking Editor >>> without much knowledge about i18n. >>> >> I was the one who mentioned groff-utf8: from what Colin said, >> *current* man-db looks a better way to go (i.e. it converts non-UTF8 >> pages, so we don't have to recode them). The issue seems to be "can >> we use recent groff with man-db ?" and for that I have no idea, I >> haven't even got close to looking at how it's all set up in current >> debian and ubuntu. >> > No..only groff CVS. No, not even groff CVS, because it expects different command line options than those hard-coded in Man-DB. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils-i18n patch
DJ Lucas wrote: > Excellent! Thank you Alexander! That will be a great help. You said > that some of these come from the LSB docs at that time. I'll check > tomorrow and see if I can find any more there. Do you have any more > test cases stashed away in your bookmarks that can be of use? I am > especially interested in the coreutils tests that had previously > failed. Looks like they were still broken in 6.9. There are no bookmarks, I googled for the subject combined with my surname. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils-i18n patch
Randy McMurchy wrote: > Hi all, > > Noted in DJ's book (I'll continue to refer to it as that > even though his book is what will be SVN, he's the one > that got all this stuff going) that we've dropped the > i18n patch for Coreutils. IIRC, upstream won't touch it, > and I think I remember there may have been a discussion > about it here, but I want to revisit it to ensure that > we're all good dropping it and/or keeping it. > > Alexander may have some good info here, as others may > also, but I want to ensure the community is agreed as to > the direction we take. Please look at http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055425.html - basically, if you are going to remove the patch, rerun the tests and, if they fail, forget about LSB certification. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc locale instructions
DJ Lucas wrote: > Actually, the individual locales are not needed any longer. However, some locales improve the coverage of the testsuites, and I think it is instructive to show how to create individual locales with localedef. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
Lefteris Dimitroulakis wrote: > With all due respect to lfs-dev's, to you and to the holly book, > it will be very bizarre if lfsbook uses the Man package > and at the same time is claiming > that the included in the package man-pages > are NOT readable for whatever reason. Let's clarify the situation a bit. There are three possible outcomes for "man foo" in the ru_RU.UTF-8 locale: 1) Glibberish (unacceptable, but, unfortunately, what happens if the system is misconfigured by an English-speaking editor who doesn't know how to test the configuration) 2) "No such manual page" (well, OK if it indeed doesn't exist) 3) English manpage (acceptable, although not ideal) 4) Russian manpage. Reaching (4) means non-default configuration of Man that has to be explained. Explanation means understanding by editors. Are you sure that English-speaking editors have motivation to understand all the details and can immediately see their errors? Do you know that, in the past, some English-speaking readers refused to follow the new book after "magic" (from their viewpoint, i.e., "not understandable") changes in man setup happened and "magic" patches were added to coreutils, grep and diffutils, and that we lost some editors due to the same reason? Such "magic" patches undermine the educational nature of the book. You see - there is a fundamental conflict between "100% correct" and "educational", so a proposal is being made to adopt a suboptimal, but easily understandable setup. (no offense meant to English-speaking editors and readers in this paragraph) So: do you mean "it will be very bizarre if lfsbook uses the Man package and at the same time produces glibberish" (which I agree with) or "it will be very bizarre if lfsbook uses the Man package and at the same time patches it to never display translated manual pages, even though they are installed"? > And yes, I use the default /etc/man.conf. > and my personal files for configuration needed in order > to read man-pages in the encoding of my preference, > legacy or utf8. Very interesting, however, on my system, no packages installed Greek manual pages. Where you got them from, except the "man" package (that doesn't install them if one passes "+lang none")? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
DJ Lucas wrote: > Alexander E. Patrakov wrote: > > DJ Lucas wrote: > >> Roll back to file-4.21. The newer versions of file do not display the > >> character set if type is text/troff > > > > Testcase please. IMHO they are right, as it is impossible to reliably > > decide between, say, ISO-8859-1 and KOI8-R based only on manpage contents > > (without using a dictionary containing the translation of, say, "NAME" > > for all languages). I.e., the old version was likely to give wrong > > answers anyway, that's why this feature was removed. Could you please > > test both old and new "file" on manual pages installed by Man-1.6f? > > Shouldn't be necessary, but if you'd like to see the output, I can post > it tomorrow. Indeed, http://www.linuxfromscratch.org/~dj/not-utf8.txt contains the needed info. > The -e switch is still broken and since the older versions are not > readily available... Have to look and see if I can find 22,23, or 24 > with working -e, and without the broken guessing. The changelog does > not mention releases. Don't even try. It simply (or, if you want, "logically" or "mathematically") can't be unbroken without adding a dictionary, so don't wait for the fix. That's why I always mention the consistency requirement (i.e., that the encoding of all manual pages in a given directory should be the same) and the resulting need to convert or move manual pages according to the chosen convention (that is different in all distros, but has to exist in LFS, too). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
I wrote:
> And in fact I would strongly prefer a 8-line patch to Man to ignore
> non-English manual pages completely (instead of unconfigured groff-utf8 and
> hard-coded special-casing Japanese in Man-1.6f in a way that works only
> with Debian-patched Groff), as it saves the editors from all the encoding
> validation work. This is rather trivial
Attached. One of the reasons for this destructive approach is that Greg
Schafer doesn't accept anything into DIY that he doesn't fully understand,
and I want manual pages and error messages to be readable in DIY by default,
too. Obviously, complete removal of support for translated manual pages by
this patch makes groff-utf8 unneeded. "+lang none" is still needed.
--
Alexander E. Patrakov
diff -ur man-1.6f.orig/configure man-1.6f/configure
--- man-1.6f.orig/configure 2007-08-21 10:15:21.0 +0600
+++ man-1.6f/configure 2008-09-13 15:22:52.0 +0600
@@ -26,7 +26,7 @@
# (Indeed, -r may cause the terminal to get into funny states.
# Very inconvenient. For viewing pages in strange locales, set LC_*.)
#
-DEFAULTLESSOPT="-is"
+DEFAULTLESSOPT="-isR"
#
# Note that not creating any cat directories (/var/cache/man or so)
# and not making man suid or sgid is recommended.
@@ -476,24 +476,24 @@
then
if test $Fnroff = "missing"
then
- nroff="nroff -Tlatin1 -mandoc"
+ nroff="nroff -mandoc"
else
- nroff="$Fnroff -Tlatin1 -mandoc"
+ nroff="$Fnroff -mandoc"
fi
troff="troff -mandoc"
echo "Warning: could not find groff"
else
if test $Fnroff = "missing"
then
- nroff="$Fgroff -Tlatin1 -mandoc"
+ nroff="$Fgroff -mandoc"
else
- nroff="$Fnroff -Tlatin1 -mandoc"
+ nroff="$Fnroff -mandoc"
fi
troff="$Fgroff -Tps -mandoc"
jnroff="$Fgroff -Tnippon -mandocj"
fi
eqn="$Fgeqn -Tps"
- neqn="$Fgeqn -Tlatin1"
+ neqn="$Fgeqn"
jneqn="$Fgeqn -Tnippon"
tbl="$Fgtbl"
col="$Fcol"
diff -ur man-1.6f.orig/src/manpath.c man-1.6f/src/manpath.c
--- man-1.6f.orig/src/manpath.c 2006-08-04 03:18:33.0 +0600
+++ man-1.6f/src/manpath.c 2008-09-13 15:16:29.0 +0600
@@ -279,17 +279,6 @@
if (alt_system) {
add_to_list(dir, alt_system_name, perrs);
} else {
- /* We cannot use "lang = setlocale(LC_MESSAGES, NULL)" or so:
- the return value of setlocale is an opaque string. */
- /* POSIX prescribes the order: LC_ALL, LC_MESSAGES, LANG */
- if((lang = getenv("LC_ALL")) != NULL)
- split2(dir, lang, add_to_mandirlist_x, perrs);
- if((lang = getenv("LC_MESSAGES")) != NULL)
- split2(dir, lang, add_to_mandirlist_x, perrs);
- if((lang = getenv("LANG")) != NULL)
- split2(dir, lang, add_to_mandirlist_x, perrs);
- if((lang = getenv("LANGUAGE")) != NULL)
- split2(dir, lang, add_to_mandirlist_x, perrs);
add_to_mandirlist_x(dir, 0, perrs);
}
}
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: New personal experimental book
Lefteris Dimitroulakis wrote: > > Since you install Man, you get relevant man pages translated in greek. > > So you may add in your Table 6.1 "Greek (el) ISO-8859-7". > > Additionally: > Bulgarian (bg) cp1251 > Romanian (ro) ISO-8859-2 > Slovenian (sl) ISO-8859-2 NAK. The table in the text is really a copy of a table in Man-DB source, because the expectations of Man-DB can't be changed. With Man, the encoding expectations depend on NROFF and JNROFF lines. So, you can't really suggest this without knowing how DJ Lucas is going to configure Man. Your suggestion is obviously valid if one uses the default NROFF line (and thus avoids groff-utf8) and a non-UTF-8 locale. However, this is obviously different from the expected future direction. DJ: I will reject everything related to Man(-DB) reconfiguration if it doesn't discuss (by means of text, not only commands) the following items: 1) The list of subdirectories of /usr/share/man where a manual page for a given language is looked up Currently, /usr/share/man/ll* (i.e., both /usr/share/man/ru, /usr/share/man/ru.KOI8-R and /usr/share/man/ru.UTF-8 are searched in both ru_RU.KOI8-R, ru_RU.CP1251 and ru_RU.UTF-8 locales), and /usr/share/man if nothing is found. 2) for both UTF-8 and non-UTF-8 locales, the encoding at the input and at the output of every program that is involved in formatting and displaying the manual page; Yes, I understand that it is more than currently in the book, but only the encoding on disk matters now because the processing pipeline is hard-coded in Man-DB. Anyway, in the non-CJK case: the on-disk encoding of manual pages is inferred from their location (e.g., "/usr/share/man/ru => "KOI8-R" according to the table, "/usr/share/man/ru.UTF-8" => "UTF-8" because it is in the directory name). Then, if this is not a no-op, Man-DB runs iconv to convert to the language-specific 8-bit encoding listed in the table. Then it runs one of "groff -Tutf8" (if input is in ISO-8859-1 and the output should be in UTF-8), "groff -Tlatin1" (if both input and output are in ISO-8859-1), "groff -Tascii8" followed by iconv from the 8-bit charset to the user's locale (in all other cases). In the CJK case: the on-disk encoding of manual pages is inferred from their location. Then, if this is not a no-op, Man-DB runs iconv to convert to the locale encoding, and passes the result of conversion through "groff -Tnippon". 3) instructions to reconfigure your system from UTF-8 to non-UTF-8 locale (or the other way round) without reinstalling all packages that provide translated manual pages. Currently, no actions related to manual pages are needed. Only edit /etc/sysconfig/console and /etc/profile, and convert stuff in your home directory. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
DJ Lucas wrote: > Roll back to file-4.21. The newer versions of file do not display the > character set if type is text/troff Testcase please. IMHO they are right, as it is impossible to reliably decide between, say, ISO-8859-1 and KOI8-R based only on manpage contents (without using a dictionary containing the translation of, say, "NAME" for all languages). I.e., the old version was likely to give wrong answers anyway, that's why this feature was removed. Could you please test both old and new "file" on manual pages installed by Man-1.6f? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
DJ Lucas wrote: > All the recently mentioned changes and updates have been made except for > the testsuite fixes that Robert has been working on as I haven't had the > time to do manual builds. Of note: GCC-4.3.2, GlibC-2.8-20080905, LSB > bootscripts, initd-tools introduced, man instead of mandb and added > groff-utf8 package (thanks Ken). Man is probably still a little broken Yes, it is. Please read the man-i18n.txt hint and pass +lang none to man in order to get readable error messages. And, groff-1.19.2 doesn't have the --enable-multibyte configure switch. And in fact I would strongly prefer a 8-line patch to Man to ignore non-English manual pages completely (instead of unconfigured groff-utf8 and hard-coded special-casing Japanese in Man-1.6f in a way that works only with Debian-patched Groff), as it saves the editors from all the encoding validation work. This is rather trivial, as it involves only removing stuff from the add_to_mandirlist() function (because of the check in is_lang_page(), this also disables the Japanese special-case logic that doesn't make sense with any modern groff). Remember: an English message (i.e, error message or manpage) is infinitely better than an unreadable one. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
DJ Lucas wrote: > force UTF-8 locales? _please_ don't! I still don't use UTF-8 locales at work, because I do a lot of TeX work, and with certain styles, bibtex completely mangles Russian references in UTF-8 encoded files (takes the first _byte_ instead of the first _letter_ as the initial, thus producing invalid UTF-8, e.g., transforms Александр Евгеньевич Патраков to ?.~?.~Патраков [replaced invalid with question marks] instead of А.~Е.~Патраков). Since it is inconvenient to have the majority of documents in the encoding different from that of the locale, I stay with ru_RU.KOI8-R there. I think I am not alone with this bibtex problem. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ncurses patches
Randy McMurchy wrote: > Hi all, > > I noticed that the Ncurses author creates patches against > the 5.6 version. I can't remember if this has been > discussed before, and if it has then my apologies for > not remembering. This is how he publishes development versions. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
DJ Lucas wrote: > Ken Moffat wrote: > > Of the 'not so liked', I'd be happy to see the back of Man-DB (and > > therefore move Berkeley DB back to BLFS - if my memory is correct, it > > was a dependency of Man-DB). In my own builds, I still use groff-utf8 > > to render UTF-8 man-pages. [ nostalgic memory: before shadow was > > orphaned and then taken over by debian, it used to have a nice > > selection of UTF-8 pages. ] > > I really do not have a good understanding of that particular issue. > From what I did catch, and taking only info from the Debian bug, is > that we gain proper support for Japanese, and some broken support for > Chinese and Korean with ManDB. I really wish Alexander could chime in > here since he is the most knowledgeable WRT to this issue. For > reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196762 . I don't use anything except Debian now (i.e., have no LFS) and don't follow the upstream development (was too busy with my PhD, and now I am looking for a new job). So, I can't give any up-to-date advice. The last information that I posess is: 1) There must be consistency!!! And this requirement will never change. I.e., it shouldn't happen that some packages install UTF-8 manual pages and some install 8-bit manual pages. While consistency is not normally a problem, it is a huge problem for the huge BLFS book to change from one consistent scheme to another. For this reason alone, I don't recommend any changes. 2) Man-DB can be built with gdbm which is much more lightweight than BDB (and that is how it is built in Debian). 3) Man-1.6f still uses the obsolete catgets() system for message translation and thus outputs garbage instead of error messages in UTF-8 locales. So, if LFS goes to Man, it should completely disable translations of man error messages by passing "+lang none". 4) Groff CVS can read UTF-8 manual pages (at least for Ruissian, no idea about CJK) and produce UTF-8 output if started with "-Tutf8 -K UTF-8", but in traditional 8-bit locales one needs the output in the user's 8-bit charset, not UTF-8. > In skimming through the groff archives 200801-current, > http://lists.gnu.org/archive/html/groff/ , it doesn't look like anything > has happened in CVS for CJK support. ManDB with the debian groff patch > is the only solution for Japanese. Chinese and Korean are still in the > dark even with that. I guess my real question is what exactly do we > loose by dropping back to Man with current groff-1.19.2. I do realize > that what we have now works well in most cases. If you really want to stick with the current stable versions of Man and Groff and have the possibility to choose or not choose UTF-8 locales, then please implement the method from the "5. WHEN EVERYTHING WORKS BY DEFAULT" section, i.e., remove _all_ translated manual pages from all packages in LFS and BLFS and/or patch Man not to look for them at all. This is the only "right" thing to do now, because such support is based on either obsolete standards (ISO-8859-1) or, even worse, hacks. This will also serve better for the readers, as in many packages the translations of manual pages are horribly outdated. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
iproute2 vs net-tools on x86_64
Yes, I know that x86_64 is currently off-topic on this list. However, it exposed a problem. The problem is that iproute2 wraps its traffic counters at 4GB (i.e., uses 32-bit counters), while the old "ifconfig" command from net-tools doesn't. Unwrapped (64-bit) counters are, obviously, available from /proc/net/dev. So, is our "by default, use iproute2 only" choice justified enough? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PDF files in */downloads/ compressed - removed uncompressed versions
Gerard Beekmans wrote: > In an effort to save a large amount of bandwidth I've compressed the PDF > files that haven't been compressed yet and removed the uncompressed > files in the download sections. This'll conserve some bandwidth and > associated charges that go along with it. > > In the last few days alone the server has uploaded several gigabytes > worth of LFS and BLFS PDF files. Thanks for informing us that there is a demand for PDF versions. Is it possible to have some figures about the bandwidth consumed by HTML versions of LFS and BLFS books (preferably separate for stable & development versions), artwork, stuff in public_html, and PDFs, just to compare? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cp foo{,.bak} not always supported
2008/6/1, Gilles Espinasse <[EMAIL PROTECTED]>:
> cp configure{,.bak}
> cp: missing destination file operand after `configure{,.bak}'
> Try `cp --help' for more information.
This simply can't happen if the user follows the book to the letter.
Look at
http://www.linuxfromscratch.org/lfs/view/development/chapter04/addinguser.html:
useradd -s /bin/bash -g lfs -m -k /dev/null lfs
See "bash" here? On the next page, /bin/bash is also explicitly called
in ~/.bash_profile.
So: the bug report is invalid.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [LFS Trac] #2057: Udev-122
Gerard Beekmans wrote: > Rather than trying to fix udev, and it sounds like there isn't a > solution that isn't hackish and has a risk of not working any day now > with new releases. How about we fix our network setup. Yes, this is possible. However, this requires dropping udev and moving to a static /etc/sysconfig/modules file. And, optionally, switching to the FreeBSD kernel, which cannot create name collisions (because the driver name is a part of the interface name--e.g., an Intel card gets "em0", while a Realtek card gets "rl0"). BTW, one pleasant surprise for me recently (while testing solutions for #2057) was that I could install modern kernels on a Sarge virtual machine (that originally shipped with 2.6.8 or 2.4.?? kernel) that didn't have udev--and everything "just worked". With udev, I would have to worry about compatibility when upgrading kernels. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #2057: Udev-122
Gerard Beekmans wrote: > Aren't we back to square one after you enable more drivers. Then after > the first reboot of "kernel with additional drivers" you have to go > through the discovery again of which card has which name assigned. No, we aren't. 1) First boot, with only an Intel card recognized: it gets eth0, and an entry is written to the persistent rules database so that it remains at eth0 even when other cards are added to the system. 2) Second boot, with both Intel and Realtek cards. Due to the old entry in the database, the Intel card remains at eth0, while the Realtek card gets eth1. However, at USU, there were the following multi-card situations: 1) ums.usu.ru, before the old server died: two onboard Intel cards, both connected to different networks, and only one of them is public. 2) dsa.physics.usu.ru, before hardware upgrade: three Intel PCI cards, and only one of them is public. 3) dsa.physics.usu.ru, after the upgrade: one PCI Intel card facing the outside world, two D-Link gigabit PCI cards looking into the internal nets. 4) internal SAMBA server, after the upgrade: one old unused Intel card (combined with a video card, so can't remove), and a D-Link gigabit PCI card. So the scenario with blacklisting (or not building) some drivers would have worked only with 50% of cases. > Because the scenarios are so varied this would take up an entire chapter > in the book just to cover them all in a readable manner. Putting that > information in an appendix would help to maintain the flow of the book > without too many "if then else" scenarios. For those cases, put a note > in chapter 7's network config to skip ahead to Appendix X and read up on > what can be done and if a scenario matches the builder's. The scenarios are varied, but some "default" suitable for most cases has to be in the book. Some options for this default are: 1) always reboot before configuring the network (any number of cards), see the hint if building remotely; 2) the book assumes that you have only one network card and configures only eth0, see the hint if you need something beyond this simple case; 3) always write udev rules by hand--the idea is simple! 4) your own variant. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
GPL
> Group: Appbat/browsers
> Buildroot: %{pkgroot}/%{name}
> AutoReqProv: no
> PreReq: lsb >= 3.2
>
> %description
> LSB conforming version of lynx. Lynx is a text-based Web browser. Lynx
> is added to the LSB Application Battery primarly to demonstrate the use
> of the ncurses library.
>
> %pre
>
> %install
>
> %post
>
> %preun
>
> %postun
>
> %clean
>
> %files
>
> %attr ( - bin bin ) /opt/lsb/appbat
>> So: given that we still can't agree on the set of features to implement, I
>> propose LFS to never have any sort of PM, and those who disagree with this
>> "no
>> PM" policy should start a fork right now.
>
> We'll never agree. That's why we'll likely end up offering some options
> but we can't support all the options in-house. That's why we provide a
> set of known instructions - it the bootscripts are just a sample
> implementation for people who don't want/need to come up with their own
> boot scheme. Sometimes understanding the system is good enough. Same can
> be said about the PM system.
>
> Most users in the end won't really care which system is used. As long as
> there's something usable for them available to make life easier.
>
> We're not in decision phase yet. We're still in speccing out the various
> methods and getting some concrete ideas what it would mean if we were to
> pick one over the other.
As far as I understand, the outcome was (roughly) that LFS needs to provide at
least a no-PM and PM versions, with a well-known PM. And a requirement has been
formulated that the commands must match between these two versions (thus ruling
out %configure for RPM). Now Bruce wonders if we create a source RPM for each
package. The answer (obvious from a sample implementation that has been posted
already to this list, and from Dan's work) is that we don't create a source
RPM,
but a spec file indeed has to be created for each package. There is no way to
use RPM without spec files.
The second question (how to use a PM in LFS) is left unanswered, because of its
inexact formulation. I don't see any other way for RPM except writing a spec
file, running "rpm -bb" on it, and installing the resulting binary package with
"rpm -i" onto one or more systems, and the same principle applies to every
other
DESTDIR-based package manager.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
Bruce Dubbs wrote: > This seems to be the knotty problem. Just how are we going to *use* PM in > LFS? Both RPM and Debian package managers require writing a set of control files in order to create a package. Although it is possible to write dummy files containing only packaging information for pre-built files (and no building instructions), this is not how these tools are supposed to be used. I.e., I strongly object to this severe lobotomization. In this case, a simpler package management scheme is needed. However, in simple tar-based schemes, there is a trap in handling configuration files when upgrading a package. So: given that we still can't agree on the set of features to implement, I propose LFS to never have any sort of PM, and those who disagree with this "no PM" policy should start a fork right now. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
Gerard Beekmans wrote: > So to summarize simply using the %configure macro won't run it like we'd > want the configure script to be run. > > Can't it be overridden or introduce our own %configure-like macro that > does run things like the book does? Why not just say somewhere on the PM page that we don't use the %configure and similar macros in our spec files (and call ./configure directly instead) because we want 100% correspondence between commands in no-PM and RPM versions of LFS? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
Gerard Beekmans wrote: >> Yes. Note that I have not evaluated pacman. > > Do you by chance have any plans or desire to do so in the near future? Not in the nearest future--too busy with bureaucracy that surrounds presenting the dissertation (scheduled for July, 3). >> What's even more important for educational purposes, Debian rules are >> incoherent >> between various Debian packages. > > How does RPM differ in that regard? Couldn't RPM spec files (in theory?) > suffer from the same problem depending on who writes them? RPM doesn't have this amount of additional layers of almost-mandatory helpers for getting dependencies right, and the "debconf" tool for interactive package configuration. As I said, a few Debian packagers do things by hand, some use debhelper, some call cdbs (that doesn't even contain the explicit build instructions, but is suitable only for simple CMMI-like packages), and there are other options. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
Bruce Dubbs wrote: > The XML is used for generating the book in chunked and non-chunked versions, > populating and verifying completeness of the patch directory, generating a > wget > list, generating pdf, and checking for the completeness of files on anduin. > > It is *much* more flexible than a wiki. A wiki is wysiayg -- What you see is > all you get. Yes, that's the point, and you describe the purpose of the _current_ XML in the book precisely. The problem with Jeremy's approach is that his XML is different and unsuitable for PDF generation, and the rest of the tasks can be done with a simpler Wiki-like syntax once one writes additional parsers. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM vs DEB vs Slackware-like tgz
Gerard Beekmans wrote: > This continues the emails Alexander sent a while back (March 5). > > Alexander, am I correct in my assumption that you would consider RPM a > good choice and DEB a bad choice for LFS purposes. Yes. Note that I have not evaluated pacman. > Your emails made it sound (to me) that deb would be a lot harder to > implement, maintain and understand (config file wise ie debian/rules > files). RPM, on the other hand, sounds a lot simpler to implement and > maintain as far as you are concerned. What's even more important for educational purposes, Debian rules are incoherent between various Debian packages. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future of LFS
Jeremy Huntwork wrote: > 1) Continue to use XML as the source (because it is a standard for > defining data and is easily parsed) _but_ to use, as much as possible, > fewer and simpler tags. This is not the only standard for defining textual data, and some people think that XML is too verbose. Given that the PDF generation capability has been lost, what are the benefits over some wiki markup? IMHO, the LeafOS wiki syntax was better suited for the task, because there was no chance to make an error (there is no such thing as "invalid Wiki markup", but there is "invalid XML"). About the editor: it does show line numbers for errors, but it doesn't number lines. Inconvenient for large pages. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap (Was: Re: As promised: LFS compilation summary)
Marc McLaughlin (LUSYN) wrote: > Out of interest, which bootloaders mentioned by Jeremy for LFS 7.0 will > work with x86-64? I only managed to get my x86-64 LFS build booting > with EXTLINUX. LILO, Grub2. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
Dan Nicholson wrote: > Fedora is getting along fine without putting libraries in separate > subpackages. The -devel split is not really about putting headers somewhere else to save space, it's really about libraries. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
Dan Nicholson wrote: > I certainly agree that it's best to handle situations like that, but > does RPM even support it? I.e., if I split off a libssl subpackage > that just has libssl.so.0.9.8, would RPM even allow me to install a > newer version of libssl in parallel without --force or something? I > don't know much here, but it seems that Fedora is getting along fine > without putting libraries in separate subpackages. On the other hand, > I notice that Debian/Ubuntu always splits the libraries into separate > packages. Yes, both RPM and dpkg support this: RPM does this natively (two versions of the package can be co-installed if they have no conflicting files), and with dpkg it is a common convention to name library packages as "libssl0.9.8" or something like that (i.e., including the library soname in the package name), so that a new incompatible version of the library becomes a completely different and (from the viewpoint of dpkg) unrelated package. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
Jeremy Huntwork wrote:
> Alexander E. Patrakov wrote:
>> Glibc is not the best example for discussion. I requested such sample page
>> for
>> bash, not for glibc, for a reason: bash needs a specific patch in the RPM
>> case,
>> and I don't see the way to force such PM-specific instructions in the
>> current
>> framework.
>
> I expected you to bring this up. :) I wanted to test a package that also
> showed variance on architecture. Glibc fit that. As for forcing
> PM-specific instruction, that ability may not be present, but I don't
> believe it would be overly difficult to introduce. If you wish, I'll add
> the bash page as another example.
Not sure if I really want you to do this right now, given your words below ("It
was not the purpose of this POC"). Anyway, it can't hurt, so do as you wish.
>> * making one big RPM package with both the shared library and its headers
>> is
>> technically incorrect (this is not so severe for glibc, but think about
>> gradual
>> updates from libssl.so.0.9.8 to libssl.so.0.9.9, and that's impossible
>> without
>> removing a lot of dependent packages if one doesn't package the conflicting
>> headers in a separate RPM file);
>>
>> * the current framework doesn't allow for such split;
>>
>> * editors that don't use a package manager have to be taught about this.
>
> Well this is a sort of build methodology that needs to be worked out if
> bringing RPM to the table. It was not the purpose of this POC to sort
> out all of these issues, but merely to demonstrate how we can make the
> book dynamic.
I am not sure that I can call the result "a dynamic book". Input is specified
only once--on the start page. HLFS has achieved roughly the same with plain
DocBook, profile.condition, and a chooser page that lists all possible
alternatives--i.e., all with static pages. CLFS has achieved roughly the same
(but in a more fragile way) with XIncludes that also produced static pages for
all combinations. So all this POC proves so far is that there is one more
method
to create many linear books at once. Very good, but someone has to compare
these
methods as applied to our end goal: multiarch book with multiple styles of PM,
when nobody yet has invented a multitude of other choices (i.e., it is
currently
not the case that someone requested so many options that generating a static
book for every combination is not feasible).
(the paragraph above should not be treated as a criticism, the point is that
the
investigation should be continued to see the benefits and the drawbacks of the
new approach)
> Again, once we know what core things need to be marked and
> defined in order to produce such a packaging split, I don't think it
> would be difficult to add it in the framework. Since I haven't had
> experience with creating such split packaging, help with determining
> what is needed would be appreciated.
Think about partially installing several versions of the package at once. What
doesn't create file conflicts between major versions, should be split from the
rest. Basically, the items one should care about are:
1) dynamic libraries
2) their .so symlinks, static libraries and headers
3) documentation
4) message catalogs
5) other data
6) perl/python/ruby/tcl/whatever else modules & bindings
7) executable binaries (here think about multilib conflicts--e.g., you can have
only one of 32-bit and 64-bit "qtconfig" binaries installed simultaneously,
even
though both 32-bit and 64-bit Qt libraries can coexist).
(the above doesn't imply building 7 packages--ideally, these 7 items should be
grouped into one, two or three packages as required for reasonable installation
of multiple versions at once)
Anyway, it will probably boil down to specifying dirctories and filename masks
explicitly for each package, and thus is more a responsibility of the book
content writer than the framework.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Revisiting ideas
Dan Nicholson wrote: > I agree that there are major advantages to splitting the libraries out > of the package, but why can't you just update the whole openssl > package to get the library update? In fact, the -devel split you're > talking about where the bare .so links and the headers are in a > separate package wouldn't affect a library update in any way. In most > cases, the .so.* links are part of the main package anyway (including > openssl). Think about the way dependencies are expressed. The automatic dependnecy extractor says: "package cryptofoo [that was built before openssl upgrade] depends on libssl.so.0.9.8 due to library dependencies". If you attempt to upgrade the whole openssl library to 0.9.9 (i.e. a binary incompatible release--that's important) without the split, the package manager will not be able to do this, because the new package does not provide libssl.so.0.9.8 and thus the cryptofoo package's dependencies are not satisfied with the new openssl package. I.e., with such incompatible upgrades, it is convenient to have the following installed during the transitions: old openssl dynamic libraries without the .so symlinks, new openssl dynamic libraries with the .so symlinks, new headers. You can't have all three at the same time without splitting the package (assuming that the package manager knows about file conflicts). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
Jeremy Huntwork wrote: > http://linuxfromscratch.org/~jhuntwork/php-test/ IMHO, too much state is kept in the PHP session. This may lead to bugs if a reader first generates one book and then the other variant, differing in the amount of required information. Something may leak between the visits--e.g., this way it may be possible to trick the future scripts into generating a multilib 32-bit book by first visiting "x86_64 multilib" and then "x86". -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Revisiting ideas
Jeremy Huntwork wrote: > Hello, > > So I finally got a free evening and the energy to sit down and get > conceptual. This is the result: > http://linuxfromscratch.org/~jhuntwork/php-test/ > > Before replying about all that you see is wrong with it ;) keep the > following in mind: > > This is a rough draft! A proof-of-concept only, designed to show > possibilities and open up discussion/ideas. Think stick-figure. Glibc is not the best example for discussion. I requested such sample page for bash, not for glibc, for a reason: bash needs a specific patch in the RPM case, and I don't see the way to force such PM-specific instructions in the current framework. Although even for glibc, there is something to discuss: * making one big RPM package with both the shared library and its headers is technically incorrect (this is not so severe for glibc, but think about gradual updates from libssl.so.0.9.8 to libssl.so.0.9.9, and that's impossible without removing a lot of dependent packages if one doesn't package the conflicting headers in a separate RPM file); * the current framework doesn't allow for such split; * editors that don't use a package manager have to be taught about this. As for the generated pages: if the LiveCD is to be revived, this means packaging PHP and some lightweight HTTP server on it (I prefer lighttpd). It also means increased requirements for mirrors, both in terms of available software and the level of trust to the book authors (i.e., so that they don't put a malicious PHP script in order to compromise a lot of mirrors at once, or just unintentionally introduce a security hole). Are we ready to this? P.S. Sorry for several hackish HTTP requests to www.linuxfromscratch.org. So far, I have found no obvious way to compromise the scripts in the current PHP configuration. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS - DESTDIR Style (minor update)
Randy McMurchy wrote: > Cc: to BLFS-Dev > > Alexander E. Patrakov wrote these words on 03/31/08 10:44 CST: >> Bruce Dubbs wrote: >>> The implication of going to DESTDIR for LFS would imply doing the same >>> for BLFS. Some of the BLFS packages are not DESTDIR friendly. I can't >>> remember which ones off the top of my head, but I do recall some that >>> ignore DESTDIR, at least partially. >> All perl modules. See >> http://linuxfromscratch.org/pipermail/lfs-dev/2007-December/060640.html > > This message is after-the-fact and not really relevant to the previous > discussion. It is however, interesting. > > I just installed a Perl Module and not only was it native DESTDIR > friendly and multilib friendly, it installed files depending on the > native arch of the machine. I cannot confirm this. Both with perl-5.8.8 and 5.10.0, the package installs files into the DESTDIR, but it installs wrong files. See the URL above, I can add nothing to what is already said there. If you insist on your point, please provide full command lines starting with "perl Makefile.PL", and look into the .packlist and perllocal.pod inside the DESTDIR. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RPM
Bruce Dubbs wrote: > I would like to add RPM to BLFS because it is required for a system to be > compliant with the Linux Standards Base. Which version? 4.x and 5.x are completely different beasts. Anyway, LFS contains a severe deviation from LSB (no libncurses.so.5 by default, only a non-standard wide-character version, but here the standard is wrong), thus, I don't think that it is a good idea to use this "standard" as a rationale. Anyway, if you want (B)LFS to be LSB-compliant, you'll need to do a lot more things: 1) ld-lsb.so.3 -> ld-linux.so.2 symlink 2) a fake "lsb" RPM, because the standard requires that LSB packages must be installed without --nodeps 3) run their binary testsuite and fix all failures, even if this means downgrading versions and reintroducing other, more severe, bugs. See http://bugs.debian.org/401006 as an example that I would like to avoid. As for your proposal to put RPM into BLFS, I think this has to be discussed in LFS, too. Reason: package management belongs in the next-generation LFS, and it is an option to have it there, as opposed to BLFS. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A minor reorganization
I wrote: > Bruce Dubbs wrote: >> In conjunction with some of Alexander's proposals I would like to >> makes some changes. >> >> Does anyone object if I move section 4.5 (About SBUs) to right after >> section iv (Host System Requirements). >> >> I also want to rename the SBU section to "Time to Build an LFS >> System". And add some discussion about the overall time to build. > > Let's wait a bit for alternative proposals on renaming. No proposals :( So let's go either with your variant, or with "Hardware and Time Requirements" (and possibly rename "Host System Requirements" to "Host System Software Requirements"). My variant of renaming also allows to mention the "x86-only" limitation of LFS in any of the two sections. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
I wrote: > Bruce Dubbs wrote: >> Alexander E. Patrakov wrote: >>> Hello, >>> >>> Some newbies get caught by our advertisement (which might be true for >>> older versions of LFS, but is untested as of LFS-6.3): >>> >>>> It is not difficult to build an LFS system of less than 100 >>>> megabytes (MB), >>>> which is substantially smaller than the majority of existing >>>> installations. >>>> Does this still sound like a lot of space? A few of us have been >>>> working on >>>> creating a very small embedded LFS system. We successfully built a >>>> system >>>> that was specialized to run the Apache web server with approximately >>>> 8MB of >>>> disk space used. Further stripping could bring this down to 5 MB or >>>> less. Try >>>> that with a regular distribution! This is only one of the many >>>> benefits of >>>> designing your own Linux implementation. >> >> The above is still true, but perhaps there should be a modification: >> >> "It is not difficult to modify a standard LFS system to use less than >> 100 megabytes (MB)..." > > Yes, this is acceptable. After some thought, I still can't come with a complete, correct and meaningful paragraph. The problem is that, while the statements about achievable sizes are true, it is technically incorrect to show them as advantages of LFS. In fact, binary distros are more suitable to such reduction, because they (unlike LFS) survive removal of gcc painlessly. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A minor reorganization
Bruce Dubbs wrote: > In conjunction with some of Alexander's proposals I would like to makes some > changes. > > Does anyone object if I move section 4.5 (About SBUs) to right after section > iv > (Host System Requirements). > > I also want to rename the SBU section to "Time to Build an LFS System". And > add > some discussion about the overall time to build. Let's wait a bit for alternative proposals on renaming. It would be nice if memory requirements are also covered. Also, why it is placed after the "Host System Requirements" section and not before (not an objection, just curious)? > I will suggest that ALFS can > build a system in about two hours on a reasonably fast system, but ALFS is > not > recommended for first time LFS users. AFAIK, ALFS is not an active project (9 mails to the list and 0 SVN commits since January, 1st). So it would be better to say something like "a scripted build" (meaning user-written scripts) instead of "ALFS", and proide some concrete specs of a "reasonably fast system". -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
Bruce Dubbs wrote:
> Alexander E. Patrakov wrote:
>> Hello,
>>
>> Some newbies get caught by our advertisement (which might be true for older
>> versions of LFS, but is untested as of LFS-6.3):
>>
>>> It is not difficult to build an LFS system of less than 100 megabytes (MB),
>>> which is substantially smaller than the majority of existing installations.
>>> Does this still sound like a lot of space? A few of us have been working on
>>> creating a very small embedded LFS system. We successfully built a system
>>> that was specialized to run the Apache web server with approximately 8MB of
>>> disk space used. Further stripping could bring this down to 5 MB or less.
>>> Try
>>> that with a regular distribution! This is only one of the many benefits of
>>> designing your own Linux implementation.
>
> The above is still true, but perhaps there should be a modification:
>
> "It is not difficult to modify a standard LFS system to use less than 100
> megabytes (MB)..."
Yes, this is acceptable.
> I can't find anywhere where the book refers to a slow 586-class system.
It doesn't do so explicitly, but by showing how slim the final system can be,
it
implicitly suggests that it won't consume a lot of resources and is thus a
suitable choice for old hardware.
> The SBU section already says that "Glibc .. could take up to three days on
> slower
> systems!"
Sorry, I missed it. But see the proposed alternative/additional wording below.
The point that "there is a better way than to wait three days" is currently not
addressed.
>> P.S. I accept the challenge to "try that with a regular distribution".
>
> I am waiting for your results. Can you do it without breaking updates via
> their
> package manager?
I started with Debian Etch, choosing "No localization" (i.e., "C" locale).
Fresh network-based installation with all options in tasksel (even "standard
system" deselected): 268 MB (according to "df", which also reports
filesystem-related overhead).
After running "apt-get clean" to remove downloaded *.deb files: 209 MB
Then I removed the following "obvious" packages:
acpid, dselect, tasksel, tasksel-data, info, man-db, manpages, ed, vim-common,
vim-tiny (nano is the remaining editor), libc6-i686, installation-report,
iptables, netcat, traceroute, libsasl2, groff-base, acpi, bsdmainutils,
console-common, console-data, console-tools, libconsole, dmidecode,
laptop-detect, usbutils, libgdbm3: the remaining system occupies 196 MB, out of
that /var is 51 MB, /lib/modules is 43 MB, and /usr/share is 40 MB.
The next step is to install "debconf-english" instead of "debconf-i18n" and
remove the following packages that are no longer needed:
liblocale-gettext-perl,
libtext-charwidth-perl, libtext-iconv-perl, libtext-wrapi18n-perl, so that the
result is 195 MB.
Then, for a web server, install lighttpd "without recommends". This will pull
in
lighttpd, mime-support and libpcre3. Thus, a Debian-based system with a
static
web server and with no manually-removed files takes 196 MB.
One can comment out all lines in /etc/apt/sources.list and run "aptitude
update". This will remove long package lists from /var, bringing it down to 18
MB (out of that, /var/log occupies 9.4 MB, and the total size of the system is
162 MB).
Then one can remove unneeded modules. I allowed only ne2k-pci, 8390, piix,
ide-disk, ide-core, jbd, ext3 and mbcache modules (required by qemu virtual
hardware) to stay (and to propagate to initramfs, by running "update-initramfs
-u -k all").
Then, translated message catalogs (/usr/share/locale), character set conversion
modules (/usr/lib/gconv) and optimized libraries ({/usr,}/lib/i?86*) go away.
Then, configuration data from stale packages:
dpkg -l | grep ^rc | awk '{ print $2 }' | xargs dpkg --purge
So, the system is down to 76 MB according to "df" (including 18 MB of data in
/var), still boots, serves static HTML files, logs everything, rotates logs,
and
can be fully restored from a Debian mirror. It is interesting that the ext3
overhead is significant: according to "du -shx /", the system takes 65 MB.
Further reduction requires sacrificing the ability to restore from a Debian
mirror (i.e., to remove apt and related packages). This doesn't remove the
ability to install packages "by hand" with dpkg, so counts only as "breaking
repository support", not as "completely breaking a package manager". However,
due to dependency of lighttpd (in particular, mod_auth.so) on libldap2, this
doesn't help. Well, further manual reduction is possible, but breaks
dependencies (e.g., on
Re: LFS size and hardware requirements
J. Greenlees wrote: > and this is done manually typing in, or copy and paste of the build > commands? > or is it scripted to remove the manual input [ slow point ] requirement? It is completely scripted, see the LiveCD SVN repository. I can't afford any uncertainty due to typos for official LiveCD releases. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS size and hardware requirements
J. Greenlees wrote: > 8 hour build time? unless using the build scripts I don't think it's > possible without brand spanking new hardware with massive amounts of ram. ums.usu.ru (before it died in November, 2007 due to voltage spike): Pentium IV 2.4 GHz (without hyperthreading), Intel S845WD1-E server board, 512 MB of RAM, 120 GB IDE hard disk. Bought in May, 2003, not upgraded since then until the complete replacement in November, 2007. Able to build LFS LiveCD (the full version) in 12 hours. So we are not speaking about brand new hardware. And the "8 hours" figure has the following origin: it's the maximum amount that we can realistically expect a typical desktop computer to stay on, so one doesn't have to bother with exiting and reentering the build environment (that is poorly documented in the book, probably because it is not supposed to be done). >> Hard disk space is a mandatory requirement. >> Disk requirement on IPCop is 2 GB free space before building. >> Indicative minimal memory could be somewhere between 128 MB. >> Recommended memory to build should more than 256 MB >> I have mesured IPCop 1.4 (is with gcc-3.3) building time on the same machine >> with 128 MB and 512 MB. 128 MB require 3 time more to build than with 512 MB >> memory. We are talking about a bit different things. The paragrapk above is talking about building gcc-3.3 based IPCop from itself - that's fine. But building gcc-4.x with gcc-3.3 triggers a known bug in gcc-3.3 that leads to huge consumption of memory (above 512 MB). > and the learning opportunities for building on a more limited resource > system are greater, you run into problems from the limitations. Let me just throw your child into water and say "he learns swimming" (bad joke: I can't swim). No, learning must be gradual, the reader must see a trouble-free book first and _then_ experiment. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS size and hardware requirements
Hello, Some newbies get caught by our advertisement (which might be true for older versions of LFS, but is untested as of LFS-6.3): > It is not difficult to build an LFS system of less than 100 megabytes (MB), > which is substantially smaller than the majority of existing installations. > Does this still sound like a lot of space? A few of us have been working on > creating a very small embedded LFS system. We successfully built a system > that was specialized to run the Apache web server with approximately 8MB of > disk space used. Further stripping could bring this down to 5 MB or less. Try > that with a regular distribution! This is only one of the many benefits of > designing your own Linux implementation. ...and attempt to build LFS on their slow 586-class computers with only 16 MB of RAM. This is obviously a waste of time, both for them and for us. Additionally, the mentioned 100 MB system obviously contains significant deviations from the book and thus cannot be counted as LFS. P.S. I accept the challenge to "try that with a regular distribution". Proposal: 1) Remove this advertisement. 2) List hardware requirements (CPU, RAM, hard disk space) on the same page as software host requirements, or immediately before it. These requirements should be set so that the total build time (including all testsuites) is less than 8 hours, and that the build process never needs to get into swap (the worst case seems to be Chapter 5 gcc Pass1 when starting from a host that is based on gcc-3.3). 3) When package management enters the book, include a procedure for building packages for a lower CPU (basically, import config.site from the LiveCD and adjust toolchain and perl configure arguments as done there) and transferring LFS and subsequent packages to a different machine. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
Dan Nicholson wrote: > On Fri, Apr 4, 2008 at 7:28 AM, Alexander E. Patrakov >> For a regular distro, I would agree. For a third-party LiveCD, I disagree. > > I still don't think instructions should be special for this situation. > If you chose a host that doesn't provide the necessary development > environment and doesn't provide the means to acquire the necessary > environment, then that probably wasn't the best choice. Instead, I'd > rather that the hostreqs page said "If you're host doesn't contain the > necessary requirements and doesn't provide a means to acquire them, > see the instructions in Ch. 6 as a guide to building them." Maybe it is a good idea. But my point is that there are almost no LiveCDs other than (no longer existing) LFS LiveCD that serve as a good starting point (by meeting the host requirements). Some people think it is a problem with the LiveCD-based hosts. Other people think that it is a problem with our requirements. Both viewpoints are valid, but as long as LFS mentions the possibility to build from _a_ LiveCD, it has to have host requirements compatible with LiveCDs. Or maybe the whole paragraph about using a LiveCD should be dropped from http://www.linuxfromscratch.org/lfs/view/development/chapter01/how.html -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
Dan Nicholson wrote: > On Thu, Apr 3, 2008 at 8:15 PM, Alexander E. Patrakov > <[EMAIL PROTECTED]> wrote: >> Dan Nicholson wrote: >> > You really need gawk, not mawk. >> >> Then please add gawk and bison in Chapter 5 before binutils, to accomodate >> Debian-based LiveCDs and PCLinuxOS, respectively. > > The host requirements specify _Gawk_ 3.0. I really would prefer people > just check the host requirements instead of shoehorning temporary > packages at the beginning of the chapter. For an automated > environment, maybe, but it would just be clutter in the book. For a regular distro, I would agree. For a third-party LiveCD, I disagree. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20080403 : 5.6.1. Installation of Glibc failure
Dan Nicholson wrote: > You really need gawk, not mawk. Then please add gawk and bison in Chapter 5 before binutils, to accomodate Debian-based LiveCDs and PCLinuxOS, respectively. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/4/3, Alexander Kozlov <[EMAIL PROTECTED]>: > > Bryan Kadzban wrote: > >> Since that's the problem, we could move in one of two directions > >> to fix it: either stop using any filesystem driver in the > >> bootloader(which means, at this point, "move to LILO"), or fix > >> the ext2/3 driver in grub (with the patch). > > Just wonder, why not SYSLINUX? Not friendly, true, but mighty > powerful and flexible. Could be a chapter in BLFS too. Syslinux does come with a boot loader that can boot Linux kernels from ext2 filesystems, is actively maintained, and is thus a valid candidate for inclusion in LFS, together with its dependency on nasm. However, not everyone uses ext2/ext3, so it cannot be the only candidate. As for BLFS: my own opinion is that it contains after-the-first-reboot steps, and installing a boot loader is not one of such steps. Even more: various non_ext2-fsprogs don't actually belong there. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: e2fsprogs in chapter 5?
Jeremy Huntwork wrote: > As I'm going through the book, I realized I couldn't place why e2fsprogs > is built in chapter 5. The description about udev needing its headers > makes no sense to me... util-linux-ng needs either libblkid from e2fsprogs or libvolume_id from udev. Libblkid is easier to build. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
J. Greenlees wrote: > Personally, on the svn version I'm doing a test build with, I went lilo > before starting and made sure I had the sources and dependencies sources. > [ lilo depends on nasm according to the hint on the website for > "beautifying lilo" ] Are you sure? The LiveCD contains LILO and uses bin86, bot nasm, to build it. > With the direction for LFS discussions, isn't presenting the options in > keeping with the general input for the direction, which was to make LFS > more a guide to creating a distro if I remember correctly than just a > guide to building a linux system? This, by itself, looks right. Let's see if the book and our resources can bear this. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS - DESTDIR Style
Bruce Dubbs wrote:
Randy McMurchy wrote:
Thoughts from others?
Looks interesting. Where do you put your DESTDIR? Is it a part of the
chroot partition?
It can't be outside this partition. With RPM, this is typically
/var/tmp/pkgname-root/ , and with dpkg, this is always the `pwd`/debian/tmp
directory.
The implication of going to DESTDIR for LFS would imply doing the same
for BLFS. Some of the BLFS packages are not DESTDIR friendly. I can't
remember which ones off the top of my head, but I do recall some that
ignore DESTDIR, at least partially.
All perl modules. See
http://linuxfromscratch.org/pipermail/lfs-dev/2007-December/060640.html
And the fix is to patch perl, see how Debian does this (completely untested,
likely not directly applicable to LFS, you probably need only a subset of this)
In any case, a svn branch that shows what you are doing would be quite
appropriate.
+1.
--
Alexander E. Patrakov
--- perl-5.8.8.orig/lib/ExtUtils/MM_Unix.pm
+++ perl-5.8.8/lib/ExtUtils/MM_Unix.pm
@@ -20,7 +20,7 @@
use ExtUtils::MakeMaker qw($Verbose neatvalue);
-$VERSION = '1.50';
+$VERSION = '1.50_01';
require ExtUtils::MM_Any;
@ISA = qw(ExtUtils::MM_Any);
@@ -2054,9 +2054,7 @@
$(NOECHO) $(ECHO) INSTALLDIRS not defined, defaulting to INSTALLDIRS=site
pure_perl_install ::
- $(NOECHO) $(MOD_INSTALL) \
- read }.$self->catfile('$(PERL_ARCHLIB)','auto','$(FULLEXT)','.packlist').q{ \
- write }.$self->catfile('$(DESTINSTALLARCHLIB)','auto','$(FULLEXT)','.packlist').q{ \
+ $(NOECHO) umask 022; $(MOD_INSTALL) \
$(INST_LIB) $(DESTINSTALLPRIVLIB) \
$(INST_ARCHLIB) $(DESTINSTALLARCHLIB) \
$(INST_BIN) $(DESTINSTALLBIN) \
@@ -2068,61 +2066,41 @@
pure_site_install ::
- $(NOECHO) $(MOD_INSTALL) \
+ $(NOECHO) umask 02; $(MOD_INSTALL) \
read }.$self->catfile('$(SITEARCHEXP)','auto','$(FULLEXT)','.packlist').q{ \
write }.$self->catfile('$(DESTINSTALLSITEARCH)','auto','$(FULLEXT)','.packlist').q{ \
$(INST_LIB) $(DESTINSTALLSITELIB) \
$(INST_ARCHLIB) $(DESTINSTALLSITEARCH) \
$(INST_BIN) $(DESTINSTALLSITEBIN) \
- $(INST_SCRIPT) $(DESTINSTALLSCRIPT) \
+ $(INST_SCRIPT) $(DESTINSTALLSITESCRIPT) \
$(INST_MAN1DIR) $(DESTINSTALLSITEMAN1DIR) \
$(INST_MAN3DIR) $(DESTINSTALLSITEMAN3DIR)
$(NOECHO) $(WARN_IF_OLD_PACKLIST) \
}.$self->catdir('$(PERL_ARCHLIB)','auto','$(FULLEXT)').q{
pure_vendor_install ::
- $(NOECHO) $(MOD_INSTALL) \
- read }.$self->catfile('$(VENDORARCHEXP)','auto','$(FULLEXT)','.packlist').q{ \
- write }.$self->catfile('$(DESTINSTALLVENDORARCH)','auto','$(FULLEXT)','.packlist').q{ \
+ $(NOECHO) umask 022; $(MOD_INSTALL) \
$(INST_LIB) $(DESTINSTALLVENDORLIB) \
$(INST_ARCHLIB) $(DESTINSTALLVENDORARCH) \
$(INST_BIN) $(DESTINSTALLVENDORBIN) \
- $(INST_SCRIPT) $(DESTINSTALLSCRIPT) \
+ $(INST_SCRIPT) $(DESTINSTALLVENDORSCRIPT) \
$(INST_MAN1DIR) $(DESTINSTALLVENDORMAN1DIR) \
$(INST_MAN3DIR) $(DESTINSTALLVENDORMAN3DIR)
doc_perl_install ::
- $(NOECHO) $(ECHO) Appending installation info to $(DESTINSTALLARCHLIB)/perllocal.pod
- -$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
- -$(NOECHO) $(DOC_INSTALL) \
- "Module" "$(NAME)" \
- "installed into" "$(INSTALLPRIVLIB)" \
- LINKTYPE "$(LINKTYPE)" \
- VERSION "$(VERSION)" \
- EXE_FILES "$(EXE_FILES)" \
- >> }.$self->catfile('$(DESTINSTALLARCHLIB)','perllocal.pod').q{
doc_site_install ::
- $(NOECHO) $(ECHO) Appending installation info to $(DESTINSTALLARCHLIB)/perllocal.pod
- -$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
- -$(NOECHO) $(DOC_INSTALL) \
+ $(NOECHO) $(ECHO) Appending installation info to $(DESTINSTALLSITEARCH)/perllocal.pod
+ -$(NOECHO) umask 02; $(MKPATH) $(DESTINSTALLSITEARCH)
+ -$(NOECHO) umask 02; $(DOC_INSTALL) \
"Module" "$(NAME)" \
"installed into" "$(INSTALLSITELIB)" \
LINKTYPE "$(LINKTYPE)" \
VERSION "$(VERSION)" \
EXE_FILES "$(EXE_FILES)" \
- >> }.$self->catfile('$(DESTINSTALLARCHLIB)','perllocal.pod').q{
+ >> }.$self->catfile('$(DESTINSTALLSITEARCH)','perllocal.pod').q{
doc_vendor_install ::
- $(NOECHO) $(ECHO) Appending installation info to $(DESTINSTALLARCHLIB)/perllocal.pod
- -$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
- -$(NOECHO) $(DOC_INSTALL) \
- "Module" "$(NAME)" \
- "installed into" "$(INSTALLVENDORLIB)" \
- LINKTYPE "$(LINKTYPE)" \
- VERSION "$(VERSION)" \
- EXE_FILES "$(EXE_FILES)" \
- >> }.$self->catfile('$(D
Re: LFS - DESTDIR Style
Randy McMurchy wrote: > I also track every file that may conflict or overwrite with an existing > file on the system. This is not intended to be a package manager, > however, it would be trivial to create one from it (I do). > > Much of this is done via scripts (code snippets) that can be reused > in each package. There is no manual work as I think I've got > everything automated. Not automated as in jhalfs, but in the sense > that there is a series of commands that does everything. > > I'm somewhat bored with building LFS, so I changed things up a bit, > and I now like it and will be married to DESTDIR type installations > from here on out. > > I'm not trying to push this on anyone, I'm only saying that I can > help if the community sees this as a direction we may go towards one > day. Many others including Dan, Tushar, et. al. may be willing to > assist or contribute as well. > > Thoughts from others? You have essentially duplicated Dan's RPM work, see http://gitweb.dwcab.com/?p=pound.git;a=summary . In this case, duplication is good, because it helps to spot errors. Please continue this good work, e.g., by building dependencies of the MOC player (or any other useful package), see http://moc.daper.net/links . -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
The LFS LiveCD project is dead. Officially.
Hello, as you can easily find out in Trac, the latest change in the LiveCD repository not by me is dated 08/21/07, i.e., more than 7 months ago. And there are no substantial changes since 12/29/07. The LiveCD contains more than 200 packages, and that's way too much for one person to maintain. For me, the LiveCD was a playground that might help pushing some ideas into LFS and/or BLFS by providing a sample implementation. Essentially, it was a fork of LFS (now mostly fixed) and BLFS. Some of the ideas got implemented: UTF-8 support in LFS, PPP and PPPoE configuration in BLFS. Some were at least considered, but too much is just stalled. Thus, I lost my primary motivation to continue the work, and, in the absense of the replacement team, hereby declare the LiveCD project to be officially dead. The demand for it doesn't matter for me and, by itself, won't resurrect the project. The latest LFS LiveCD version will still remain available on the mirrors. Here is an incomplete backlog of ready things to be investigated for merging (or maybe just thrown away due to lack of manpower to maintain them--but note that they do exist on the LiveCD that was essentially maintained by me alone): * XIM-based input. Absolutely required for Chinese, Japanese, Corean and some other languages. Described at http://wiki.linuxfromscratch.org/blfs/wiki/InputMethods, even including a testcase that allows to see easily whether it works. Confirmed for Chinese on IRC by a native speaker. * Initramfs. Absolutely required for booting from non-standard devices such as dmraid (which is required on some fakeraid controllers for dual-booting with Windows on the same RAID), LVM2 or just SCSI controllers that require firmware. * Accessibility-related packages (currently, only for the Linux console). * GPM in LFS (this is an optional dependency of ncurses, allows you to click through dialogs created with the "dialog" package on the Linux text console). * Hibernation, either with the "hibernate" script (as implemented on the CD) or with a more modern (but not fully working for me) pm-utils package. * config.site file for system-wide changes to the confgure script. I use it for forcing the i486 compilation, setting optimization flags and removal of static libraries. * Compiling on fast machines (e.g., Core 2 Duo) for lower processors (e.g., i486) and deploying the result. * x86_64 support. Also, since the LFS LiveCD no longer exists, the LFS book page about the host requirements has to be modified. Maybe we should list LiveCDs that come with gcc and a recent-enough kernel. However, the only live ISO files known to me that come with gcc are Knoppix (but the latest version is available only as a huge DVD) and Zenwalk (Slackware-based, and thus too buggy, especially when it comes to non-English language support). Any other alternatives? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gdk-pixbuf.loaders, DESTDIR and libgnomeui
Sukucorp Sukucorp wrote: > If you use DESTDIR approach, you are deviating from the book. If you > are deviating from the book it is assumed that you know what you are > doing. > > Anyway this point might be moot if LFS starts supporting a package > manager of some sort. With this "discouraging" attitude, package management will never become part of the LFS book. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Improper handling of -p ${pidfile} in lfs-bootscripts
Dan Nicholson wrote: > The problem is, for BLFS-6.3, we have to rely on the bootscripts from > LFS-6.3, which have this bug. No. We can (and, IMHO, should) release LFS-6.3.1 right now, with this fix and GRUB patch to fix incompatibility with the new e2fsprogs that may be present in the latest distros. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Which type of LFS should I choose on 64bit system
2008/3/24, Phillip Huang <[EMAIL PROTECTED]>: > Hello folks, > > I want to build LFS on my new 64bit platform(Intel EM64T), and I googled > CLFS, > while according to another link: http://lwn.net/Articles/243695/ > > JH said the x86_64 LFS LiveCD was available in July 30,2007, and the above > link provide download address. However, I do not find any relevant manual > about how to install this x86_64 LFS. The official 64-bit CD contains the unofficial modified 64-bit book. However, it doesn't contain a boot loader, so you have to invent your own instructions for bin86 and LILO. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Bruce Dubbs <[EMAIL PROTECTED]>: > What distros use the new version of e2fsprogs? What boot loader do > those distro's use? Debian Lenny. It offers a choice among a patched version of Grub Legacy, LILO, and GRUB2. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Bruce Dubbs <[EMAIL PROTECTED]>: > My position is that we should stay with grup 0.97 and the compatible > version of e2fsprogs until upstream gets the problems worked out. This doesn't work: GRUB has to be compatible not only with the LFS version of e2fsprogs, but also with the hosts's version. We expect GRUB to boot not only LFS, but also a host distro. If a host distro uses a new ext3 filesystem, we have a big problem. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, Matthew Burgess <[EMAIL PROTECTED]>: > Does LILO still require NASM? No, but it requires bin86. -- Alexander E. Patrakov (writing from FreeBSD 7.0 amd64) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: > http://gag.sourceforge.net/ Requires Borland Turbo Assembler (available for MS-DOS only) in order to be recompiled. LFS cannot assume that this proprietary OS is installed. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/19, J. Greenlees <[EMAIL PROTECTED]>: > GAG Not tested yet, will do now. > http://gujin.sourceforge.net/ Tested seveal months ago, had a conversation with the author about the QEMU bug (unfortunately, the proposed fix broke something in SUSE) and the bogus LANG=en argument being appended to the kernel command line. Drawbacks: * Triggers a keyboard/mouse emulation bug in QEMU and KVM * Has no config file, attempts to guess append the "root=/dev/hdXY" parameter automatically. * Thus, is incompatible with libata until this guessing is disabled (one can do it from the command line of the installer). * This manual override works only on a global basis, thus, one cannot explain that one kernel (from a host distro) should be used with one root partition, while the other kernel has another root. The last item makes this boot loader unsuitable for LFS, since LFS relies on the ability to dual-boot LFS and the host until one installs a DHCP client and a web browser. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/17, Alexander E. Patrakov <[EMAIL PROTECTED]>:
> Instructions for the impatient:
>
> lzo-2.02: ./configure --prefix=/usr && make && make install
> grub-1.96: ./configure --prefix=/usr --sysconfdir=/etc && make && make
> install
>
> # the need to add --modules="pc" is a bug,
> # grub-install is advertised to be able to autodetect the needed modules
> grub-install --modules="pc" /dev/hda
>
> cat >/boot/grub/grub.cfg <<"EOF"
> set default=0
> set timeout=5
> set root=(myvg-root)
> terminal console
>
> menuentry "LFS-6.3 on LVM" {
> linux /boot/linux root=/dev/myvg/root
> initrd /boot/initramfs_data.cpio.gz
> }
>
> EOF
Spoke too soon. Today this virtual machine refused to boot, for no
apparent reason. Grub2 drops to the rescue mode, and typing these two
commands brings the menu back:
insmod normal
normal
...even though, according to the source (kern/main.c, functions
grub_main() and grub_load_normal_mode()), loading the "normal" module
and switching to the normal mode are the first things that are
supposed to be done automatically and unconditionally.
I really don't want this to happen with your computer. Thus, please,
no Grub2 in LFS for now.
Also its ./configure script looks for ruby as an optional build-time
dependency, in order to convert unifont to a format that Grub
understands (required for graphical booting).
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
Sebastian Faulborn wrote: > How do you mean - "not installable at all if root is on LVM2"? I have been > using LVM2 on root together with grub for the last 2 years without problems... That was about Grub2. Grub legacy, with a separate /boot partition, works fine. And I mean that the command "grub-install" or "grub-setup" fails to figure out how to access the /boot file system. It mistakenly starts searching how to access "/" (although it shouldn't), fails and thus fails the whole installation process. This bug is fixed in version 1.96. > Grub is only used for loading the kernel and starting it - so as long as grub > can read the /boot partition it's fine... Yes. However, you should install Grub into MBR first, and that failed with Grub-1.95. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/17, Greg Schafer <[EMAIL PROTECTED]>:
> What about Grub2? The time must be getting near.. Anyone use it?
I was able to make it work in QEMU in the "new ext3 on LVM2 on
/dev/hda1, no /boot partition" case. But the lack of up-to-date
documentation in the tarball and incompleteness of the documentation
at http://grub.enbug.org/FrontPage are, IMHO, major obstacles, and due
to this, I would like LFS to be a bit more conservative (i.e., not
dump two problems on the reader--LFS itself and new GRUB; successful
education is always gradual education).
Instructions for the impatient:
lzo-2.02: ./configure --prefix=/usr && make && make install
grub-1.96: ./configure --prefix=/usr --sysconfdir=/etc && make && make install
# the need to add --modules="pc" is a bug,
# grub-install is advertised to be able to autodetect the needed modules
grub-install --modules="pc" /dev/hda
cat >/boot/grub/grub.cfg <<"EOF"
set default=0
set timeout=5
set root=(myvg-root)
terminal console
menuentry "LFS-6.3 on LVM" {
linux /boot/linux root=/dev/myvg/root
initrd /boot/initramfs_data.cpio.gz
}
EOF
Configuration can be adjusted to show a JPEG image in the background
and have a nice font, but I think that the above example is enough.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/17, Alexander E. Patrakov <[EMAIL PROTECTED]>: > They released version 1.96 on March, 3 Oops, that was in February. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing a boot loader for LFS 7.0
2008/3/17, Greg Schafer <[EMAIL PROTECTED]>: > Hi Alex, interesting. A couple of questions/observations. > > - Does the problem exist when Grub installation is run in its preferred > native mode as per the Grub docs? ie: not run from within a running Linux > kernel, but instead run from eg: a floppy before any OS is loaded? Yes. In both modes, Grub interprets the filesystem using its own driver, not the kernel driver, and the problem is that its own driver doesn't understand new ext2 filesystems. > - There is nothing stopping folks from changing the default Inode size > back to 128 via editing /etc/mke2fs.conf or via a command line switch. > LFS could just warn, yes? That's not so horribly broken, is it? This is probably true, but going this route means that one can no longer boot the host distro if its kernel is on the new ext2 filesystem (that was aready created, and thus it is too late to change it). Thus, it is not acceptable. > - LFS could change its install paradigm. There is no need to create the > target partition immediately from the outset. For example, I > intentionally changed this aspect in the DIY Refbuild in order to avoid > the situation that's occurred in the past whereby creating a target fs > with a too new E2fsprogs (think Fedora host) causes incompatibilities > with the (older) version being installed. Correct, this also opens the opportunity to explain the procedure of backing up LFS with tar, installation onto LVM2, or making a cluster of NFS-root machines. > > Did anyone investigate the boot loader options further? What should be > done for > > LFS-7.0? > > What about Grub2? The time must be getting near.. Anyone use it? Version 1.95 was not installable at all if root is on LVM2 (even if /boot is on a plain partition). They released version 1.96 on March, 3, and it is indeed a good idea to test it. According to Debian, this particular incompatibility doesn't affect Grub2, but it still uses its own ext2 driver and thus is not protected from this kind of bugs in the future. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Choosing a boot loader for LFS 7.0
Hello, as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker), due to recent changes in e2fsprogs, Grub-0.97 no longer works (cannot read any files from the resulting filesystem, cannot be installed into MBR, and the book is thus horribly broken). There are a couple of tickets about alternative boot loaders: http://wiki.linuxfromscratch.org/lfs/ticket/2093: just a proposal to add a new section about boot loaders; http://wiki.linuxfromscratch.org/lfs/ticket/1955: duplicate, but with more discussion. Did anyone investigate the boot loader options further? What should be done for LFS-7.0? And before anyone objects to LILO on the basis that you must not forget to run it: write the /sbin/installkernel script and run "make install" in the kernel tree (it calls /sbin/installkernel, that should rename and install bzImage and update the boot loader), and the problem of forgetting to run lilo will go away. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
kbd bug
I wrote: > Ag. D. Hatzimanikas wrote: >> wget >> ftp://ftp.ntua.gr/pub/linux/gentoo/distfiles/links-2.1pre33-utf8.diff.bz2 >> # -> Setup -> Terminal Options and check the "UTF-8 I/O" box >> # -> Setup -> Character Set and choose KOI8-RU >> # and while you have links running >> g >> www.in.gr >> # -> Setup -> Character Set and choose "ISO 8859-7" >> -->% >> >> Also entering text in web forms seems to work with an exception (I >> can't get an "μ", I take "υ" instead in VT mode). > > Bug in one of the programs called by the "console" bootscript, because > the key doesn't produce the correct character even in bash command line. This is a bug in loadkeys. It looks like the definition of "mu" is taken from the ISO-8859-1 table by "loadkeys -u". What should we do in the console script to avoid triggering of this bug? Or maybe make a kbd patch that adds a pre-made Greek UTF-8 keymap with "U+03bc" instead of "mu"? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
Gerard Beekmans wrote: > If you feel you can talk about a potential PM candidate for LFS, please > write up a document that outlines the following: Slackware-like .tgz > - it's strengths and weaknesses + It is very simple, and everybody is expected to understand the code. - Out of the box, it requires tar-1.13 due to the reasons outlined in ftp://ftp.slackware.com/pub/slackware/slackware_source/a/tar/tar.SlackBuild (that are, IMHO, invalid--you should use ext3 on LVM2 and never have problems with free disk space). Anyway, this requirement is easy to patch out. + It has no external dependencies except dialog (which is optional and depends only on ncurses anyway). - It has no features one expects from a sane package manager, such as dependency checking. To work around this, the Slackware installer recommends installing all packages from the DVD. * Configuration file handling is emulated with post-installation scripts, by renaming the packaged copies to *.new and using code such as ftp://ftp.slackware.com/pub/slackware/slackware_source/a/udev/doinst.sh - Packages have to be built as root (workaround: install fakeroot from Debian). - No checking of the package contents is possible unless one patches the makepkg script. + It manipulates binary packages, with obvious benefits like the ability to deploy them, to revert to the old version quickly, and so on. + Packaging and build instructions are in one file, with the .SlackBuild extension. Such files are very easy to write from scratch, because they are just bash scripts. + It is buildsystem-independent. - Instead of SlackBuild scripts, there is a temptation to produce Slackware packages with checkinstall--but this will clobber configuration files. - It comes from Slackware, against which I have prejudice (they oversimplify a lot of things). + Text-based database > - why it's better than other candidates Because it is very simple. > - why it's worse than other candidates Because it is only a toy model of a package manager. It can only install packages by untarring the archive and running the install/doinst.sh.script, uninstall them, and list packages claiming ownership of a file. It cannot explain why each package is needed in the system, and doesn't prevent its removal when in fact there are other packages depending on it. > - what it takes to integrate it in the LFS book >* not looking for installation instructions. Just explain the impact > and changes that will be required for successful use Write SlackBuild scripts: this means DESTDIR, post-installation steps, and, for each configuration file, renaming it by adding the .new extension and writing a scriptlet like ftp://ftp.slackware.com/pub/slackware/slackware_source/a/udev/doinst.sh > - what it likely is not able to do for its users Any kind of dependency tracking. > - how well it can deal with matters such as conflict resolution and > dependency handling It can't, by design. Upgrading a package means: 1) Installing a new version, so that it overwrites some old files. At this point, _two_ packages (old and new) will claim ownership of some files. 2) Deleting the old version, so that files that existed only in the old version get deleted because their reference count drops to zero. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
I wrote: > Greg Schafer wrote: >> You seem to be striving for perfection. When I want all the bells and >> whistles I run a mainstream distro. > > Without this, LFS is unsuitable for production use. Nevertheless, people > want it. There are only two ways to deal with this situation: make LFS > work perfectly, or drive them away from LFS even before they think about > it in production. So, we are back at the old dilemma about LFS-course > (that has to be simple and fully understandable by everyone, possibly > even oversimplified, and it is not a bug that it doesn't work for a > significant portion of users) vs LFS-distro (that also has to be > present, just to show the shortcomings of LFS-course as a distro). Sorry for this part of the message, it's too flame-prone. Here is a better expression of the same thought: Some people do want to use LFS in production. There are only two ways to deal with this situation: make LFS work perfectly, or drive them away from LFS, e.g., by including somewhere in the preface some concrete missing features that make LFS unsuitable for production use, and give some foundations to the fact that these features are really required. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
Greg Schafer wrote: > Alexander E. Patrakov wrote: >> does it >> allow running arbitrary scripts on the DESTDIR contents before >> actually creating a package? > > Um, I don't think so. However, while Pacman itself is written in C, the > "makepkg" portion of the system is a Bash script which allows easy > hackability. That's what allowed Alex Merry to write the fake_install() > patch that I still use today. I.e., writing such patch would be easy. That's enough. > While I'm a Pacman fan, it is by no means a perfect PM. It uses an > ASCII text package database which tends to slow down when you have a > zillion packages installed. The same applies to dpkg. > It probably won't do everything you want, like > easy splitting off of -devel and runtime packages. How does Arch Linux handle library transitions then? E.g., suppose that a new version of OpenSSL appear that builds libssl.so.0.9.9. How do they avoid the situation that some of the binary packages (those not yet rebuilt) want the old libssl library? > You seem to be striving for perfection. When I want all the bells and > whistles I run a mainstream distro. Without this, LFS is unsuitable for production use. Nevertheless, people want it. There are only two ways to deal with this situation: make LFS work perfectly, or drive them away from LFS even before they think about it in production. So, we are back at the old dilemma about LFS-course (that has to be simple and fully understandable by everyone, possibly even oversimplified, and it is not a bug that it doesn't work for a significant portion of users) vs LFS-distro (that also has to be present, just to show the shortcomings of LFS-course as a distro). > It is simply too labour intensive to > have "the lot" on a self built system. I looked at the amount of effort > Dan has apparently put into his RPM based system and weeped :-( Pacman is > good enough for my meagre needs, but I wouldn't use it if, for example, I > was trying to be the next Ubuntu. Here I fully agree. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Poll results
m"/"I will ignore PM that doesn't allow package transfer" 0.33: "I use PM to revert mistakes"/"I will ignore PM that fails on busy system" 0.32: "I use PM for upgrading toolchain easily"/"I use PM to compile once, deploy everywhere" 0.32: "I will ignore PM that fails on busy system"/"I will ignore PM with non-bash syntax" -0.31: "I trust the book"/"I want to know where each file comes from" -0.31: "I trust the book"/"I use the clean-uninstallation feature" 0.31: "I use PM for removal of obsolete files"/"I won't use PM that clobbers config files" Now the important, in my opinion, parts: DESTDIR-based techniques are not as popular as others! So we have to learn them first before writing about them. Probably, this happens because the current LFS book is not really suited to DESTDIR. See also the high correlation coefficient (0.43) between this and deviation from LFS. The "I rebuild often" and "I use the scripting feature of the PM" checkboxes are not correlated (-0.06). I find this strange and cannot explain. The deviation rates from both LFS and BLFS are not correlated to the editor status. Thus, we can say that the community is not split. It is surprising that a lot of users (among both editors and non-editors) will accept a totally broken package manager that overwrites their customizations of the configuration files. This indicates that they probably didn't try to implement package management themselves (or didn't even package stuff for regular distributions) and thus didn't meet the problem. Existence of such users that can't tell a key property of a good PM will surelly negatively affect the quality of the resulting pages in LFS. I.e., again, we have to learn more about package management before attempting to write about it. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Poll is closed
I wrote: > Please reply to this message (please, limit this to the lfs-dev list > only) and mark with "X" the items that apply. Any replies after this will be ignored. Thanks for your input. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management - technical comparisons
package into packagename.install files (the other alternative is to call dh_install or dh_move with the exlicit arguments what to move to a different package). List configuration files. > - what it likely is not able to do for its users It can do everything with the right optional dependencies installed. > - how well it can deal with matters such as conflict resolution and > dependency handling Same as RPM or better. The "optional runtime dependency" stuff (aka recommendations and suggestions) is not likely to be used by LFSers, because it is useless without a repository. Neither RPM nor DPKG have "optional build-time dependencies", and Debian has a release goal of 100% reproducible builds (for the purposes of securty rebuilds) even when wagonloads of potentially useful packages are installed (so that, e.g., an upload by the security team never switches the dependency from expat to libxml2 if a package can use either of them). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS-6.3 status
2008/3/5, Jeremy Henty <[EMAIL PROTECTED]>: > Dillo Classic certainly works well enough to be useful. Is that > enough? No, please go to http://www.lenta.ru/ (a Russian news site) and see wrong characters (if you don't apply the i18n patch). Ag decided that Links compiled without graphics is useless with such sites (even though in legacy non-UTF-8 locales it works--so Dillo is worse than Links), and the book must be self-consistent. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Package Management - technical comparisons
bash syntax in order to
understand the existing spec files (i.e., know how various %{things}
expand)
- Some stock post-processing scripts contain small (i.e., ignorable)
bugs, but I'll raise the known ones upstream.
- The %configure macro interferes (ore, more correctly, duplicates or
overlaps in functionality) with config.site files, but the
autogenerated spec files are not expected to use this macro, so this
is likely to be a non-issue. However, in this case, setting the
default CFLAGS from RPM macros, as documented, will stop working.
- Binary database
- Embeds many third-party projects like Berkeley DB and the Lua
scripting language.
> - why it's better than other candidates
Because Dan Nicholson has a lot of working spec files and thus the
initial "proof of concept" implementation of an LFS-like system with
the RPM package manager already exists.
> - why it's worse than other candidates
Because of the "%configure" vs "./configure --prefix=/usr" issue.
"%configue" means that the paths will be different as compared to the
non-PM version of LFS, and that config.site files won't work.
"./configure" allows to achieve exactly the same result as the current
LFS, at the cost that the %{optflags} no longer sets the default
CFLAGS, contrary to its documentation.
> - what it takes to integrate it in the LFS book
>* not looking for installation instructions. Just explain the impact
DESTDIR, post-installation steps, list of files whose MD5 sum can
change during the normal operation of package (e.g., for glibc, that's
/usr/lib/locale/locale-archive, because glibc provides the "localedef"
command that modifies this file), list of files that should not be
replaced on upgrades (aka configuration files). All of that goes into
spec files, that also specify how to split the package into the main
and -devel parts. This split is necessary with any binary package
manager that doesn't allow two packages to have the same file, in
order to allow gradually upgrading, say, from libreadline.so.5 to the
future libreadline.so.6 without removing everything.
> and changes that will be required for successful use
> - what it likely is not able to do for its users
It doesn't track which packages were explicitly asked for, and which
were installed only as dependencies. IOW even if someone writes a full
tree of build-time dependencies, RPM won't be able to use it in order
to automatically "install xfce" from source.
> - how well it can deal with matters such as conflict resolution and
> dependency handling
It doesn't allow two packages to have the same file. It tracks
dependencies of binary packages, and doesn't allow breaking them by
default. Moreover, often it finds the library dependencies
automatically. Source build-time dependencies have to be specified
manually.
--
Alexander E. Patrakov
--
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
2008/3/5, DJ Lucas <[EMAIL PROTECTED]>: > Alexander E. Patrakov wrote: > > > > So, please express your ideas in the following areas: > > > > > First and foremost, SLOW DOWN How about some baby steps instead of > leaps and bounds. The recent threads are going nowhere because we have > 20 individual topics crammed into one thread. There have been 4 now > that have all resulted in no clear direction. DESTDIR sounds like a > logical first step. I've excluded the rest of your message as it > doesn't seem useful just yet. Again, knowing nothing about the various > PMs, I've made some assumptions. Can someone confirm or deny those for me? Let's try. It is good that you don't forget that there are people that think that DESTDIR is a wrong approach, and also note the fact that most non-DESTDIR approaches can be applied to the corrent book without the need for such extensive modifications. > For RPM, I've made the assumption that you take a spec file and a source > tarball, and create an installable binary package, then install that > package. I don't suppose that the second step is automated only by rpm > itself, so the installation portion is different. I expect that, but > are the configure, make, make install commands the same for all DESTDIR > methods? Looking at different PMs, how much will be in common WRT to > CMMI? I'd say, 90% if you avoid RPM-specific idioms. You can look at my spec files in the "RPM: proof of concept" mail and see yourself. > On DESTDIR installs, DESTDIR can be an exported environment variable and > the target cleaned out after every installation is completed. This may interfere with the way Makefiles get environment variables. > If that > is possible, then the no PM group, the install-watch group, and the > timestamp group are completeley unaffected by the changes for a mass > majority of the packages as DESTDIR="". I'm looking for simplicity in > common instructions first. Again, take some baby steps, one thing at a > time. Lets try not make things so complicated just yet. If the above > handles getting DESTDIR into the current book, with such simplicity, > then get that part done first. Explicitly set DESTDIR="" for the first > cut and the book still works as is. If not, then if you would be so > kind as to explain away my assumptions, it'd be much appreciated by me > for certain, but would help in educating the rest of the readers as well > WRT RPM anyway. Also, the same goes for other DESTDIR PMs that anybody > would care to explain. Yes, DIY uses this fact. They require the reader to set $PM_DEST to an empty (no PM) or non-empty (PM) value, and run things like "make DESTDIR=$PM_DEST install". However, for some packages, this may need a command like "mkdir -p $PM_DEST/etc" before this. Also note that post-installation steps are required in all DESTDIR-based methods (e.g., to register info documentation correctly), and that all configuration files have to be marked as such in order to avoid their overwriting. "DESTDIR alone" is just broken, so a baby step leads to a hole in the ground. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
