Re: LFS 64bit - thoughts
DJ Lucas wrote: > Bruce, Randy, ya'll got anything to add? No, not really. On a LUG list I read we just had a long discussion about problems on guy had getting his wireless to work with ndis wrapper. He was using Ubuntu64 and never could get it to work. When he went to Ubuntu32, it was fine. These are the types of problems we run into with 64-bit systems. The think is, he had no idea why he wanted 64-bits. It has to be better than 32-bits, right. I've seen similar problems with video drivers. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New experimental book
DJ Lucas wrote: > Jean-Philippe MENGUAL wrote: > >> Hi, >> >> I'd like to know the difference between the contents of trunk/BOOK and the >> new experimental book. Is new experimental more unstable? Where is it >> downloadable? To see this changes, it'll be necessary to wait for updates in >> trunk/BOOK? So far I only saw stylesheets which changed. >> >> Thanks for your explanations. >> >> Sincerely, JPM >> >> > "New experimental book" was my own copy of the book with all the latest > (and greatest?) packages. Link is in ticket #2250, err, 2205. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 64bit - thoughts
Nathan Coulson wrote:
> I noticed one person mentioning 64bit LFS on a previous post. It made
> me wonder how LFS may address this in the future.
>
Actually, it's been mentioned a few times in the past week.
> On my own, I took the multilib plunge about 6 months ago. (sortof a
> hodgepodge of LFS's buildsystem, and a few occassional CLFS patch's).
> I had the following ideals in mind in the construction of my own
> system. (I dont know how close these are to LFS values)
>
>
I can't really add a lot here as I haven't tried it yet. I think
pure-64 is ideal, but from what little I've looked into it, that is just
not possible.yet, not to mention that it breaks the LSB goal.
> -I wanted a pure 64bit os, or at least a system where 32bit could be
> added on later. (To this end, I built a multilib gcc/glibc/binutils,
> but no other 32bit libraries unless I specifically had a program link
> against them)
>
> -I dont like the idea that if I was to install a 32bit version of a
> package, that it would overwrite the 64bit binaries. (goes against my
> first idea, where I wanted 32bit as a addon). [although this one has
> caused a few headaches]. I know one can install the 64bit version
> after, but it just feels wrong.
>
From what I've seen of it, I guess there is no concept of
{,/usr}/{,s}bin64 or /usr/include64 like there is for the lib dirs (or
the alternate). I mean a total separation of the system, side by side
would be ideal IMO. Unfortunately I am just not able to make any useful
comments on the rest of your post yet. Best I can do is point you to
Jeremy's book. I believe this is the correct link:
http://www.linuxfromscratch.org/~jhuntwork/lfs-JH/
It likely will provide a baseline for which LFS follows (or even much
taken verbatim). At a casual glance, I notice the use of 'uname -m' a
few times, which probably means the building arch only. Jeremy, care to
jump in here with where you were headed? I know that LFS as a whole
would certainly benefit from anything that ya'll can add. I still will
not be able to toy with 64bit for a few more weeks.
Bruce, Randy, ya'll got anything to add?
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: New experimental book
Jean-Philippe MENGUAL wrote: > Hi, > > I'd like to know the difference between the contents of trunk/BOOK and the > new experimental book. Is new experimental more unstable? Where is it > downloadable? To see this changes, it'll be necessary to wait for updates in > trunk/BOOK? So far I only saw stylesheets which changed. > > Thanks for your explanations. > > Sincerely, JPM > "New experimental book" was my own copy of the book with all the latest (and greatest?) packages. Link is in ticket #2250, which you will also need to follow. Trunk will be updated within a couple of days. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
New experimental book
Hi, I'd like to know the difference between the contents of trunk/BOOK and the new experimental book. Is new experimental more unstable? Where is it downloadable? To see this changes, it'll be necessary to wait for updates in trunk/BOOK? So far I only saw stylesheets which changed. Thanks for your explanations. Sincerely, JPM -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book [warning: lots of UTF-8 in this]
Colin Watson wrote:
> On Tue, Sep 30, 2008 at 09:03:00PM -0500, DJ Lucas wrote:
>
>> Other packages in the base LFS utilize BDB. They may or may not work
>> with GDBM so I'll be looking into that as soon as we get updated to
>> reasonable revisions of all installed 'base' software. My question,
>> however, will man-db-2.5.3 allow continued used of BDB in the near future?
>>
> Yes (--with-db=db, or --with-db=dbN for N=1-4), although I can't promise
> to test it very often.
> We use the notorious Debian-patched groff 1.18.1.1 and configure man-db
> with --enable-mb-groff. I'd rather that not be the only possible
> alternative, of course.
>
>
>> My real concern is the version of groff being used. I did not see
>> mention of a current groff version which was *my* original concern. I
>> want to use what works, but I also want to stay as close to upstream as
>> possible for all packages because we (LFS) do not have the development
>> staff that distributions have. Keep in mind that LFS is an educational
>> product, not a 'distribution', though many use it as their
>> 'distribution' of choice. Utilizing Debian's work in this area was
>> great (and will continue to be I think). It allowed Alexander to
>> provide a working setup for almost all cases, and explain in detail the
>> future issues (though the current text, like much of the book ATM, is
>> now out of date).
>>
>
> For staying as close to groff upstream as possible, you probably want to
> use the preconv preprocessor included in CVS groff. That eliminates the
> need for the Debian multibyte patch for most languages. Unfortunately
> there has been no new upstream release of groff since that work was
> done.
>
> The remaining problem is that nobody's yet finished the work on
> character classes in groff, which mean that certain kinds of specialised
> typography don't work: in particular the line-breaking algorithm
> required for Japanese text ("kinsoku shori") isn't implemented. This is
> the reason we're still sticking with the multibyte patch in Debian for
> now, since I want to avoid introducing regressions. I think everything
> other than CJK should work with preconv, although feedback from people
> actually regularly using it wouldn't hurt.
>
>
Thanks for the detailed response Colin. For the immediate future, LFS
will have to stick with your known working method. Maybe later we can
look into backports of groff-cvs.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: 2 New LFS Editors
On Tue, Sep 30, 2008 at 09:02:45PM -0500, Randy McMurchy wrote: > Randy McMurchy wrote: > > Actually, just for the record, I'm a newbie in LFS compared > > to Ken. He's overestimating my time here. I remember my first > > post to an LFS list and was drilled my an ex-member (who I > > won't name) for "which list", when he thought that my post > > didn't belong in LFS-Dev. :-) > > I should have mentioned (the reason I posted...sigh...) > > Ken responded to that very first post in a positive manner > indicating that the post really wasn't off-topic for the > -dev list. > > Hence my saying I'm the newbie compared to Ken. :-) > Thanks. I suppose in my reply yesterday I was confusing _this_ list with lfs-book, where I remember you giving me advice and helpful comments when I became an editor. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 64bit - thoughts
I noticed one person mentioning 64bit LFS on a previous post. It made me wonder how LFS may address this in the future. On my own, I took the multilib plunge about 6 months ago. (sortof a hodgepodge of LFS's buildsystem, and a few occassional CLFS patch's). I had the following ideals in mind in the construction of my own system. (I dont know how close these are to LFS values) -I wanted a pure 64bit os, or at least a system where 32bit could be added on later. (To this end, I built a multilib gcc/glibc/binutils, but no other 32bit libraries unless I specifically had a program link against them) -I dont like the idea that if I was to install a 32bit version of a package, that it would overwrite the 64bit binaries. (goes against my first idea, where I wanted 32bit as a addon). [although this one has caused a few headaches]. I know one can install the 64bit version after, but it just feels wrong. -I like the concept of building the simplest system first, and giving options later in BLFS. (such as the 32bit environment). -I prefer to use standards (if appliable) to find the location of 32/64bit libraries. CC=gcc -m32 is smart enough to find /usr/lib, while gcc can see /usr/lib64. I also found that overriding PKG_CONFIG_PATH to /usr/lib/pkgconfig or /usr/lib64/pkgconfig is a great way of helping a config script find it's dependencies. -CLFS/BCLFS has done alot of work to make 32/64bit buildsystems work relatively seemless, but I do not like the concept of the multiarch_wrapper they made. (Saying that, I dont know of a better solution). Most packages seem to use pkg-config either in conjuction, or instead of programs in /usr/bin that tell you where to link against. That is not the case for all programs though. note: more details on the multiarch wrapper can be found at http://cross-lfs.org/view/svn/x86_64/final-system/multiarch_wrapper.html. -- Nathan Coulson (conathan) -- Location: Alberta, Canada Timezone: MST (-7) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2 New LFS Editors
On Tue, Sep 30, 2008 at 9:39 AM, Matthew Burgess <[EMAIL PROTECTED]> wrote: > Hi all, > > As those of you who have been following ticket #2205 have already seen, DJ & > Randy have been doing stirling work in getting some much needed life injected > back into the LFS book. Although they've had commit privs to the LFS repo > for a while, out of what I can only assume is down to sheer laziness, they've > never made a single commit to the LFS book :-) > > In order to ease the merging of their work, they have both agreed to become > LFS book editors. As such, please offer them the usual welcome and support > for their fine efforts! Welcome on board guys, and thanks again! > > Kind regards, > > Matt. > > PS: I'm still monitoring lfs-dev & lfs-book, but am still unable to make any > worthwhile contributions at present due to ongoing 'real-life' stuff. shame, how that always seems to get in the way... I miss the old bootscript days. I thought DJ did a lot of bootscript commits, technically it's in the LFS SVN (: Congratulation DJ and Randy -- Nathan Coulson (conathan) -- Location: Alberta, Canada Timezone: MST (-7) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
