> I need ppp, I have no use for dhcp.
PPP. I admit to often forgetting about that one. The BLFS book handles
PPP installation of course and also touches on GPRS and EDGE setup. PPP
setup is not as straight-forward as DHCP (ppp for dialup, or for pppoe
and other slight variations thereof). It mi
> know about). The current BLFS development book has dhcpcd; I didn't
> look to see if it also has dhclient / pump / others.
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/dhcpclient.html
> A workaround for that issue is to have an "alternatives to the XXX DHCP
We'd have to yes, people
On Thu, 22 May 2008 18:15:40 -0600
Gerard Beekmans <[EMAIL PROTECTED]> wrote:
> One of the solutions that came from the udev discussion the last few
> days was to move dhclient from BLFS to LFS. Or leave it in BLFS but
> also install it in LFS.
>
> I know we've had the discussions before in the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> One of the solutions that came from the udev discussion the last few
> days was to move dhclient from BLFS to LFS. Or leave it in BLFS but also
> install it in LFS.
One possible issue would be that there are lots of dif
One of the solutions that came from the udev discussion the last few
days was to move dhclient from BLFS to LFS. Or leave it in BLFS but also
install it in LFS.
I know we've had the discussions before in the past. I'm honestly not
sure anymore what the outcome of that was.
Gerard
--
http://
This is under the premise that the udev configs are stored in a package.
How about possibly tackling them like we do the bootscripts - the udev
rules are in SVN, thus they are always checked out in our local copies
when we do 'svn co LFS/trunk'
--
http://linuxfromscratch.org/mailman/listinfo/l
> (What I'd like to do is get udev-122 into SVN along with the "udevadm
> test" option, for now. Any fixing of the network configuration can, of
> course, change around section 7.13.1 later. :-) )
Go for it. In the mean time I'll start a new thread or two with proposed
network changes. Even if
command in the XML toolkit (which I'll call "get-entity") that takes an
entity reference's name, and prints the entity's value to stdout. So
for instance, "get-entity udev-config" would print whatever the entity
&udev-config; expands to in the XML (that is, "
Bryan Kadzban wrote:
> Gerard Beekmans wrote:
>> If a diverging is needed then we may just need to branch it.
>
> Yeah, that may have been smarter.
>
>> It's not *the* solution but it sure would keep things easy for us. It
>> gets complicated otherwise to rememer.
>
> I'm not sure if this is pos
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander E. Patrakov wrote:
> Gerard Beekmans wrote:
>
>> Rather than trying to fix udev, and it sounds like there isn't a
>> solution that isn't hackish and has a risk of not working any day
>> now with new releases. How about we fix our netw
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> If a diverging is needed then we may just need to branch it.
Yeah, that may have been smarter.
> It's not *the* solution but it sure would keep things easy for us. It
> gets complicated otherwise to rememer.
I'm not sur
Alexander E. Patrakov wrote:
> Gerard Beekmans wrote:
>
>> Rather than trying to fix udev, and it sounds like there isn't a
>> solution that isn't hackish and has a risk of not working any day now
>> with new releases. How about we fix our network setup.
>
> Yes, this is possible. However, this
> The scenarios are varied, but some "default" suitable for most cases has to
> be
> in the book. Some options for this default are:
I agree with that. That would most likely mean dhclient needs to be
moved from the LFS book to the BLFS book.
> 3) always write udev rules by hand--the idea is s
As getunimap, loadunimap and setfont man page say, getunimap, loadunimap
program are old and obsolete and replaced by setfont.
So no need to worry about (same as mapscrn)
Gilles
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See th
Gerard Beekmans wrote:
> Rather than trying to fix udev, and it sounds like there isn't a
> solution that isn't hackish and has a risk of not working any day now
> with new releases. How about we fix our network setup.
Yes, this is possible. However, this requires dropping udev and moving to a
Gerard Beekmans wrote:
> Aren't we back to square one after you enable more drivers. Then after
> the first reboot of "kernel with additional drivers" you have to go
> through the discovery again of which card has which name assigned.
No, we aren't.
1) First boot, with only an Intel card recog
> Right, that's why I was saying you'd probably want to minimize the
> macro usage in general. However, from the perspective of someone using
> RPM, I really want to use the macros.
Make up our own? We then need to distribute that as part of the rpm
package installation.
Call them things like %l
On Wed, May 21, 2008 at 9:11 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Gerard Beekmans wrote:
>>> for any bog standard autotooled package:
>>>
>>> %configure
>>>
>>> Looks simple enough: it runs ./configure for you. However, there's a
>>
>> So to summarize simply using the %configure macro won't
>> Enhance the network boot scripts to first check for a link before assigning
>> the IP address.
>
> Would this work? You would have to know the ip address of the gateway
> attached
> to the network card. If two cards have the same ip address, will the system
> try
> to sent outbound packet
On Wed, May 21, 2008 at 9:00 PM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> Gerard Beekmans wrote:
>> So to summarize simply using the %configure macro won't run it like we'd
>> want the configure script to be run.
Yeah. %configure would do a lot more than ./configure. Not that that's
a ba
> As far as I understand, the outcome was (roughly) that LFS needs to provide
> at
> least a no-PM and PM versions, with a well-known PM. And a requirement has
> been
> formulated that the commands must match between these two versions (thus
> ruling
> out %configure for RPM). Now Bruce wonde
> them. That way if the book and those packages ever diverge (e.g. as
> udev-config has recently; the current udev-config trunk won't work with
> the current BOOK trunk), you don't get the wrong scripts or rules files.
>
That's what I was getting at. However we may want to safe guard against
Gerard Beekmans wrote:
>> Both RPM and Debian package managers require writing a set of control files
>> in
>> order to create a package. Although it is possible to write dummy files
>> containing only packaging information for pre-built files (and no building
>> instructions), this is not how
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gerard Beekmans wrote:
> ...Develop/maintain an actual bootscripts package and during the
> generation of the LFS book, extract the scripts and include into the
> book.
>
> That does mean that anybody who wants to build the LFS book needs to
> c
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce Dubbs wrote:
> Gerard Beekmans wrote:
>> I think the consensus we're trying to reach is what to do with the
>> bootscripts if we do add them back to an Appendix as Bruce
>> suggested. Do we still install the bootscripts the current way or
>>
25 matches
Mail list logo
