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 Paul Traina
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
with
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 shipping.
snip
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
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
reference to generate man pages, and the docbook xml source is
available via uri.
The only problem with that idea that I can
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
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 them.
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
repository.
#
# Copyright (c) Paul Traina 2006, GPL v2
#
MODLIST=/etc/modules
MODREPO=/mnt/modules.tgz
LIBMOD=/lib/modules
##
progname=`basename $0`
usage() {
cat 2 -EOF
Usage: $progname [ -m modules ] [ -f modules.tar.gz
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
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?
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
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
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!
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
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
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
? 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
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
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 after the
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
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/packagename.depend
which would contain a list of packages that the current
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
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,
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 whole
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 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. :-)
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?
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
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
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
(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
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:
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
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...
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
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
problem
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
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 to do with
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
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 port of the project at linux-igd.sourceforge.net with some
help
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
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
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
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
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
48 matches
Mail list logo
