You two are right, I'm so sorry, if I had used my own damn tools
instead of doing it by hand it would have showed up. I keep doing
crap like this, sorry for being unobservant.
On Dec 19, 2006, at 11:49 PM, KP Kirchdoerfer wrote:
> Am Mittwoch, 20. Dezember 2006 00:06 schrieb Pau
It looks like ipt_CONNMARK.o is not in the Bering*_modules.tgz file
in the iso image.
Can we please get this in as part of the standard build before
shipping 3.0? It's needed for TCP connection tracking when using
shorewall to do intelligent rate limiting of flows.
Much thanks,
Paul
Ron Senykoff wrote:
> Sorry for the duplicate emails Eric...
>
>>> Instead of branching out, you could create a custom QOS, configdb and
>>> moddb package and a lwp plugin. The packages can be merged in an automatic
>>> way with the standard package to an image. This way you can just keep pace
>>>
Doh, I'm an ass. I found it just after I sent the note out... I was
thinking, "I know it was in 2.x..."
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
Eric Spakman wrote:
> Hi Paul,
>
>>> What troubles me more is that Tom updates the documentation on his site
>>> to represent the state of the art in shorewall v5, and the currently
>>> shipping versions of LEAF or BU are using shorewall v3, our
>>> documentation will not match the code we're shi
Is there a reason the ez-ipupdate package for 3.x isn't in the packages
3.x list? Does it not build or?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
Mike Noyes wrote:
> I believe, an even better solution is using DocBook XInclude from LEAF
> to the Shorewall site. This is only possible if you're using DocBook XML
> to generate man pages, and the docbook xml source is
> available via uri.
>
The only problem with that idea that I can think of,
Andrea Fino wrote:
>
> Hi to all,
>
> I have put the ast*.lrp packages on the cvs repository on sourceforge.
>
> here they are: devel/faino/asterisk/packages/bri2/
>
> Moreover, I have put all the things needed to build them. If someone is
> interested I can write down some doc about building t
Eric,
The new .lrp files are running on the home router as well as the
development systems. I can't begin to tell you how happy I am that this
will be the last 3 hours of manual diffing and patching I had to do for
LEAF configurations when doing a forklift upgrade.
Paul
p.s. I've got a new r
Eric Spakman wrote:
> Please take a look at the local.lrp package of 3.x, it has a new
> functionality. You can list the added files that you want to save. Before
> use check the help file of local.lrp.
That's good enough, thanks Eric!
-
The 2.x distribution had one particularly nice feature that I'd like to
see reimplemented in 3.x. From the looks of it, saving the config
currently only checks the collection of config files enumerated in
/var/lib/lrpkg/*.config.
There are times when I need ancillary scripts and crap on the ro
Cédric Schieli wrote:
> The best doc (or starting point) should be the script
> tools/createimage.sh in buildtool
Awesome, much thanks!
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff do
OK, what I'd like to do is reproduce the build sequence that you guys
use, exactly, to create the CD. What I'd like to do is have a unified
build from scratch and build from source environment (perhaps modulo
lrpstat).
Is there any documentation on that?
--
I'm going to try to pound out something to do this, unless someone
tells me that there's already a better way of doing it. I don't quite
understand apkg.merge yet so I'm still scratching my head on how to do
it most efficiently.
I would like some functionality that would generate a diff -u file o
he contents of /etc/modules and a
# defined modules repository.
#
# Copyright (c) Paul Traina 2006, GPL v2
#
MODLIST=/etc/modules
MODREPO=/mnt/modules.tgz
LIBMOD=/lib/modules
##
progname=`basename $0`
usage() {
cat >
Here's what I was talking about... this is the core engine, obviously
it should take some command arguments, and make some intelligent guesses
about where .lrp files exist (stealing from apkg/lrcfg), but I wanted
to show actual working code to make this a non-academic pitch.
Even if folks don't l
? busybox-1.2.1
Index: .config
===
RCS file: /cvsroot/leaf/src/bering-uclibc/apps/busybox/.config,v
retrieving revision 1.10
diff -u -r1.10 .config
--- .config 13 Aug 2006 20:22:05 - 1.10
+++ .config 8 Sep 2006 05:08:0
Please consider applying this patch to dropbear. It will dynamically
create the dropbear host key files if they don't exist. This is EXTREMELY
useful for bringup from scratch. If you don't have access to the serial
port, at least you can ssh into the box. I wish I had had it today.
With this c
I don't know how popular this is going to be, but I'll toss it out anyway.
For 99% of leaf users, storage is no longer ultra critical. This idea
is not meant to eliminate the current way of doing things (for those
folks who really are tight on secondary storage, things stay the same),
but I'd
Just my random notes. I built a leaf flash from scratch using pxeboot
on a spare box using the CVS .lrp packages
diff.lrp is not being built?
a port of traceroute would be a good thing (feedback from burning man)
ditto iperf
not having a WRAP configdb kinda sucked... (the whole serial console
Sorry for the delay getting back to you, just got back from a week on
the playa lighting up dust storms with 2.4 and 5.8ghz wifi... :-)
> The reason I'm not really enthusiastic about this idea is that it adds a
> new dependency between sylinux, initrd and the etc package and also adds
> extra com
Eric Spakman wrote:
> Hi Paul,
>
>> Not if it's not. You're the software developer, you make the
>> distribution etc.lrp. The whole point of this thing is to get people
>> running with a working console. Once they're on their feet, i.e. if
>> they edit the /etc/inittab or do a backup aft
Currently, /etc/init.d/showtraf adds a line to /etc/crontab.
This is seriously bogus.
Instead, showtraf.lrp should own a file called
/etc/cron.d/showtraf
and any showtraf cron commands should be in that file.
Otherwise, if you back up etc.lrp while showtraf is running,
you'll get showtraf's cro
Cool. I'm heading out to the desert for 2 weeks, I'll check back in
once I have come home and washed all the dust off and regained my sanity.
Paul
-
Using Tomcat but need to do more? Need to support web services, security?
Your call, but the stuff in the help file isn't formalized and it isn't
validated in any way since it was always human input.
When are you guys shooting for a 3.0 alpha test release? I just whacked
together stuff for burning man based on 2.4.2 even though that's a bit
creaky because I wasn't s
Eric & KP,
Looks nice, been trying to catch up on things...
Couple of questions, while we're doing the 3.0 flag day, would it be OK
if we made the package dependancies explicit, not part of the help file?
/var/lib/apkg/.depend
which would contain a list of packages that the current package depe
Hi Eric and friends,
I stumbled across a couple of problems today while playing with hostapd.
It looks like WPA2 (psk) is not working properly with my Atheros CM9
card. I did a cursory visual inspection of the source and it looks like
the problem might be fixed by compiling with MADWIFI_NG. U
I would love to remove the documentation from the configuration files since it
is a PITA to maintain but when I've suggested that idea in the past, the
moans and cries have been absolutely pitiful to hear :-)
-Tom
I agree and stand corrected. :-)
Eric,
This isn't magic. Debian solved this quite nicely years ago.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime
I'm glad to hear that someone with energy and good ideas is looking at this.
"In a perfect world" what I'd like to see is binaries come with default
sensible configurations, and the user is simply responsible for
specifying and maintaining divergences from that configuration. There
are a whol
I think the question is, should the PRIMARY b-u distribution be geared
towards a floppy release, or something more modern. If people with
floppy only hardware want to maintain a stripped down floppy only
version, that's great, but do we really want the fate of B-U tied to
such limitations?
F
I got my dev environment working (limping) again.
I built a pptpd with symbols and statically linked.
It was crashing in libwrap.
I added the line "pptpd: ALL" to /etc/hosts.allow and now it works.
My libwrap hosts.deny is the default, libwrap should obviously not
be crashing. Unfortunately I di
I thought, at one point, the ipp2p matching code was part of the build
kernel, but it doesn't appear as if it's in the 2.4.32 kernel you compiled.
No, the ipp2p code isn't in yet. I know Arne created some setups for it,
but we still need to discuss a bit about what's the best way to implement
it
Eric,
I thought, at one point, the ipp2p matching code was part of the build
kernel, but it doesn't appear as if it's in the 2.4.32 kernel you
compiled. If not, this would be a nice capability for BU to carry
forward. I find that the p2p traffic on my network is bogging stuff
down a bit (es
No clear differentiation between programs that run in the host environment
and programs that need to be compiled in the target environment.
Good exercise would be to build LEAF on a non x86 linux box and find all
of this crap (for example, linux/scripts/mkdep (a binary) is compiled
against uclibc
Eric Spakman wrote:
Hi Paul,
Something needs to be done so that the pthread include files are used
instead of the system include files.
The pthread library is part of uClibc and compiled with the initial build
of buildenv. The pthread.h file is also part of uClibc and placed in the
.../stagin
Eric Spakman wrote:
Hi Paul,
(6)
upnpd package needs to depend upon lpthread in sources.conf
That's not needed, the pthread library is build as part of uClibc and
already build in the buildenv setup. The pthread setup is only to create
the package, it's no dependency of upnpd.
Eric
Some
(1)
gpio fails to package
tries to package staging/lib/modules/gpio.o
file is really staging/lib/modules/2.4.32/gpio/gpio.o
--
(2)
initrd needs to be built as real root, not fakeroot because it tries to
m
Guys, I see folks are starting to work on the new kernel, at this point,
it would be a good thing update openssl to 0.97i (or 0.98a if you're
going to refresh binaries as well).
More security holes.
---
This SF.net email is sponsored by: Spl
KP, here's a change I'd like to see implemented in the kernel. It
removes the old hard-coded keyboard controller check code for a much
more simple runtime detection of the keyboard. With this patch, there
will be no more reason to produce two different kernels for B-U afaik.
Everything goes
Would someone with kernel privs add the wrap gpio driver that Luis did
into the kernel module build process? It doesn't have to go in the
default modules file, but it should be built by the leaf team instead of
people having to manually do it.
Paul
--
A port of 2.2.3 to B-U's buildtool has been uploaded to
devel/pstraina/shorewall.
Please code review and send opinions/hate-mail, etc.
Thanks,
Paul
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds o
Agreed.
On Mon, Apr 11, 2005 at 01:54:10PM -0700, Tom Eastep wrote:
> Tom Eastep wrote:
>
> >
> > Thanks -- I note that KP had added another change to the rules file in
> > LrpN which I hadn't included in my patch. Something to do with dnsmasq...
> >
>
> Ok -- I took a look at that and it has
Hmm, OK, there are a couple patches in here I assume you didn't want
anymore... based upon your changelog saying you weren't going to set up
default stuff anymore in /etc?
Specifically:
Tom Eastep wrote:
--- /home/teastep/Shorewall/Shorewall2/interfaces 2005-04-08
10:19:05.0 -0700
Tom Eastep wrote:
Paul Traina wrote:
Actually, that's exactly what I was suggesting we do as well, although
there's not consensus about it.
Let me take a whack at it this afternoon and see how cleanly I can do
it. If people like the results, great, if not, no worries. The biggest
pr
Actually, that's exactly what I was suggesting we do as well, although
there's not consensus about it.
Let me take a whack at it this afternoon and see how cleanly I can do
it. If people like the results, great, if not, no worries. The biggest
problem with the way I was /intending/ to do it w
I don't see it in buildtool? Tom's got some changes in CVS I want to
play with to test UPnP integration, and I wanted to see about making
some local changes.
I realize shorewall isn't compiled per-se, but shouldn't it be under
buildtool anyway so we can patch in local changes?
Confused...
Pau
Warning:The symlink from /lib/ld-uClibc.so.0 -->
/home/pst/LEAF/buildtool/staging/lib/ld-uClibc.so.0 does not exist,
this may cause problems with some configure scripts that try to run
a compiled program
Do we still need this link? If this is the case, then how can buildtool
do cross-arch target
g-uClibc
Date: Wed, 6 Apr 2005 09:24:21 -0700
From: Paul Traina <[EMAIL PROTECTED]>
To: leaf-user@lists.sourceforge.net
Hi folks,
I just wanted to introduce myself and let people know that I've uploaded
Universal Plug-N-Play Internet Gateway Device support for Bering uClibc.
This is a po
Sigh, I forgot, I already asked this question in Feburary, I just didn't
like the answer then so I forgot it...
K.-P. Kirchdörfer wrote:
> The long term idea by Arne or Martin has been to chroot into staging
> and run our own distro from there.
> I've asked myself, but then with all the problems
In the upnpd package, I create several new files that are part of the
package and are LEAF environment specific. At first, I was keeping them
in a patch file, but that seems like I'm mis-using cvs. I think it
would be best to actually keep them as individual source files right in
CVS so peopl
I certainly understand why we copy the toolchain, libraries, and include
files into bt_staging_dir, but it seems somewhat bogus that we're doing
so for end-binaries (i.e. things that nothing else is ever going to
depend upon)...
Is there a reason for this? It seems that there was a change in t
Hi,
I'm packaging upnpd.lrp. I'd like to add a few user defined actions to
shorewall to make integrating leaf and shorewall a bit easier. I'm
wondering what the best way to do this is...
currently I'm having the user add:
/etc/shorewall/action.allowinUPnP
/etc/shorewall/action.allowoutUPnP
/et
53 matches
Mail list logo