Jeremy Huntwork wrote:
> Digging deeper...
Time test to lfs-dev, 0046 EDT - please ignore
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>> Digging deeper...
>
> Time test to lfs-dev, 0046 EDT - please ignore
This one came through right away. There was a user subscribed to
alfs-discuss and lfs-support that was using an unresolvable domain.
Mailman was attempting to
Jeremy Huntwork wrote:
> Forcibly removing the user from the lists and restarting postfix and
> mailman _seems_ to have fixed the issue. Although why one unresolvable
> domain was causing so much trouble, I'm not sure. I'm looking into it
> further...
Just to reiterate
TheOldFellow wrote:
> Did you see this system for 'autowhitelisting' that works with postgrey?
>
> http://oc-co.org/p2pwl/
I looked at this. Postgrey already does autowhitelisting internally. I'm
not sure which is more effective.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FA
TheOldFellow wrote:
> In that way when a triple (IP,sender,destination) is checked against
> the greylist dbase, the IP is masked first, so all the IPs in a range
> are treated as the same.
This is what is in the default client whitelist for postgrey (the one
that whitelists senders) for google:
On Sat, 14 Apr 2007 12:11:34 +0200, "M.Canales.es" <[EMAIL PROTECTED]> wrote:
> Looks like that issue is here again :-/
I'm busy this morning, but I'll try to look at it later today.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscr
On Fri, 13 Apr 2007 21:19:54 -0500, DJ Lucas <[EMAIL PROTECTED]> wrote:
> Auto whitelist on greylist? Auto permanent whitelist would be bad, I'm
> assuming this is just a retention policy?
The general policy is accept if the MTA appears in the database has having
tried to deliver before. But th
On Sat, 14 Apr 2007 6:51:34 -0600, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> On Sat, 14 Apr 2007 12:11:34 +0200, "M.Canales.es" <[EMAIL PROTECTED]>
> wrote:
>> Looks like that issue is here again :-/
>
> I'm busy this morning, but I'll try
On Sat, 14 Apr 2007 12:37:06 -0600, Jeremy Huntwork <[EMAIL PROTECTED]> wrot
> OK. It looks like this might be a recurring problem unless we can find the
> source. When mailman tries to deliver a message to a user at a domain that
> is (at least temporarily) unresolvable, everyt
On Mon, Apr 23, 2007 at 08:46:04AM +0300, Ag. D. Hatzimanikas wrote:
> Maybe it's a flaw in Track, maybe there is already a patch.
Keep in mind that, although it may have appeared that way externally,
the idea to try out greylisting had nothing to do with recent vandalism
of the trac system(s). We
Hello Everyone,
Just a small hello and a request for some info. After a much-needed
break, I have a bit more free time this summer and I'd like to do some
work on the LiveCD. I've scanned through my LFS emails (although there's
about 1700 of them waiting for me, so it might take a while to get
Dan Nicholson wrote:
> Here are some changes I'd like to see go into the bootscript/book before
> the release. Comment welcome.
I suppose this is a little OT, but it's semi-related. Has anyone ever
considered adding chkconfig or a custom equivalent to our bootscripts
package? It would definitely
Randy McMurchy wrote:
> A thorough explanation of the pros and cons (and appropriate URLs
> to the package homepage) of the above suggestion is welcome. It's
> hard to comment when it takes blindly researching the suggestion.
Sure thing. It's been in Fedora/Red Hat for some time, but I guess I
s
Heya,
Posting here instead of creating a ticket because maybe someone knows
off-hand what the deal is here. Currently for coreutils in chapter 6 we
have the command:
chmod +x tests/sort/sort-mb-tests
But after unpacking the source and adding the appropriate patches all I
see is:
tests/sort/s
Chris Staub wrote:
> sort-mb-tests should be added by the i18n patch.
Of course. Should have known I was missing something. Thanks, Chris.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Dan Nicholson wrote:
> I think most of the issues brought up in this thread have been
> addressed. I'd like to see if glibc-2.5.1 will happen, but we can
> certainly just use the latest branch_update patch. The LiveCD is still
> kind of up in the air, but I think most of the big concerns have been
Bryan Kadzban wrote:
> Possibly the only solution would be a separate 64-bit livecd, but that's
> a bunch more work for the maintainers (and may not even be possible for
> them to build, I don't know). :-(
Wow, I'm really not thinking straight these days. Of course you're right
about the 64-bit
Hey All,
Just wanted to announce the first of a new type of LiveCD. It's called
'minimal' but it still has quite a few BLFS-type packages. Mostly it's
just the removal of X and any programs that depend on X and the source
packages. The size is about 210MB. Should be useful for a usb thumb
drive or
On Tue, Jul 17, 2007 at 02:28:31PM -0600, Matthew Burgess wrote:
> So, does anyone here want to wrestle this release into submission?
I'm willing to be a wing-man. :) I'll do what I can to help, but I doubt
I have enough free time to tackle it all alone. A release comittee/group
might be a good id
On Wed, Jul 18, 2007 at 07:45:35AM +0600, Alexander E. Patrakov wrote:
> Note that the documentation on this CD should be ignored - it still mentions
> X window system and doesn't document the new boot options (e.g., "toram").
Blast! I had remembered that and then forgot it again. Well, I'm hopin
On Wed, Jul 18, 2007 at 12:50:45AM +0100, Ken Moffat wrote:
> I was going to say 'yes' to a package freeze (and if glibc-2.5.1
> appears in a timely fashion you can knock me down with the proverbial
> feather!), except that (a) ISTR you weren't very confident about
> linux-2.6.21 (you quoted Dave
On Tue, Jul 17, 2007 at 07:49:20PM -0500, Bruce Dubbs wrote:
> Just as a comparison, there were a total of 126 tickets worked for 6.2
> and there are a total of 157 (5 open) for 6.3.
Well, it seems a good time for a package freeze then, especially after
Matt brought us up to speed with several pac
Just wanted to get the ball rolling on this in an effort to resolve this
ticket:
http://wiki.linuxfromscratch.org/lfs/ticket/2043
The question comes down to, 'Do we want to provide support for building
LFS from a UML system?'
I'm not sure that I'm qualified to speak much on this point, lacking
ex
On Tue, Jul 17, 2007 at 07:16:20PM -0700, Dan Nicholson wrote:
> I would like to allow glibc-2.5.1 through a freeze if it happens. That
> should be safe since we've been moving the snapshot along.
Duly noted. And I don't see why that wouldn't be fine. Especially as
once we clear up the remaining t
Hello,
I'm aware that this is perhaps a little off-topic for the -dev list, but
I feel that this thread could really help future development of the CD,
so please bear with me and help me out with as much feedback as you can
muster. :)
The LiveCD project rarely hears much back from its end users,
William Harrington wrote:
> I think it'd be a good idea to post this to all the mailing lists
> than just this one.
Well, I did lfs-dev, lfs-chat, and livecd. You think there's bound to be
more users not covered on the other lists?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-d
On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote:
> LFS could be made to accommodate x86_64 (multilib) with very few changes
> and a bunch of new pages. Where multilib gets tricky is where lfs stops
> and blfs begins. With the introduction of pkg-config and all those fun
> *-config pr
On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote:
> Thanks for the info. I think just to get started on handling multiple
> arches in LFS, we should focus on non-multilib 64 and just symlink
> /lib -> /lib64. Hopefully it doesn't bite elsewhere, but I think it's
> the fastest way to ge
On Fri, Jul 20, 2007 at 09:51:48PM +0100, Ken Moffat wrote:
> A slightly bigger problem might be that you don't seem to have a
> replacement for it.
Indeed. I meant to drop something in, but forgot about it. bin86/lilo
would probably be alright. Anyone tried grub2?
--
JH
--
http://linuxfromscra
On Fri, Jul 20, 2007 at 10:47:16PM +0200, M.Canales.es wrote:
> Depends on how the changes are applied in the branch.
>
> If the branch will contains only x86_64 pure64 libs commands for now (i.e.
> replacing the needed x86 trunk commands by the ones for pure64), current
> jhalfs should work fin
Greg Schafer zip.com.au> writes:
> It appears you haven't allowed for a surprising gotcha that means
> GCC-Pass2 will search for libs on the host thus rendering the build method
> ineffective. This (and the fix) is all documented in the DIY Refbuild.
Thanks. This was just an oversight. I meant to
On Mon, Jul 23, 2007 at 12:57:14PM -0700, Craig Jackson wrote:
> I would love a simple installer that copies the contents of the livecd
> to a "safe OS" partition, from which to build LFS or CLFS or whatever.
The most recent version does allow you to run the CD from a partition or
USB flash drive.
On Mon, Jul 23, 2007 at 10:34:45PM +0100, Ken Moffat wrote:
> The pure64 patch is usually thought to be needed in chapter 6 as
> well as pass 2 ;)
The problem I ran into is that the pure64 patch (at least the one I
found that's usable for gcc-4.1.1) won't apply once the specs patch has
been appli
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote:
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_DIRNAMES = 64 32
> -MULTILIB_OSDIRNAMES = ../lib64 ../lib
> +MULTILIB_OSDIRNAMES = ../lib ../lib32
And, I suppose if I'm going to be adding this to the specs patch, it
would
Greg Schafer wrote:
>> Author: jhuntwork
>> - Use --disable-multilib in final gcc and binutils
>
> Why binutils? It serves no purpose there.
I did notice that it didn't make a difference with binutils, but I must
admit that this was a case of working from CLFS. I started by taking
notes of wh
Greg Schafer wrote:
> Umm, you appear to have missed the point completely. Please re-read the
> info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
> around the surprising (buggy?) GCC behavior I'm talking about.
I didn't miss the point, I understood all of what you wrote. I
Greg Schafer wrote:
> Dude, it's fairly simple.
I'm not sure if you meant to sound condescending here; I'll give you the
benefit of the doubt and assume you didn't. It does appear, however,
that you missed the point of my request. I wasn't asking you to explain
to me your method; I get it. I w
Randy McMurchy wrote:
> I ditto these sentiments. Jeez, Jeremy, why invent the wheel?
Actually, I was trying to avoid that. The simple fact is that I rarely
consult DIY. For reference, I looked at what I was already familiar
with: CLFS. I didn't even remember that DIY had a native x86_64 build
Bruce Dubbs wrote:
> 1. Ignore the update for now.
> 2. Use our own repackaged version.
> 3. Add a note or other comments to to the iptables page
I'd opt for either 1 or 2. If we did number 3, I'm sure many people
would see the message after they've already unpacked it.
What's included in the
Greg Schafer wrote:
> Greg Schafer wrote:
>
>> Preferably on an Ubuntu64 host, please post the verbose output
>> of gcc-pass2 so we can what is going on ie:
>>
>> echo 'main(){}' | gcc -xc -o /dev/null -v -
>
> Actually, that may not be enough. Would also need to see the output of:
>
> gcc -prin
Randy McMurchy wrote:
> You are too sensitive.
Yes, you're probably right. :/
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Dan Nicholson wrote:
> I thought the reason for using iproute2 was because net-tools is
> unmaintained.
Yes, when the discussion for the change took place, this was the main
reason.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscri
This is a continuation from here:
http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059737.html
Starting a new thread because the last one was getting unwieldy and had
several different topics running through it.
Greg, the host I was working from was a current CLFS development
snapshot.
Jeremy Huntwork wrote:
> As an aside, the effects of their not having a /lib64 dir or symlink
> seems to be that if I want to use a CLFS system as a host, I *must* use
> their pure64 patch. I tried a build last night without using that patch
> and just using --disable-multilib and
Hello Everyone,
I'm trying to decide how best to alter the x86_64 branch. If we adopt
the basic principles from DIY-Linux, it would mean that as far as build
instructions go, we only have to add 3 things:
* Add --disable-multilib to each build of GCC (this has no effect on a
x86 build)
* In GC
Matthew Burgess wrote:
> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> The question is, do we want x86_64 to be a separate book, or simply roll
>> these small changes into a conglomerate book with x86?
>
> I'd certainly
Alan Lord wrote:
> * Bootloader, or rather lack-of
Yes, I keep forgetting about the boot loader. There's one more
difference - we'd probably want to add lilo/bin86 to the build.
Of course, you can always install grub to the mbr or partition without
installing grub's shell into the OS. Use the L
Matthew Burgess wrote:
> Hmm, that "nightmare" seems a bit extreme. Certainly, for native x86-64,
> which is the only additional target we're contemplating at the moment, having
> 2 paragraphs (or small sections at the most) in the book surrounded in the
> relevant profiling syntax, doesn't see
Bruce Dubbs wrote:
> I guess I can do it again. Most of the stuff is mechanical. We'd need
> to decide on a package freeze. Right now there are a total of 16 open
Can we cut trunk to a release/testing/6.3 branch so that we can begin
doing 7.0 type work on trunk?
--
JH
--
http://linuxfromscra
Bruce Dubbs wrote:
> I tagged 6.3-rc1. I also added 7.0 to the wiki milestones and 6.3-rc1
> and 7.0 to the versions for tickets.
Thanks. :)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
M.Canales.es wrote:
> I prefer to use the HLFS-way for x86_64 integration.
Well, you obviously know that setup better than I do. If you could help
me set that up, I'd appreciate it.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscr
M.Canales.es wrote:
> Could you continue using the x86_64 branch for now until jhalfs-2.3 will be
> released?
No problem.
> I think that at the weekend I will can start mergin the x86_64 changes into
> trunk. For a full set-up a new top-level index.html file must be created and
> the Makefile
Heya,
Not sure how important this is for the rc books, but chapter 6 gcc tells
the user to compare the gcc test results with those at this missing
link:
http://www.linuxfromscratch.org/lfs/build-logs/6.3-rc1
Just want to make sure we don't forget to generate these for 6.3.
Also, for a while now
Jeremy Huntwork linuxfromscratch.org> writes:
> If I end up getting it sorted it out, I'll let you take a look before I
> commit anything.
Manuel, I'm slowly beginning to understand how the HLFS render 'magic' works.
One question: would the 'condition
Jeremy Huntwork linuxfromscratch.org> writes:
> 2) The commands to adjust the gcc spec file would have to change to
> incorporate either dynamic linker. (Also, the current command in chapter
> 5's adjusting the toolchain, "gcc -dumpspecs | sed
> 's ^/lib/ld-linux
Greg Schafer wrote:
> Anyhow, I still suspect there is a buglet involving MULTILIB_OSDIRNAMES
> somewhere in the GCC driver that needs to be accounted for in this
> `--disable-multilib' build method, but my brain hurts when trying to
> figure out all the twisty parts of gcc.c.
Thanks for your help
Hello,
The LFS LiveCD team is pleased to announce a new 64bit-only CD. It is a
minimal CD, meaning that it contains no X Windows System and dependent
software nor any source packages. The LFS book that is included is based
on the current development x86_64 branch. Be advised that as of now that
On Wed, Jul 25, 2007 at 08:07:24PM +0200, M.Canales.es wrote:
> I'm not sure what do you meant, but entities are resolved while loading the
> XMLs in memory and before processing the they with XSL, thus I don't see how
> could we say to xmllint/xsltproc that they must use one set of entities or
On Wed, Jul 25, 2007 at 05:24:04PM +, Jeremy Huntwork wrote:
> can easily become:
>
> gcc -dumpspecs | sed -e 's@/tools@@g' \
>
> I can't test this on x86 right atm... would anyone be able to verify that this
> command would also work for x86?
Nevermind. I
On Fri, Jul 27, 2007 at 08:33:53AM -0600, Jeremy Huntwork wrote:
> Of course, as the build progresses and you begin using more and more
> items on the hard-disk only, (first in /tools and then in chroot), the
> read time would increase.
Er, decrease. The speed increases. :)
--
JH
On Fri, Jul 27, 2007 at 10:36:42AM -0500, Randy McMurchy wrote:
> Please help me in welcoming Ag as the newest member of the team.
Congrats, Ag. Nice to have you onboard officially. :)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.h
On Fri, Jul 27, 2007 at 10:25:31AM -0400, kas wrote:
> that the book changed that much. 64 bit was run from the CD whereas the 32
> bit build was run from the CD installed on a hard drive.
This would kind of skew the accurateness of your test. Reads performed
on a CD filesystem are noticeably s
kas wrote:
> Jeremy, I'm not trying to rain on your parade ... I want to figure out if I
> am
> doing something wrong or if we are building incorrectly ... or if gcc is (you
> fill in the blank).
It's OK, I had my parade rain-proofed recently. ;) I just wanted to make
sure your comparisons wou
On Mon, Jul 30, 2007 at 08:03:43PM +0200, M.Canales.es wrote:
> If some bug is found later we always could do a 6.3.1 release.
>
> Plus, I would start today with the preparative to can merge the x86_64 branch
> into trunk.
I've been thinking about this some more recently. I really think it's
not
On Mon, Jul 30, 2007 at 10:08:53PM +0200, M.Canales.es wrote:
> IMHO, multilib build instructions will be very intrussive due that several
> packages need be builded two times. If we want to add it, we will need to
> render sepparate books to not mess the reader with a lot of "if ".
I prefe
M.Canales.es wrote:
> And when x86_64 will be merged, that values will be less accurate.
I suppose that's argument for producing a separate set of text for 64-bit.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
M.Canales.es wrote:
> If we are happy with big figures, thus use the same values for all archs, If
> we want something accurate for each arch, remove the info from the book a
> create a web page to place jhalfs reports.
I like this option. Perhaps provide *very* rough estimates for the SBU
(rou
Bruce Dubbs wrote:
> http://www.linuxfromscratch.org/~sbu/
:-)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Alexander E. Patrakov wrote:
> Hello,
>
> I am afraid that LFS-6.3 will be obsolete even before release. Details
> follow.
>
> I have tried to build the x86_64 LiveCD from Debian Lenny (x86
> userspace, but with 64-bit kernel, 64-bit capable compiler, and with
> 64-bit libs installed). This fa
Jeremy Huntwork wrote:
> I also started a build on Ubuntu Dapper (don't have Feisty installed
> anywhere just now) just to see how that would go. I've already gotten
> past the point of error on the Debian system and it's still moving forward.
GCC pass 2 and still moving
Alexander E. Patrakov wrote:
> Then the main system will be 32-bit, but there will be a 64-bit kernel
> and enough 64-bit libraries to run simple 64-bit applications. And the
> compiler accepts the "-m64" switch, so that you can even compile them.
Thanks, I was wondering if you did something diffe
On Tue, Aug 07, 2007 at 08:15:39PM +0600, Alexander E. Patrakov wrote:
> [EMAIL PROTECTED] wrote:
> Please remove this and validate the book. Also, what are the plans for
> HJL binutils and glibc-2.6 based hosts?
GCC 4.2.1 and Glibc-2.6.1 have open tickets in Trac. So it's just a
matter of the f
Alexander E. Patrakov wrote:
> In order to build /tools to the end, I had to make the following extra
> adjustments: add --disable-libmudflap to gcc pass1, and replace "make
> bootstrap" with just "make" there (presumably, there is some mismatch
> with 64-bit glibc or headers and toolchain on th
Alexander E. Patrakov wrote:
> I wrote:
>> In order to build /tools to the end, I had to make the following extra
>> adjustments:
> In order to build binutils stage2, I also need to add (surely) flex and
> (possibly) m4 and bison to Chapter 5.
>
I'm still curious what your results would be if y
On Thu, Aug 09, 2007 at 04:28:47PM +1000, Greg Schafer wrote:
> Ok, it appears the GCC devs conveniently added a new (undocumented?)
> configure switch in 4.2 `--disable-stage1-checking' which does the right
> thing. Times for GCC-4.2.1 bootstraps without and with the switch are
> below:
Thanks. I
Hello,
You may have seen me working recently on a branch called 'jh'. I named
it that as a way to show that there are personal changes that have not
yet been community approved. And I needed an easy way to document and
present ideas.
Here are the major changes:
* Merge x86 and x86_64 commands i
On Thu, Aug 09, 2007 at 08:33:20AM -0600, Jeremy Huntwork wrote:
> * Use --disable-checking on GCC Pass 1. See this ticket:
> http://wiki.linuxfromscratch.org/lfs/ticket/2056
Sorry, typo. That's supposed to be --disable-shared.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/
On Sat, Aug 11, 2007 at 07:13:16AM +1000, Greg Schafer wrote:
> > I don't buy this explanation alone. The fact is that you can't build LFS
> > (or DIY) with FSF binutils if you are on x86_64 and start from a new
> > host such as Debian Lenny x86_64.
>
> The LFS/DIY build method is only meant to
On Sat, Aug 11, 2007 at 07:15:56AM +1000, Greg Schafer wrote:
> FWIW, If I were to design a pseudo-native build method based on cross
> compilation that is exactly how I'd attempt to do it.
Two questions:
1. Do you think it likely that the second pass of GCC in such a build
would bootstrap okay?
On Sat, Aug 11, 2007 at 10:01:01PM +0600, Alexander E. Patrakov wrote:
> LiveCD is not ready - mostly, one needs to update documentation and jhalfs.
This isn't and should never be a showstopper for LFS. Since its
inception as a project, the LiveCD always _followed_ LFS releases.
People who follow
On Sat, Aug 11, 2007 at 08:19:28PM -0500, Bruce Dubbs wrote:
> I've redone the acknowledgments page in my sandbox, but have not
> committed yet. Does this look OK to everybody?
>
> http://www.linuxfromscratch.org/~bdubbs/lfs-book/appendices/acknowledgements.html
I'm no longer the ALFS project le
On Sat, Aug 11, 2007 at 08:21:14PM -0500, Randy McMurchy wrote:
> has ever been. Too bad half the folks that would want to use it
> won't because they feel that their 64 bit machines need CLFS
> massaging.
Where do you get this information from?
I think that most people that use a 64-bit platform
Alexander E. Patrakov wrote:
> How do you propose to do this? I cannot recruit even testers. See -
> there was only one relevant reply to my request to test the CD on Intel
> hardware. The project is dead.
It's not dead. It's slow, but it isn't dead. I think you set your
standards for the proje
Randy McMurchy wrote:
> This is some of the most refreshing words I've heard in a long time,
> and would do wonders for the project. Jeremy, thank you for saying it.
> I feel guilty because I don't update the BLFS web site more often.
> (haven't even announced Ag's acceptance of an Editor's role, n
Bruce Dubbs wrote:
> I would really not want anyone except editors to update the web site.
> Its really pretty easy. svn checkout ... (once); edit html; svn commit
> -m '...' and its done.
I think you misunderstood my intention. I wasn't talking about
implementing a full wiki, or replacing the c
On Tue, Aug 14, 2007 at 11:41:54AM -0500, Bruce Dubbs wrote:
> Perhaps you can publish a .info file with each iso that has md5sum, file
> size, brief info, etc.
We're working on a getting a master server in place for mirroring the
ISOs. We hope to have that up by the end of the week. That should h
Hello Everyone:
The LFS LiveCD project is currently attempting to produce four CDs. A
minimalistic CD and a full Xorg+XFCE CD each for both x86 and x86_64.
There are two of us working on this project officially. It becomes quite
a bit of work to try to keep up with the development of LFS and co
Hello,
As I've been giving some thought to what might make the LiveCD project
more manageable, more open to community development and better all
around, it occurred to me that our build method could be adjusted. Right
now the build is automated by a long series of Makefiles that was, in
some r
Alexander E. Patrakov wrote:
> Yes, I think this is good enough for now for the DIY reference build, if
> it is clearly stated that the patch is a workaround. Not sure about LFS
> - the x86 build is not affected, the x86_64 branch apparently (Jeremy:
> am I right?) should not be used (because it
Shane Shields wrote:
> On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote:
>> Jeremy - that sounds like a cracking idea but I strongly believe that it
>> should go much further than the LiveCD...
>
> Strongly agree
I would love to see some sort of proper support for PM go into LFS, but
that all depend
On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
> I'll go on record as -1.
I'm not going to push to get this into LFS. If the vast majority of
those with a voice here are for PM in LFS, great. If not, great. :)
> I feel we should mention it, provide links to the various alternativ
On Wed, Aug 15, 2007 at 06:59:55PM +0600, Alexander E. Patrakov wrote:
> # This old version is the only one that won't clobber synlinks, e.g.:
> # someone moves /opt to /usr/opt and makes a symlink. With newer
> # versions of tar, installing any new package will remove the /opt
> # symlink and plo
On Wed, Aug 15, 2007 at 08:38:42AM -0400, George Boudreau wrote:
>I agree with Greg, Pacman is superior to Slackwares Pkgtools and does
> not depend on a quirk only available in tar <= 1.13..
>
I'm willing to give either a pkgtools-based PM or Pacman a try but a
definite decision on that cou
On Wed, Aug 15, 2007 at 02:56:45PM +0100, Alan Lord wrote:
> Perhaps therefore, making the LFS PM friendly and then having a separate
> project which would develop and provide on-going maintenance tools would
> be a way to look at this... It too would also be a "learning" tool
> demonstrating [p
On Wed, Aug 15, 2007 at 03:29:47PM +0100, Alan Lord wrote:
> Jeremy Huntwork wrote:
> This is pretty much what I said in the "LiveCD users" thread you started
> on the 18th of last month on the general list...
>
> In fact here's my comments from that.
Yes, I recall
On Wed, Aug 15, 2007 at 03:41:52PM +0100, TheOldFellow wrote:
> was spot on. Note also that neither fedora-6 nor ubuntu-7 would have
> anything to do with this box. So I'm impressed. (and I'd like to see
> instructions for loading the precompiled image onto the HD and making
> it bootable - I ca
On Wed, Aug 15, 2007 at 10:37:44AM -0600, Jeremy Huntwork wrote:
> Not in the least. If DESTDIR is set to an empty variable, the effect of
> the command is the same as usual.
>
> ./configure --prefix=/usr && make && make install
> is the same as
> ./configure --p
On Wed, Aug 15, 2007 at 11:34:34AM -0500, Randy McMurchy wrote:
> If something were to be implemented, even a DESTDIR foundation without
> full PM capability, would ruin cut-and-paste capability for the scores
> of readers that don't want the bloat a PM brings into the picture.
Not in the least. I
On Wed, Aug 15, 2007 at 11:59:34AM -0500, Randy McMurchy wrote:
> I can't see it happening in BLFS for the simple reason that it would
> be a monumental task (automating the proper inserts could perhaps be
> done, but we wouldn't do that until *every* package has been tested,
> which again would be
On Wed, Aug 15, 2007 at 12:05:09PM -0500, Bruce Dubbs wrote:
> Having said that, I am not opposed to a PM hint (which already exists)
> or even a entirely new project "PM for LFS". A relatively small book
> that explains package management and one (or more) methods may be a nice
> compliment to th
601 - 700 of 1449 matches
Mail list logo
