2 New LFS Editors
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. -- 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]
CC'ing to lfs-dev, if I've remembered to change to a subscribed address. On Tue, Sep 30, 2008 at 04:54:33PM +0100, Colin Watson wrote: On Tue, Sep 30, 2008 at 03:48:50PM +0100, Ken Moffat wrote: On Tue, Sep 30, 2008 at 12:27:09PM +0100, Colin Watson wrote: I've been looking into the adoption of man-db in various distributions lately, and ran into your post archived at http://linuxfromscratch.org/pipermail/lfs-dev/2008-September/061632.html. I'm not subscribed to lfs-dev so can't easily reply directly there, but I wanted to reply to one point as I thought it was a bit odd: Long-term, UTF-8 is the only sensible solution for text encoding, in the same way that a terminal on an X desktop is the only way to read some languages. In my view, packages such as man-db are prolonging the pain of the transition by encouraging people to use legacy encodings. But, for me as an English speaker the pain is minimal. Others may conclude that the pain of conversion to UTF-8 should be deferred. Modern versions of man-db default to expecting UTF-8 for manual page source (although if they realise that the page is actually encoded in a legacy encoding then they'll automatically fall back to that), and will generate whatever is appropriate for the user's locale. I like the sound of that. It's not the way we've been doing things since we switched to man-db in LFS, and we have text (perhaps carried forward in error) saying that man-db can't display UTF-8. See http://www.linuxfromscratch.org/lfs/view/development/chapter06/man-db.html part 6.45.2 in the middle of the page. Ah, that definitely used to be true but is false as of man-db 2.5.0 (though you should really use at least 2.5.1 - 2.5.0 didn't get the encoding fallback logic quite right). Since I have the opportunity (and thanks, I hadn't seen that page before), it seems worth going through the rest of that page. If I should file these as bugs instead, let me know, or feel free to forward this to lfs-dev, or whatever. I suppose one of _us_ ought to file it, once this hits the list archives. The first change is a sed substitution to delete the “/usr/man” and “/usr/local/man” lines in the man_db.conf file to prevent redundant results when using programs such as whatis: Do you make /usr/man and /usr/local/man symlinks? If so, I could detect that and skip them automatically. The second change accounts for programs that Man-DB should be able to find at runtime, but that haven't been installed yet: I made configure options available for these in 2.5.0, so you could use '--with-browser=lynx --with-col=col --with-vgrind=vgrind --with-grap=grap' instead. Prepare Man-DB for compilation: I think I already suggested this to somebody else at LFS, but I'd recommend that you use --with-db=gdbm rather than the default of Berkeley DB (which is something of an awkward beast, and overkill for man-db). This will be the default in man-db 2.5.3. And, yes, I think you can get rid of the convert-mans business entirely. With the exception of a few hopelessly misencoded pages that are really lost causes, man-db can pretty much cope with any of the obvious candidates for encoding pages in each language now. I noticed a comment in there about Norwegian not working, and have fixed it for man-db 2.5.3. In the distributions I'm most directly involved with, namely Debian and Ubuntu, everything is set up for UTF-8 output by default, and we've arranged for the packaging tools to automatically convert pages to UTF-8 on installation with the aid of some helper tools I ship with man-db; while this latter item has only been running for a few months, it won't be long until we'll be running with UTF-8 across the board. As soon as groff upstream finishes off Unicode support then we'll use that and the whole pipeline will be UTF-8, but for the meantime we recode back and forward behind the scenes and very few people have to notice or care. I'll also take a look at this part, it sounds good. I hope you're not holding your breath for a UTF-8-capable version of groff ;-) Oh, certainly not; I've put a lot of effort into not holding my breath for that! That said, I'd be entirely happy to make man-db able to use groff-utf8 as an option if that's what you guys would prefer. I haven't yet looked at what you are doing in 2.5.2, or what versions of groff you are using in ubuntu and debian, but I'm fairly sure most LFS users won't want to use groff-utf8 if it isn't needed. It's only a temporary hack until groff is fixed. Is there some misunderstanding here about what man-db is doing? If so, I'd be happy to explain. Thanks for the offer, I might take you up on it in a few weeks. NB my estimates for how long things will take me are always way out, so that might be next year! Depends on how long I spend beating my head
Re: 2 New LFS Editors
On Tue, Sep 30, 2008 at 09:39:16AM -0600, Matthew Burgess 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. Pleased to see you guys have accepted this. I'm not sure that offering you a welcome is appropriate, you've both been here longer than I have, but for sure you have my support. ĸ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
Re: 2 New LFS Editors
Ken Moffat wrote: On Tue, Sep 30, 2008 at 09:39:16AM -0600, Matthew Burgess 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. Pleased to see you guys have accepted this. I'm not sure that offering you a welcome is appropriate, you've both been here longer than I have, but for sure you have my support. ĸen TY. I'm crawling through my first manual build in a long time right now...commits to begin soon. -- 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
Ken Moffat wrote: Pleased to see you guys have accepted this. I'm not sure that offering you a welcome is appropriate, you've both been here longer than I have, but for sure you have my support. 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. :-) But thanks anyway, Ken. :-) -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2 New LFS Editors
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. :-) -- Randy -- 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]
Ken Moffat wrote: On Tue, Sep 30, 2008 at 04:54:33PM +0100, Colin Watson wrote: On Tue, Sep 30, 2008 at 03:48:50PM +0100, Ken Moffat wrote: On Tue, Sep 30, 2008 at 12:27:09PM +0100, Colin Watson wrote: Modern versions of man-db default to expecting UTF-8 for manual page source (although if they realise that the page is actually encoded in a legacy encoding then they'll automatically fall back to that), and will generate whatever is appropriate for the user's locale. I like the sound of that. It's not the way we've been doing things since we switched to man-db in LFS, and we have text (perhaps carried forward in error) saying that man-db can't display UTF-8. See http://www.linuxfromscratch.org/lfs/view/development/chapter06/man-db.html part 6.45.2 in the middle of the page. Ah, that definitely used to be true but is false as of man-db 2.5.0 (though you should really use at least 2.5.1 - 2.5.0 didn't get the encoding fallback logic quite right). Since I have the opportunity (and thanks, I hadn't seen that page before), it seems worth going through the rest of that page. If I should file these as bugs instead, let me know, or feel free to forward this to lfs-dev, or whatever. I suppose one of _us_ ought to file it, once this hits the list archives. This CC to lfs-dev is sufficient, but if you or anyone else wants to correct the text, please file away. :-) The first change is a sed substitution to delete the “/usr/man” and “/usr/local/man” lines in the man_db.conf file to prevent redundant results when using programs such as whatis: Do you make /usr/man and /usr/local/man symlinks? If so, I could detect that and skip them automatically. The second change accounts for programs that Man-DB should be able to find at runtime, but that haven't been installed yet: I made configure options available for these in 2.5.0, so you could use '--with-browser=lynx --with-col=col --with-vgrind=vgrind --with-grap=grap' instead. Prepare Man-DB for compilation: I think I already suggested this to somebody else at LFS, but I'd recommend that you use --with-db=gdbm rather than the default of Berkeley DB (which is something of an awkward beast, and overkill for man-db). This will be the default in man-db 2.5.3. 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? And, yes, I think you can get rid of the convert-mans business entirely. With the exception of a few hopelessly misencoded pages that are really lost causes, man-db can pretty much cope with any of the obvious candidates for encoding pages in each language now. This is very nice! I noticed a comment in there about Norwegian not working, and have fixed it for man-db 2.5.3. In the distributions I'm most directly involved with, namely Debian and Ubuntu, everything is set up for UTF-8 output by default, and we've arranged for the packaging tools to automatically convert pages to UTF-8 on installation with the aid of some helper tools I ship with man-db; These will also be very useful in BLFS. while this latter item has only been running for a few months, it won't be long until we'll be running with UTF-8 across the board. As soon as groff upstream finishes off Unicode support then we'll use that and the whole pipeline will be UTF-8, but for the meantime we recode back and forward behind the scenes and very few people have to notice or care. I'll also take a look at this part, it sounds good. I hope you're not holding your breath for a UTF-8-capable version of groff ;-) Oh, certainly not; I've put a lot of effort into not holding my breath for that! That said, I'd be entirely happy to make man-db able to use groff-utf8 as an option if that's what you guys would prefer. I haven't yet looked at what you are doing in 2.5.2, or what versions of groff you are using in ubuntu and debian, but I'm fairly sure most LFS users won't want to use groff-utf8 if it isn't needed. It's only a temporary hack until groff is fixed. Definitely not. It looks like a sensible, long-term solution will be here soon. If man-db is already doing the leg work for the interim solution, then we have a much larger development team (Debian) to follow for guidance. We'd be much better off without the wrapper for groff. Is there some misunderstanding here about what man-db is doing? If so, I'd be happy to explain. Thanks for the offer, I might take you up on it in a few weeks. NB my estimates for how long things will take me are always way out, so that might be next year! Depends on how long I spend beating my head against the various versions of mozilla on ppc64, plus
Re: 2 New LFS Editors
Matthew Burgess wrote: As those of you who have been following ticket #2205 have already seen, DJ Randy Congrats guys! I wouldn't say I've been monitoring LFS in the past few months, but now and then I'd look around to see what's going on and it's nice to see that there's still some bit of fighting breath in it. :) On a personal level I've been very busy (moving, managing my new company, there's been a lot going on). But things are starting to even up a bit and I'm beginning to get my priorities in place. I have a few cycles to spare for helping, I believe, but I don't want to just jump in anywhere. And I don't really want to work on ideas or concepts that aren't really going to go anywhere or will be stepping on other people's toes. So I guess I'm asking is (while trying to avoid raising a long, tired, pointless discussion about where LFS could and should go): what's our current goal and what needs done? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2 New LFS Editors
Jeremy Huntwork wrote: Matthew Burgess wrote: As those of you who have been following ticket #2205 have already seen, DJ Randy Congrats guys! I wouldn't say I've been monitoring LFS in the past few months, but now and then I'd look around to see what's going on and it's nice to see that there's still some bit of fighting breath in it. :) On a personal level I've been very busy (moving, managing my new company, there's been a lot going on). But things are starting to even up a bit and I'm beginning to get my priorities in place. I have a few cycles to spare for helping, I believe, but I don't want to just jump in anywhere. And I don't really want to work on ideas or concepts that aren't really going to go anywhere or will be stepping on other people's toes. So I guess I'm asking is (while trying to avoid raising a long, tired, pointless discussion about where LFS could and should go): what's our current goal and what needs done? To me, I'd like to see two things. First, an update to the packages. This is relatively straight forward, but of course has a lot of detail. Second, I'd like to see a new page on how we are addressing building LFS as a 64-bit system. Then add a section to each page that needs it any special 64-bit instructions. Then a 6.4 or 7.0 release would be appropriate. After that, we can address package management. In the past there has been a fair amount of discussion about that, but we need to come to a decision on how to address it. Another item of interest is LSB conformance. Again, this would start as a page up front to describe what it is and why one might want to do it. It would be followed up by sections in individual package sections as necessary. Of course a bare LFS system would not be LSB compliant, but would need to be followed up in BLFS to get a complete system. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Helping Out [Was: Re: 2 New LFS Editors]
Bruce Dubbs wrote: To me, I'd like to see two things. First, an update to the packages. This is relatively straight forward, but of course has a lot of detail. I think DJ and Randy are handling that so far? I wouldn't mind lending some fingertips and half a brain here but I've not yet caught up with everything that's been going on in the blanket ticket. Second, I'd like to see a new page on how we are addressing building LFS as a 64-bit system. Then add a section to each page that needs it any special 64-bit instructions. Well most of what is needed to allow 64-bit systems is done already, since the separate branch I made a while ago was aiming for that. The principles and method there should work fine, but the packages are out of date. In fact, most of the current differences between the branch and trunk outside of package versions and related changes are quite small. The one thing I hadn't done yet was adjust the boot-loader section because grub won't work with 64-bit. So what do you still require in 'a new page'? Then a 6.4 or 7.0 release would be appropriate. After that, we can address package management. In the past there has been a fair amount of discussion about that, but we need to come to a decision on how to address it. Yeah, and that's part of the discussion I was trying to avoid again just now. I rather doubt we'd be able to reach a consensus just yet. Perhaps after the next release as you say. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Helping Out [Was: Re: 2 New LFS Editors]
Jeremy Huntwork wrote: Bruce Dubbs wrote: To me, I'd like to see two things. First, an update to the packages. This is relatively straight forward, but of course has a lot of detail. I think DJ and Randy are handling that so far? I wouldn't mind lending some fingertips and half a brain here but I've not yet caught up with everything that's been going on in the blanket ticket. I've committed to testing. I'll also make typo/minor changes if appropriate. Second, I'd like to see a new page on how we are addressing building LFS as a 64-bit system. Then add a section to each page that needs it any special 64-bit instructions. Well most of what is needed to allow 64-bit systems is done already, since the separate branch I made a while ago was aiming for that. The principles and method there should work fine, but the packages are out of date. In fact, most of the current differences between the branch and trunk outside of package versions and related changes are quite small. The one thing I hadn't done yet was adjust the boot-loader section because grub won't work with 64-bit. Yes, I know that. It was the motivation for doing the 64-bit instances first. So what do you still require in 'a new page'? The new page would introduce the issues and provide information for a user to use to decide if they want a 32-bit system or a 64-bit system. Yes, I think that page is necessary. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Helping Out [Was: Re: 2 New LFS Editors]
Bruce Dubbs wrote: The new page would introduce the issues and provide information for a user to use to decide if they want a 32-bit system or a 64-bit system. Yes, I think that page is necessary. Hmmm. Alright. That will require some thought and a bit of research, I think. I suppose I can take a crack at it. Don't expect anything right away, but I'll start gearing up for this. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Helping Out [Was: Re: 2 New LFS Editors]
Jeremy Huntwork wrote:
Bruce Dubbs wrote:
After that, we can address package management. In the past there has been a
fair amount of discussion about that, but we need to come to a decision on
how
to address it.
Yeah, and that's part of the discussion I was trying to avoid again just
now. I rather doubt we'd be able to reach a consensus just yet. Perhaps
after the next release as you say.
Probably after the next release, but I was driving down the road a few
minutes ago, and I had a very simple idea on that. It involves a little
scripting, added to the book for each supported PM. supported PM ==
A developer is interested in maintaining it It would also require a
repository of scripts/specs/conf files or whatever. There could even be
a common area for pre/post install scripts that are common to DESTDIR
style PMs. The book commands would simply be prefixed with the
packaging script (which starts a shell with the proper environment
setup) and then postfixed with an exit command. Something like this:
--
PACKAGE=GLibC VERSION=2.8-20080930 /tools/bin/lfsinst
--
./configure {...}
--
make
--
make install
--
exit 0
---
The exit command breaks out of the shell that lfsinst provided us with,
and then continues on to do the packaging and installation of the new
package (or executes post-install commands for simple logging or tgz types).
Is something like that possible with say RPM or DEB packages? Simple
tar.gz packages and loggers I already know that it is very possible
for...I'm doing something similar to capture the output of the commands
in my homegrown lpackage ATM.
-- 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: Helping Out [Was: Re: 2 New LFS Editors]
DJ Lucas wrote: Probably after the next release, but I was driving down the road a few minutes ago, and I had a very simple idea on that. It involves a little scripting, added to the book for each supported PM. supported PM == A developer is interested in maintaining it It would also require a repository of scripts/specs/conf files or whatever. There could even be This is a good deal along the lines I was thinking previously. I think it's the way to go. Always, whatever is offered needs to be properly supported by at least one active dev. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
