Kevin P. Fleming | 1 Jun 2004 17:09
Picon
Favicon

Re: [Fwd: [RFC] - textdump element]

James Robertson wrote:

> I can't remember if I brought it up before or not (and don't feel like
> digging in the archives).  For an update to the ALFS DTD, what do you
> think of adding support for appending data in the middle of a file or at
> some point.  This is good for keeping configuration files in /etc
> updated via script, but also allow you to keep the #Begin and #End
> lines.  I for one, like those.

I'm not opposed to the idea, but I can't imagine a syntax that would 
work. I've already suggested enhancing search_replace to handle regex 
substitution (probably using PCRE), so that may be able to do what you want.

If you can come up with a syntax that's fairly easy to understand and 
document, I'll certainly think about implementing it.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Frans Verstegen | 1 Jun 2004 18:26
Picon

Re: ALFS DTD Syntax Doc v3.1

James Robertson wrote:
> OK, If you can't tell by the spam this evening, I went hog wild on the 
> doc.  I think it is done.  I need lots more eyes than mine to go over it 
> with a fine toothed comb to make sure it looks good and is accurate.
> 
> Here is the link to the latest and greatest.  You can also get a bz2 
> from the root of my home directory.
> 
> http://www.linuxfromscratch.org/~jwrober/ALFS-SYNTAX-DOC/
> 
> Things I am most concerned with:
> 
> * Typos and spelling mistakes
> * Grammar
> * Consistency with my uses of "see" and "refer to" and other such verbiage.
> * Missing cross-document links to elements.
> * examples - are they good and correct - Thomas, Kevin please help here.
> * All the DTD elements are defined correctly for v3.1.
> 
> Bruce - If you have the time, I would love for you to do a quick QA as 
> well.
> 
> Bugzilla stuff if you see it.
> 
> Thanks
> James
>
Hello,

The example for "stageinfo" has a wrong environment syntax:
(Continue reading)

Kevin P. Fleming | 1 Jun 2004 18:41
Picon
Favicon

Re: ALFS DTD Syntax Doc v3.1

Frans Verstegen wrote:

> I think the environment should be coded as:
>   <environment name="PATH">/bin:/sbin</environment>

Nope, that's wrong too. {environment} is a container for {variable} 
elements.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Kevin P. Fleming | 1 Jun 2004 18:42
Picon
Favicon

Re: ALFS DTD Syntax Doc v3.1

James Robertson wrote:

> Here is the link to the latest and greatest.  You can also get a bz2 
> from the root of my home directory.
> 
> http://www.linuxfromscratch.org/~jwrober/ALFS-SYNTAX-DOC/
> 
> Things I am most concerned with:
> 
> * Typos and spelling mistakes
> * Grammar
> * Consistency with my uses of "see" and "refer to" and other such verbiage.
> * Missing cross-document links to elements.
> * examples - are they good and correct - Thomas, Kevin please help here.
> * All the DTD elements are defined correctly for v3.1.

I have taken a quick look, and there are quite a few wording and grammar 
changes I would suggest, but I don't have time to document them all at 
the moment :-( I'm hoping someone else will jump in and do that, but if 
not I will try to get to it by this weekend.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

James Robertson | 1 Jun 2004 20:56
Picon
Favicon

Re: ALFS DTD Syntax Doc v3.1

Kevin P. Fleming wrote:
> 
> I have taken a quick look, and there are quite a few wording and grammar 
> changes I would suggest, but I don't have time to document them all at 
> the moment :-( I'm hoping someone else will jump in and do that, but if 
> not I will try to get to it by this weekend.

I am not surprised at the least.  I may print out another copy and go 
after it with a red pen.  Any help would be appreciated.  Maybe others 
can help - Richard you up for it?

James

-- 
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

James Robertson | 1 Jun 2004 21:03
Picon
Favicon

Re: [Fwd: [RFC] - textdump element]

Kevin P. Fleming wrote:

> James Robertson wrote:
> 
>> I can't remember if I brought it up before or not (and don't feel like
>> digging in the archives).  For an update to the ALFS DTD, what do you
>> think of adding support for appending data in the middle of a file or at
>> some point.  This is good for keeping configuration files in /etc
>> updated via script, but also allow you to keep the #Begin and #End
>> lines.  I for one, like those.
> 
> 
> I'm not opposed to the idea, but I can't imagine a syntax that would 
> work. I've already suggested enhancing search_replace to handle regex 
> substitution (probably using PCRE), so that may be able to do what you 
> want.
> 
> If you can come up with a syntax that's fairly easy to understand and 
> document, I'll certainly think about implementing it.

How about adding a mode attribute to search_replace like what 
environment has - that allows two options replace or prepend?  Replace 
would act like a simple sed command.  Prepend would do what I want it to 
do.  The new DTD would look like this:

!ELEMENT search_replace (file, find, replace)
!ATTLIST search_replace
           base           CDATA #IMPLIED
           mode           (replace | prepend) "replace"

(Continue reading)

Unknown | 2 Jun 2004 06:14

Segfault with xincludes again

Just cvs co'd nALFS and got a segfault when trying to parse a profile with xincludes.

The profile is pretty simple and looks sound so I presume it could be the latest changes you just committed
Kevin. A strace doesn't show much apart from a SIGSEGV being generated. This is when the profile is
executed not when its first parsed which was the problem before.

This error happens everytime so I can reproduce if if needed. 

I've attached the output of strace, the top level profile (kde.xml) and the offending profile (libogg.xml)

	-- Jamie
execve("/usr/bin/nALFS", ["nALFS", "-s", "kde.xml"], [/* 18 vars */]) = 0
brk(0)                                  = 0x8067000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17910, ...}) = 0
old_mmap(NULL, 17910, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)                                = 0
open("/usr/lib/libxml2.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\337\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=2569644, ...}) = 0
old_mmap(NULL, 1018420, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000
old_mmap(0x40104000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe6000) = 0x40104000
old_mmap(0x4010d000, 35380, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4010d000
close(3)                                = 0
open("/lib/libpthread.so.0", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300I\0"..., 512) = 512
(Continue reading)

Archaic | 1 Jun 2004 22:30
Picon
Favicon

Re: [RFC] Addition to LFS profiles (nALFS related)

On Mon, May 24, 2004 at 08:45:20PM -0700, Kevin P. Fleming wrote:
> 
> I'm thinking that maybe the last step of building nALFS in the profile 
> should be copying doc/nALFSrc to $LFS/etc/nALFSrc, so that nALFS will be 
> usable once the user reboots into their new system.

Should it be in /etc or in /root? Seems that since root permission is 
needed anyway, it would be best to leave this as a private conf file.

-- 
Archaic

The IRS has become morally corrupted by the enormous power which we in
Congress have unwisely entrusted to it. Too often it acts like a Gestapo
preying upon defenseless citizens.

- Senator Edward V. Long

--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Kevin P. Fleming | 1 Jun 2004 22:51
Picon
Favicon

Re: [RFC] Addition to LFS profiles (nALFS related)

Archaic wrote:

> Should it be in /etc or in /root? Seems that since root permission is 
> needed anyway, it would be best to leave this as a private conf file.

Well, actually root permission is not needed to run nALFS, it's only 
needed if the profile you are using actually requires it. I know most 
people are using nALFS to run LFS profiles that require root permission, 
but nALFS itself does not care and can be used for other non-root tasks.
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Archaic | 2 Jun 2004 00:20
Picon
Favicon

mount --bind

Don't know if this is done in any of the other LFS profiles, but I added
in the missing umount that creatingtoolsdir.xml references. Also added
umounting of devpts and proc.

Also, I modified the addinguser.xml to replace the recursive chown of
/tools to chowning /tools and &build_dir explicitly. The reasoning for
not chowning &package_dir are:

1) if &packages_dir is bind mounted, you will be modifying files outside
   of the lfs partition.
2) if &packages_dir is bind mounted from a CD, the build dies.
3) since umask is 022 (per the runit script) it won't matter who owns
   the files since the lfs user will only ever need read access.

Attached is the patch

HTH someone.

--

-- 
Archaic

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."

- Brian Kernighan

diff -Naur nALFS-1.2.2.old/profile/LFS-5.0-3/LFS-5.0.xml nALFS-1.2.2/profile/LFS-5.0-3/LFS-5.0.xml
(Continue reading)


Gmane