> There was a recent thread about moving away from grub-mkconfig (which
> is what we did).
>
> http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2011-June/064836.html
>
> --
> Nathan Coulson (conathan)
Apologies, I have been tying to catch up on a whole swathe of unread emails
across a num
On 21 June 2011 11:17, Bruce Dubbs wrote:
> I have updated the book for grub-1.99. I rewrote the section
>
> http://www.linuxfromscratch.org/lfs/view/development/chapter08/grub.html
>
> with fairly extensive changes. I'd appreciate feedback. I'm leaving
> the ticket open for now.
>
> -- Bruce
> In the meantime, I've compiled and formatted my build notes, which are
> augmented with contributions from Bryan Kadzban and
> Max Mann (thanks!). I posted them to my Linuxquestions.org blog. It's
> about 3,700 words, so I had to split the notes into three blog posts:
Hey Drew,
one thing I foun
On 5 August 2010 15:38, Bruce Dubbs wrote:
> Not that it makes any difference to this discussion, but I prefer to use
> /usr/src/(pkgname)/ for source tarballs. I sometimes build there and
> sometimes in /tmp
Some of "my rules for my distro":
I refine that slightly and go with
/usr/src/lfs/us
On 3 August 2010 12:50, Timothy Rice wrote:
> > What might be a way forwards here, assuming you want to keep the old files
> > around, would be to change the group-name for files that become orphaned
> > through a package upgrade to have a versioned group name.
>
> That would get on my nerves. It
On 2 August 2010 10:29, Timothy Rice wrote:
> --- Idea #2 ---
>
> The original hint does not provide much guidance for what group name to
> assign to each package. I think it is good practice, where possible, to
> make the user name equal to "-".
>
> For example, when inst
On 1 August 2010 09:12, Bruce Dubbs wrote:
> BTW, I once (IIRC around 2004) made a suggestion to scan the filesystem
> after each package and store information about each package's files in a
> DB. That kinda begs the question about how you get a db installed for
> use. We really don't want to
On 27 July 2010 16:01, Jeremy Huntwork wrote:
> It's interesting what logs will show.
>
> For instance, the access logs for community.linuxfromscratch.org show 117
> unique IP addresses viewing the site yesterday, and 76 unique IPs today.
> Combine the two lists and there are a total of 167 uniqu
> > The suggestion above is that gettext only needs it for Glade support.
>
> That's true. So far, only Glade support in gettext requires an XML parser.
I think that's the key for me. It seems as though it is only Glade-related
input to gettext which requires XML parsing and not anything from oth
On 24 May 2010 06:32, Matthew Burgess wrote:
> Hi all,
>
> On a recent rebuild of LFS-svn I attempted an upgrade to
> Gettext-0.18. That resulted in one of the xgettext tests
> failing because there is an assumption that xgettext will
> support Glade files. That support requires Expat to be
> pr
On 2 February 2010 20:15, Greg Schafer wrote:
> On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote:
>
>> What's your recommendation then? Pass '-j1' on the command line for all
>> 'make install' invocations?
>
> That's probably overkill. All I know is I've previously been burnt by
> both GC
> This is a old / long standing point that folks bring up now and again.
> Since /tools is very temporary, the book has not historically worried
> about the documentation that gets installed by the temp tools.
Indeed!
The last time I built an LFS system from scratch (bit tautological
that!), I'd
>> /lfs/patch-2.5.9/patch.c:1327: warning: the use of `mktemp' is
>> dangerous, better use `mkstemp'
>
> If you look at the code, there is a comment:
>
> /* It is OK to use mktemp here, since the rest of the code always ...
Thanks for pointing that out but that was not what I was posting about,
bu
LFS 6.5
5.31. Stripping
At this point LFS says
To save nearly 20 MB more, remove the documentation:
rm -rf /tools/{info,man}
however on my build, there seem to be close to another 10MB below these two
directories that could also go ?
8.7M/tools/share/info
1.1M/tools/share/man
$ ls /t
Hi there,
currently running through a build of LFS-6.5 with a view to
adopting a "username-per-package" Package Management
approach, as is my want every now and again.
Whilst watching the output of the Temporary System build of
patch, I noticed that the build process is hard-coding the path
to an
Apologies for jumping into this thread when you are seemingly a good way along
to "resolving" the PM issue but the question/idea I have is somewhat PM related.
If you are going to hive off the files produced for each package into a
tarball for later deployment, how easy would it be to create packa
>
> Kevin Buckley wrote:
>
> > To my mind, having a full list of of all the users and groups that
> > BLFS users MIGHT require, presented to readers of an LFS book, is akin
> > to going WBLFS - "Way Beyond LFS".
>
> Have you read BLFS? Specifically,
At the risk of being considered as one these
1.) if you've got no idea whats been discussed in these mails - don't
comment, we don't need a "can I have wirless tools" style
posters, in which case I do apologise for butting in amongst those who
aren't:
I notice that Bruce Dubbs wrote abo
18 matches
Mail list logo
