Re: [leaf-devel] Contention for conf/sources.cfg
On Tue, 2012-05-22 at 23:10 +0200, Erich Titl wrote: > on 22.05.2012 18:14, davidMbrooke wrote: > > Hi all, > > > > I've noticed that we sometimes get conflicting updates to > > conf/sources.cfg - especially when different developers add new Packages > > at roughly the same time. > > > > One option to reduce this problem would be to change buildtool.pl to > > automatically "include" every .cfg file in a specific directory. > > The directory structure could look something like: > > I am not really clear why this would buy us anything, sources.cfg would > still be a single instance. > > cheers > > Erich Hi Erich, I guess I didn't explain very well... The "new" sources.cfg would not contain any or definitions itself, just entries and something like <> Then we'd have e.g. sources.d/busybox.cfg containing: Server = localrepo Revision = HEAD Directory = busybox Description = busybox Name = buildenv david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Contention for conf/sources.cfg
Hi all, I've noticed that we sometimes get conflicting updates to conf/sources.cfg - especially when different developers add new Packages at roughly the same time. One option to reduce this problem would be to change buildtool.pl to automatically "include" every .cfg file in a specific directory. The directory structure could look something like: conf/ sources.cfg sources.d/ avahi.cfg berkeleydb.cfg ... Worth pursuing, maybe for 5.x? david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Wed, 2012-05-16 at 23:32 +0200, KP Kirchdoerfer wrote: > Am 16.05.2012 23:21, schrieb davidMbrooke: > > On Wed, 2012-05-16 at 23:03 +0200, KP Kirchdoerfer wrote: > >> Hi David, > >> > >> sorry, a misunderstanding on which side ever... I meant to add > >> "Linux Embedded Appliance Framework" below the logo. > >> > >> > >> kp > > > > As in: > > > > ** > > LOGO > > ** > > Linux > >Embedded > >Appliance > >Framework > > > > ? > > > > david > > Maybe - or as in > > > ** >LOGO > ** > Leaf Embedded Appliance Framework (in one line) > > Not shure if that's possible/lloks good - just asking how it looks. > > Anyway The logo with text as it is looks better than without text. Maybe > in the long run the logo will speak for itself. > > kp Hi Kp, Let me try some experiments at the weekend. So far we have several votes in favour of the new logo and none against so on that basis it is worth proceeding. Personally I would like the option of: - A "full" logo like the one in the body of the Wiki Main Page. - A "small" logo, which is roughly square, and could act as a favicon.ico for web pages (which Mike also requested). - Perhaps one or two other variants. david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Wed, 2012-05-16 at 23:03 +0200, KP Kirchdoerfer wrote: > Hi David, > > sorry, a misunderstanding on which side ever... I meant to add > "Linux Embedded Appliance Framework" below the logo. > > > kp As in: ** LOGO ** Linux Embedded Appliance Framework ? david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Wed, 2012-05-16 at 22:05 +0200, KP Kirchdoerfer wrote: > Am 15.05.2012 23:05, schrieb davidMbrooke: > > > > As a comparison I have updated the Wiki sidebar logo with just the > > graphic, which seems a little "bare" by comparison to the version with > > the text. We could add the LEAF text below the graphic, which would also > > make it roughly square. > > Hi David; > > Not shure yet - can you upload a logo for the sidebar with the LEAF text > below for comparison? > > kp Hi kp, I can do that. Check again now :-) You can see a side-by-side comparison at http://sourceforge.net/apps/mediawiki/leaf/index.php?title=File:MediaWikiSidebarLogo.png The colours look slightly different, perhaps because I edited the Vector (.ai) source with Inkscape then converted to PNG using Inkscape. The original graphic artist used CorelDraw, I believe. david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Tue, 2012-05-15 at 22:25 +0200, KP Kirchdoerfer wrote: > Am 15.05.2012 21:20, schrieb davidMbrooke: > > On Sat, 2012-05-05 at 12:12 +0100, davidMbrooke wrote: > >> No response from Rich (yet) so I've kicked off a project at > >> freelancer.co.uk and I'll pick one of the bidders to see what they come > >> up with. > >> > >> david > > > > My commission for a new logo at freelancer.co.uk has been completed. > > The graphic artist came up with a logo to try to emphasize the "leaf" > > and "framework" aspects, and also something that is different from other > > "leaf" logos. (Do a Google Images search for "leaf logo" and you get a > > *lot* of hits!) > > > > I have the full vector-format source for the graphics and have been > > assigned full copyright (but I will release under the Creative Commons > > Attribution-ShareAlike license). Before I upload to the "leaf/leaf" Git > > repository I want to check how the rest of you like the new artwork. > > > > I have uploaded a .png version of the full logo to our Wiki and > > (temporarily) added it to the Main Page: > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Main_Page > > > > I'm also thinking of removing the text and using just the graphic > > portion in some places (e.g. the Wiki sidebar). > > > > What do you think? I won't be offended (much) if you don't like it :-) > > Hi David; > > I'm (positively) surprised of the result. > > My first impression is that I like the move to a green colorization. The > logo itself also expresses a sort of "linking networks". > I also like the "underline" I'm not shure about "LEAF" being that > prominent/huge. But without it, it may look "empty", and something > smaller might have been tested by the author... > > To summarize: As longer I look at it, the more I like it. And the > possibility to just use logo itself, or the full one - when appropriate > - gives enough freedom. > > kp Hi kp (and Martin Hejl who I see has also replied positively), I too find it looks better as time passes. Maybe the zoom is too big on the Wiki main page; I have just scaled it down a little. As a comparison I have updated the Wiki sidebar logo with just the graphic, which seems a little "bare" by comparison to the version with the text. We could add the LEAF text below the graphic, which would also make it roughly square. (Note that it is trivial to revert to the old Wiki sidebar logo, which is still there as the previous version of the sidebar logo file.) david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Sat, 2012-05-05 at 12:12 +0100, davidMbrooke wrote: > No response from Rich (yet) so I've kicked off a project at > freelancer.co.uk and I'll pick one of the bidders to see what they come > up with. > > david My commission for a new logo at freelancer.co.uk has been completed. The graphic artist came up with a logo to try to emphasize the "leaf" and "framework" aspects, and also something that is different from other "leaf" logos. (Do a Google Images search for "leaf logo" and you get a *lot* of hits!) I have the full vector-format source for the graphics and have been assigned full copyright (but I will release under the Creative Commons Attribution-ShareAlike license). Before I upload to the "leaf/leaf" Git repository I want to check how the rest of you like the new artwork. I have uploaded a .png version of the full logo to our Wiki and (temporarily) added it to the Main Page: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Main_Page I'm also thinking of removing the text and using just the graphic portion in some places (e.g. the Wiki sidebar). What do you think? I won't be offended (much) if you don't like it :-) david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] commands in /etc/networking/interfaces?
On Tue, 2012-05-08 at 18:35 +0200, KP Kirchdoerfer wrote: > Hi; > > I see a problem with hostapd and ipv6 addresses. > (To summarize: hostapd started from /etc/init.d/ destroys ipv6 addresses > from managed interfaces - the bug has been reported in 2010 to hostapd, > and is (also) described also here > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536630) > > While this a known bug/problem, my main concern is that the workaround > for a Debian-based system as found in Debian bug report above - "to not > start hostapd from /etc/init.d and instead from interfaces after wlan0 > is up" does not work on LEAF Bering-uClibc (tested with 5-prealpha) > > "auto wlan0 > iface wlan0 inet static > address xxx.xxx.xxx.xxx > netmask xxx.xxx.xxx.xxx > hostapd /etc/hostapd/hostapd.conf" > > Note the last line! This does not work, even with using the full path to > hostapd... It does work (avoid starting hostapd form init.d) when I > start hostapd form the CLI. > > It looks like the command in interfaces doesn't even run...? > > Anyone who can confirm that running from /etc/networking/interfaces > works at all? > > kp Hi kp, Is that syntax for the workaround correct??? I haven't tested this on 5.x yet but on 4.x I use commands in /etc/network/interfaces all the time - but they need to be prefixed with a keyword, typically "up". For example, I use: auto eth1.16 iface eth1.16 inet static vlan_raw_device eth1 address 192.168.16.1 netmask 255.255.255.0 broadcast 192.168.16.255 up ip addr add 192.168.16.11/24 brd 192.168.16.255 dev eth1.16 label eth1.16:0 Works fine! The text after the "up" can be any shell command, IIRC. See http://wiki.debian.org/NetworkConfiguration for more details. david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] TRAC only lists "versions" up to 4.1
Hi kp, TRAC doesn't currently let users report issues with anything newer than 4.1. Could you please add entries for 4.2, 4.2.1-rc1, 4.2.1. Maybe we should include this in the Wiki page on creating a Release? Thanks, david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
On Thu, 2012-04-26 at 19:41 +0100, david M brooke wrote: > On 26 Apr 2012, at 16:07, Mike Noyes wrote: > > > On 04/26/2012 07:26 AM, Mike Noyes wrote: > >> On 04/22/2012 04:45 AM, davidMbrooke wrote: > >>> Hi all, > >>> > >>> I've added a Software Infobox to our Wikipedia page > >>> (https://secure.wikimedia.org/wikipedia/en/wiki/LEAF_Project). > >>> I was going to upload the LEAF Project Logo but Wikipedia asks *lots* of > >>> questions about Copyright for image uploads and I'm not clear about > >>> where our current logo came from and who owns the Copyright. > >>> The current logo also still says *Firewall* rather than *Framework*. > >> > >> David, > >> I created the image. I'll make sure the Gimp source is in Git. I never > >> licensed it. It's for the project. > > > > David, > > Be aware that I used the Tux logo, so its licence is embedded in our > > current logo. > > > > https://en.wikipedia.org/wiki/File:Tux.png > > > > > >> We had a small contest on leaf-devel > >> to decide on the current logo. > >> > >>> For a while I've been thinking about commissioning a new Logo, so maybe > >>> now's the time. I'm thinking something easier to read when scaled down, > >>> and with more of a "LEAF" (of a tree) motif. > >> > >> A vector graphic will scale better, and allow favicon. Inkscape wasn't > >> available when I created our logo. > >> > >>Example: > >>http://alpinelinux.org/ > >> > >>> Freelance logo designs seem to come in under $50 and I'd be willing to > >>> pay that myself. > >> > >> Any improvements are most welcome. You may want to talk with Rich Bowen > >> (aka DrBacchus on Freenode irc #sourceforge) about this, as he is > >> helping projects with logos. > >> > > > > > > -- > > Mike Noyes > > http://sourceforge.net/users/mhnoyes > > https://profiles.google.com/mhnoyes > > Thanks for all the feedback. Not sure where my original email got stuck (I > sent it at the weekend, but assumed I'd goofed somehow when it didn't > appear). I know Rich Bowen from the LEAF podcast so I'll seek his advice. > > david No response from Rich (yet) so I've kicked off a project at freelancer.co.uk and I'll pick one of the bidders to see what they come up with. david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Next branch: merging with 4.x
On Sun, 2012-04-22 at 17:21 +0300, Andrew wrote:
> Hi all.
> I noticed that there are manually applied software updates into both
> next and 4.2 branch, which will cause merge conflicts in future merging
> of branches. It'll be not a big trouble, but it'll be better done by
> usual merge (git merge /, for ex., git merge BuC/master).
Thanks Andrew. I'm getting the hang of Git, slowly... :-)
Just to make sure I understand properly: if we want to make changes to
BuC 4.x which we *also* want to include in BuC 5.x ('next') then the
preferred procedure is to:
- Apply the change to the 4.x (master) branch
- Merge the master branch with the 5.x (next) branch
Is that right?
david
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] LEAF Project Logo - Time for an update?
Hi all, I've added a Software Infobox to our Wikipedia page (https://secure.wikimedia.org/wikipedia/en/wiki/LEAF_Project). I was going to upload the LEAF Project Logo but Wikipedia asks *lots* of questions about Copyright for image uploads and I'm not clear about where our current logo came from and who owns the Copyright. The current logo also still says *Firewall* rather than *Framework*. For a while I've been thinking about commissioning a new Logo, so maybe now's the time. I'm thinking something easier to read when scaled down, and with more of a "LEAF" (of a tree) motif. Freelance logo designs seem to come in under $50 and I'd be willing to pay that myself. Thoughts? david -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Samba
On Fri, 2012-04-13 at 09:58 -0700, Mike Noyes wrote: > Samba Patch: Linux Users Should Apply Immediately > http://www.informationweek.com/news/security/app-security/232900201 Hi Mike, Thanks for the heads-up. We're WAY out of date on Samba versions - currently shipping 2.0.10 and 2.2.12. Must be time for an upgrade to 3.6.4. I'm on it... david -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Arm screenshot
Thanks guys. Glad you like it :-} As always, kudos to Andrew for leading the way. "It's LEAF, Jim, but not as we know it" as someone on Star Trek once said (nearly) david On Fri, 2012-04-06 at 15:02 -0500, Charles Steinkuehler wrote: > > > Awesome work! > > On 4/6/2012 2:50 PM, Mike Noyes wrote: > > David, Nice. Very nice indeed. :-) > > > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=File:Bering-uClibc_5.0-prealpha_armv5.png > > -- > > > Charles Steinkuehler > char...@steinkuehler.net -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - Successful build of ARM toolchain
Hi all, I *finally* got my ARM toolchain to compile! Seems there are some issues with NPTL on ARM (both for uClibc 0.9.32.1 and 0.9.33) so I have reverted to the "new" pthread implementation for now (only for armv6; i486 still uses NPTL). A couple of minor fixes were required in toolchain/buildtool.mk plus some configuration tweaks elsewhere. I have uploaded my kernel and uClibc config files to Git in case anyone else wants to try building an ARM toolchain intended for the Raspberry Pi. I have also updated the Wiki page. Should be a simple case of: buildtool.pl -t armv6-unknown-linux-uclibcgnueabi build toolchain I am still working on the ac_cv_* settings in make/MasterInclude.mk so there are some Package build failures because of that. Nonetheless it is encouraging to find that around 80% of the Packages build OK, just not the important ones... :-) david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Wed, 2012-03-28 at 13:02 +0200, Yves Blusseau wrote: > Hi david, i know i never happy > > perhaps we can change > > Logfile = log/buildtoollog > to > Logfile = log/$GNU_TARGET_NAME/buildtoollog > > in conf/buildtool.conf Hi Yves, I know you are right... I did consider making that change initially but it is slightly complex because buildtool.pl currently writes to the logfile *before* picking up the value for "toolchainname", so more of a change to the structure is required. I will look at this at the weekend. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Wed, 2012-03-21 at 12:50 -0700, Mike Noyes wrote: > On 03/20/2012 01:57 PM, davidMbrooke wrote: > -snip- > > I am also in the process of drafting some notes on building for other > > platforms here: > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant > > David, > Great start on this document. > > Everyone, > Anyone with cross-complie experience please review and comment on the > document. Thanks. Thanks Mike. I have now completed the document based on what was in my head. It now describes all the places where the build system has to be configured in order to add a custom toolchain (really only 3 places - some simple config settings in make/MasterInclude.mk, a custom patch for the Linux kernel .config and a custom uClibc .config). I have also started a Discussion page at the same location to track Q&A. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - uClibc 0.9.33 is available - Should we upgrade?
On Sun, 2012-03-25 at 18:15 +0200, KP Kirchdoerfer wrote: > Am 25.03.2012 14:51, schrieb davidMbrooke: > > Hi all, > > > > I am getting build errors for my highly experimental ARM11 toolchain - a > > conflict between GCC and uClibc 0.9.32.1 NPTL code. Looks like there are > > some relevant fixes included in uClibc 0.9.33 which was released 01 Feb > > 2012. > > > > Could we upgrade uClibc? I have tried a quick test and I get a > > *different* error when using 0.9.33, but I'd prefer to work on a fix for > > the "new" error rather than the "old" error. > > Understandable... > Have you tested a x86 build? > > kp I had not tested that, but I have now. With all of our uClibc patches commented out the 0.9.33 uClibc builds OK as part of the x86 toolchain (i486-unknown-linux-uclibc) and a few sample Packages build OK too. I have yet to test a full build of all packages, or to test that it actually runs... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
On Sun, 2012-03-25 at 13:41 +0100, davidMbrooke wrote: > On Sun, 2012-03-25 at 10:42 +0200, KP Kirchdoerfer wrote: > > > > My fault - forgot to commit a common.cfg which points to the correct file. > > > > Can you sow the error for shorewall6? > > > > kp > > Hi kp, > > All is OK now - the same common.cfg error affected shorewall6. > > I am currently rebuilding everything. Hoping for "all green" :-) > > david Hi kp, So shorewall and shorewall6 are indeed OK, however not shorewall-lite and shorewall6-lite (those are the only two failures from a complete re-build). Looks like the same error affects both Packages: install -c init.leaf /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall-lite/etc/init.d/shorewall-lite install: cannot create regular file `/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall-lite/etc/init.d/shorewall-lite': No such file or directory make: *** [shorewall-lite-4.5.1.1/.build] Error 1 make: Leaving directory `/home/leaf/bering-uclibc-next/source/i486-unknown-linux-uclibc/shorewall-lite' install -c init.leaf /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall6-lite/etc/init.d/shorewall6-lite install: cannot create regular file `/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall6-lite/etc/init.d/shorewall6-lite': No such file or directory make: *** [shorewall6-lite-4.5.1.1/.build] Error 1 make: Leaving directory `/home/leaf/bering-uclibc-next/source/i486-unknown-linux-uclibc/shorewall6-lite' In both cases I also see "Installing Redhat/Fedora-specific configuration..." in the logfile. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - uClibc 0.9.33 is available - Should we upgrade?
Hi all, I am getting build errors for my highly experimental ARM11 toolchain - a conflict between GCC and uClibc 0.9.32.1 NPTL code. Looks like there are some relevant fixes included in uClibc 0.9.33 which was released 01 Feb 2012. Could we upgrade uClibc? I have tried a quick test and I get a *different* error when using 0.9.33, but I'd prefer to work on a fix for the "new" error rather than the "old" error. I'm not sure which of our uClibc patches would need to be retained if we upgrade - is it simply that those with 0.9.32 in the name apply (only) to the .32 release and can be retired, whereas the others should be retained? Thanks, david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
On Sun, 2012-03-25 at 10:42 +0200, KP Kirchdoerfer wrote: > > My fault - forgot to commit a common.cfg which points to the correct file. > > Can you sow the error for shorewall6? > > kp Hi kp, All is OK now - the same common.cfg error affected shorewall6. I am currently rebuilding everything. Hoping for "all green" :-) david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - All building OK on x86_64
On Sat, 2012-03-24 at 20:37 +0100, KP Kirchdoerfer wrote: > > Another issue is shorewall. > Latest version 4.5 "improved" install section for BUILD and HOST system. > I'm not shure if I got it right. So can you pls do me a favour and chekc > if works on a Fedora system? I tried with my latest commit to go without > the the underlying build system. If it doesn't work for you, I have to > rethink my approach. > > kp Hi kp, I'm seeing errors creating Packages for shorewall (and shorewall6) :-( Error from buildpacket.pl is: Generating package shorwall cp: cannot stat `/home/leaf/bering-uclibc-next/staging/i486-unknown-linux-uclibc/etc/init.d/shorewall-init': No such file or directory Output from the "install" step running buildtool.pl is: cp init.sh shorewall-4.5.1.1/init.sh mkdir -p /home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall (cd shorewall-4.5.1.1; env PREFIX=/home/leaf/bering-uclibc-next/build/i486-unknown-linux-uclibc/shorewall ./install.sh) Installing Redhat/Fedora-specific configuration... Not setting file owner/group permissions, not running as root. Installing Shorewall Version 4.5.1.1 I wonder if is possible / sensible to force a setting for $HOST when calling install.sh ? I would have thought we should select something which matches the Target rather than the Build host... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - All building OK on x86_64
Hi all, Following another batch of cross-compilation fixes (mawk, linux-atm, dhcpd and radius) I am again seeing an "all green" report from buildall.sh My build platform is Fedora 15 x86_64, so this is a *slightly* better test of cross-compilation than building on a 32-bit x86 platform. Hopefully I haven't broken anything for building on 32-bit. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Sat, 2012-03-24 at 00:40 +0100, KP Kirchdoerfer wrote: > > Yes I'm still on 32-bit. > > kp Hi kp, OK, so that explains why it works for you but not for me. I've realized that compiling for the build host rather than the target host is *exactly* what $(BUILD_CC) is for and I've had some success with mawk by editing the Makefile to use $(BUILD_CC) for the relevant step. Hopefully I can do the same for linux-atm and dhcpd. My current thinking is that the toolchain is working properly. Testing with a more "different" target (like ARM) will help prove that one way or the other. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Fri, 2012-03-23 at 19:02 +0100, KP Kirchdoerfer wrote: > Am 22.03.2012 21:36, schrieb davidMbrooke: > > On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: > > I do seem to have re-introduced a number of build failures (mawk, > > linux-atm, dhcpd) > > Hi David; > > just rebuilded. I don't see any errors... > > Haven't tested buildpackage yet. > > kp Hi kp, Thanks for checking. Are you building on 32-bit x86 by any chance, rather than 64-bit x86_64 like me? For mawk and linux-atm the problem seems to be that they are trying to run executables on the build host as part of the build process, but those executables are intended for the target host... A possible workaround is to run the executables manually, store the output in Git and insert the output into the source tree as part of "make source". That will only work if the output is platform independent though. I'm starting to look at dhcpd (again!) now. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Thu, 2012-03-22 at 20:36 +, davidMbrooke wrote: > > I do seem to have re-introduced a number of build failures (mawk, > linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc > level in the directory structures in some places (specifically for the > include files, which are therefore not being found, hence the build > failures). I'm hunting the cause of that right now. > > david Struggling to spot what is wrong... Andrew: You are perhaps more familiar with toolchain/buildtool.mk Do the results of building the toolchain match what you expect? Seems like we have an extra GNU_TARGET_NAME level in some places... Thanks, david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Wed, 2012-03-21 at 22:21 +, davidMbrooke wrote: > > By the way, I know that buildimage.pl is now broken because of these and > my other changes. Maybe I can fix that tomorrow... > > david buildimage.pl should now be fixed too - at least for i486 builds - and also tools/buildall.sh which wasn't looking in the right place for source/*/buildtool.cfg files. The default behaviour of all the build utilities should therefore be back to where it was before but now there's an option to specify a different toolchain in (conf/buildtool.cfg or on the command line) and the toolchain name is reflected in all the generated directories as a basis for adding further toolchains for other platforms I do seem to have re-introduced a number of build failures (mawk, linux-atm, dhcpd) which is down to a *second* i486-unknown-linux-uclibc level in the directory structures in some places (specifically for the include files, which are therefore not being found, hence the build failures). I'm hunting the cause of that right now. david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Wed, 2012-03-21 at 13:08 +0200, Andrew wrote: > On 21/03/12 12:47, Yves Blusseau wrote: > > One suggestion: it will be great to have a subdirectory in the /build/ > > directory with the name of the toolchain. > > For example: build/i486-unknown-linux-uclibc so we can build multiple > > versions of a package for different architecture. > > > > Yves > > > Yes, and also it'll be good to have subdir in /source/ directory. You guys are never happy, are you? :-} I have now changed the buildtool scripts and config files so that: source/ -> source/i486-unknown-linux-uclibc/ build/ -> build/i486-unknown-linux-uclibc/ and also: conf/installed -> conf/i486-unknown-linux-uclibc/installed since we need to track what has been built on a per-toolchain basis. Seems to work OK for me from limited testing but I suspect some buildtool operations will not work. Please check and report any problems. By the way, I know that buildimage.pl is now broken because of these and my other changes. Maybe I can fix that tomorrow... david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Mon, 2012-03-19 at 22:56 +, davidMbrooke wrote: > On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: > > 18.03.2012 19:44, davidMbrooke пишет: > > > > > > I'm also thinking about what the "ARCH" arguments to buildtool.pl and > > > buildpacket.pl should look like. Maybe we just use the GCC "target > > > triplet" syntax, so e.g. > > > i486-pc-linux-uclibc for the Bering-uClibc 4.x platform > > > armv6-unknown-linux-uclibcfor the Raspberry pi > > > > > > In other words, "buildtool.pl --target=i486-pc-linux-uclibc build ..." > > > rather than "buildtool.pl --arch=i386 build ..." > > > > > > Thoughts? > > > > > > David > > AFAIK there is no difference between '-pc-linux-uclibc' and > > '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use > > i486-unknown-linux-uclibc arch. > > Thanks Andrew. I therefore propose to identify the different toolchains > with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead > of "ARCH" strings like i386. > I will add a "-t toolchain" argument to buildtool.pl and default this to > i486-unknown-linux-uclibc so as to preserve the current behaviour. > > I have these changes working in my development environment now (plus a > few other changes to prepare for non-x86 platforms) but I want to review > those again before adding to Git (hopefully tomorrow). > > david OK, changes now pushed to the SourceForge Git. Hopefully I have preserved the existing behaviour by default but now buildtool.pl has a "-t toolchainname" argument and buildpacket.pl has a "--toolchain toolchainname" argument. Both default to the (new) "toolchain" setting in conf/buildtool.conf Since the name of the toolchain directory has changed (was i386, now i486-unknown-linux-uclibc) any 'next' developers will need to re-build their toolchain after they pull my latest changes. I am also in the process of drafting some notes on building for other platforms here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
On Sun, 2012-03-18 at 23:59 +0200, Andrew wrote: > 18.03.2012 19:44, davidMbrooke пишет: > > > > I'm also thinking about what the "ARCH" arguments to buildtool.pl and > > buildpacket.pl should look like. Maybe we just use the GCC "target > > triplet" syntax, so e.g. > > i486-pc-linux-uclibc for the Bering-uClibc 4.x platform > > armv6-unknown-linux-uclibcfor the Raspberry pi > > > > In other words, "buildtool.pl --target=i486-pc-linux-uclibc build ..." > > rather than "buildtool.pl --arch=i386 build ..." > > > > Thoughts? > > > > David > AFAIK there is no difference between '-pc-linux-uclibc' and > '-unknown-linux-uclibc' suffixes, and IMHO it'll be safe to use > i486-unknown-linux-uclibc arch. Thanks Andrew. I therefore propose to identify the different toolchains with "GNU_TARGET_NAME" strings like i486-unknown-linux-uclibc, instead of "ARCH" strings like i386. I will add a "-t toolchain" argument to buildtool.pl and default this to i486-unknown-linux-uclibc so as to preserve the current behaviour. I have these changes working in my development environment now (plus a few other changes to prepare for non-x86 platforms) but I want to review those again before adding to Git (hopefully tomorrow). david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - Are we agreed that 'next' will be released as Bering-uClibc 5.x ?
Hi all, I plan to start making changes to the Wiki pages for 'next', adding info on cross-compiling and giving some more thought as to which pages are common to all Bering-uClibc versions (maybe the Hints and Tips on Git usage, for example?) and which are version-specific. Before I create more pages I'd like us to agree how we plan to identify 'next' when it finally gets released. I see that kp has started referring to 5.0 in Trac, which is OK by me. I presume that 'next' was only ever intended to be a "working title". Should I change the existing 'next' Wiki pages to reflect a BuC 5.x naming convention (easily accomplished with the "move" facility in MediaWiki, which makes the old name redirect to the new name) and create new pages with 5.x names? david -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - dhcpd build fixed
On Sun, 2012-03-18 at 17:18 +0100, Yves Blusseau wrote: > Really good news ! > > Thanks a lot david an kp ! > > When do you think you will merge the 'next' branch onto 'master' ? > > Yves Hi Yves, Personally I'd like to see us prove out cross-compiling for another platform before we take the brave step of merging the 'next' branch. As per my mail a few minutes ago we need think some more about about the most appropriate naming of directories and the changes to the build scripts. If we can all agree how to implement formal support for cross-compiling I should be able to make the necessary changes to buildtool / buildpacket in the next couple of weeks. David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - Logic for choosing the right value for "ARCH"
Hi all, I'm trying to understand the valid values for our various "architecture" variables in MasterInclude.mk (ARCH, KARCHS, GNU_ARCH, GNU_TUNE) in the context of cross-compiled builds. I'm OK with GNU_ARCH and GNU_TUNE because I can see those are driving the setting of -march and -mtune for GCC and they are covered in the GCC documentation (http://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html) For Bering-uClibc 4.x our make/MasterInclude.mk specifies: -march=$(GNU_ARCH) -mtune=$(GNU_TUNE) where: $(GNU_ARCH) = i486 $(GNU_TUNE) = pentiumpro Then there is KARCHS, where we have multiple variants (i686, i486, geode). This is effectively just a way to have different Kernels based on different Kernel .config settings, and hence different kernel Modules and different Initrd files. I'm OK with this since I understand how we added support for KARCHS in Bering-uClibc 4.x and how the Kernel .config patching works. In the Kernel .config we have settings like CONFIG_M686=y, for i686. The bit I don't understand (or at least didn't, until I started composing this mail, several hours ago) is ARCH, which is set to "i386" for Bering-uClibc 4.x. Based on my investigations today it looks like ARCH is fundamentally a Kernel configuration setting and the value of ARCH must match the name of a directory under e.g. linux-3.2.11/arch/ - with a couple of special cases accommodated in linux-3.2.11/Makefile, for example i386 and x86_64 both relate to directory linux-3.2.11/arch/x86/. Within the Kernel .config for ARCH:=i386 we have CONFIG_X86=y and then some adjustments for i686, geode etc. as part of KARCHS. There is also an "architecture" selection for uClibc which we seem to match to the value of ARCH. For Bering-uClibc 4.x we configure uClibc with TARGET_ARCH=i386 but we also specify TARGET_SUBARCH=i486 and CONFIG_486=y. That means that our "i386" toolchain is actually an *i486* toolchain, which I think we all understand and we accept that we only build one set of LRP executables for x86 devices. My primary motivation is to understand what all these variables should be set to for non-x86 platforms such as ARM. For example the Raspberry Pi has a Broadcom BCM2835 chip containing an ARM1176JZFS CPU. That is part of the ARM11 processor family built on the ARMv6 architecture, so for GCC we'd want to set -march=armv6 (or possibly -march=armv6zk) and then maybe -mtune=arm1176jzf-s. In terms of Kernel configuration we'd want to specify ARCH:=ARM (and hence CONFIG_ARM=y) and then CONFIG_ARCH_BCMRING=y (which looks to be the equivalent of e.g. CONFIG_M686=y or CONFIG_MGEODE_LX=y so would be configured via KARCHS). I'm therefore thinking, for the Raspberry Pi: ARCH = arm KARCHS= bcmring GNU_ARCH = armv6 GNU_TUNE = arm1176jzf-s In the uClibc .config I'd want to set TARGET_arm=y, TARGET_ARCH="arm" and CONFIG_ARM1176JZF_S=y (which then compiles uClibc with -march=armv6 and -mtune=arm1176jzf-s based on the settings in Rules.mak). That means we'd have an "armv6" toolchain rather than a generic "arm" toolchain. I'm also thinking about what the "ARCH" arguments to buildtool.pl and buildpacket.pl should look like. Maybe we just use the GCC "target triplet" syntax, so e.g. i486-pc-linux-uclibc for the Bering-uClibc 4.x platform armv6-unknown-linux-uclibcfor the Raspberry pi In other words, "buildtool.pl --target=i486-pc-linux-uclibc build ..." rather than "buildtool.pl --arch=i386 build ..." Thoughts? David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - dhcpd build fixed
Hi all, I believe I have fixed the build failure for dhcpcd on 'next'. It's the usual story - several hours' work for just a couple of lines in buildtool.mk :-) I managed to turn up a reference to setting CC for Solaris (in dhcp-4.2.2/README) which also works for us and enables the included copy of bind to be cross-compiled. There were also a lot of problems with #define macros being expanded inconsistently in the bind include files coming in from staging/usr/include/. I fixed those by forcing the ../bind/include/ files to be referenced first. I also fixed djbdns earlier by forcing make to run single-threaded. In theory that means that everything should build cleanly. I'm running a full rebuild now to check. David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
On Fri, 2012-03-16 at 18:54 +0100, KP Kirchdoerfer wrote: > Am 16.03.2012 18:43, schrieb davidMbrooke: > > > > kp: For djbdns I am getting an error that you also had on 28 Jan. Do you > > have a fix identified for this error: > > > > ./compile socket_accept6.c > > socket_connect6.c:9:21: fatal error: haveip6.h: No such file or > > directory > > > > Unfortunately no - djbdns and dhcpd are the only packages failing > currently on my build system. > > kp Hi kp, OK, I thought it was worth a try... :-) I will investigate djbdns tomorrow. I have found and fixed the error I was getting with linux-atm (bug in upstream qgen/Makefile.in). I have also tracked down the error I was getting with squid - missing libtool-ltdl-devel RPM on my build host. Have added a note to the Wiki. I think that means I am now seeing the same build behaviour as you and Andrew. David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
On Wed, 2012-03-14 at 20:58 +0100, KP Kirchdoerfer wrote: > Am 13.03.2012 23:33, schrieb davidMbrooke: > > Hi all, > > > > Now that Andrew and kp have done all the hard work on "next" I have > > finally found time to try to build it. I'm getting a few build errors > > (on Fedora 15, x86_64). > > > >>From previous mails to this list I can see that some of these errors are > > "expected" but others are not. Some of the problems I am seeing have > > previously been discussed in the context of the /lib/ld-uClibc.so.0 > > symbolic link. For "next" I understand that link does not *need* to > > exist, but can the presence of the link still cause problems? > > > > I am getting build failures for: > > djbdns > > squid > > mawk > > linux-atm > > libdigest-sha1-perl > > dhcpd (expected) > > > > I will of course investigate and make corrections. In particular for > > dhcpd, since I am probably responsible for that build failure anyway :-) > > > > Thanks to everyone who has contributed to "next" so far. Like others I > > am really looking forward to running it on ARM. > > > > david > > Hi David; > > Andrew deserves the honour for the next branch, he did a really good > job, so it was easy to install after a few hickups and testdrive, which > is fun cause in my environment it's running smoother even in alpha state > than 4.2 :) > > As Andrew said libdigest-sha1-perl should work today, at least it does > for me. > I haven't deleted the symbolic link for ld-uClibc.so.0 to compile the > packages (which may explain djbdns build failure from time to time - > will keep an eye on this one). > > I'll update dnsmasq to version 2.60 in next branch. It works as expected > on my box - without further changes to my dnsmasq.conf. > With 2.60 another player for DHCPv6 gets into the arena, you may look > into it and compare it with dibbler etc.. It even has (limited(?)) > support for router advertisements... > (http://thekelleys.org.uk/dnsmasq/CHANGELOG) > > kp Thanks Andrew and kp, I rebuilt from scratch on Wednesday after deleting the link. It had no effect. libdigest-sha1-perl is indeed better now (I got a buildpacket failure but I will re-build today to confirm I am using the latest code from Git). The news of IPv6 support in dnsmasq is surprising to me but very encouraging for enhanced IPv6 support in a small footprint. kp: For djbdns I am getting an error that you also had on 28 Jan. Do you have a fix identified for this error: ./compile socket_accept6.c socket_connect6.c:9:21: fatal error: haveip6.h: No such file or directory Thanks, David -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] BuC next - Confirmation of /lib/ld-uClibc.so.0 symlink requirements
Hi all, Now that Andrew and kp have done all the hard work on "next" I have finally found time to try to build it. I'm getting a few build errors (on Fedora 15, x86_64). >From previous mails to this list I can see that some of these errors are "expected" but others are not. Some of the problems I am seeing have previously been discussed in the context of the /lib/ld-uClibc.so.0 symbolic link. For "next" I understand that link does not *need* to exist, but can the presence of the link still cause problems? I am getting build failures for: djbdns squid mawk linux-atm libdigest-sha1-perl dhcpd (expected) I will of course investigate and make corrections. In particular for dhcpd, since I am probably responsible for that build failure anyway :-) Thanks to everyone who has contributed to "next" so far. Like others I am really looking forward to running it on ARM. david -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Fwd: Re: Screen captures
On Mon, 2011-11-14 at 14:41 -0600, Charles Steinkuehler wrote: > On 11/14/2011 1:38 PM, KP Kirchdoerfer wrote: > > Am Montag, 14. November 2011, 18:44:13 schrieb Charles > > Steinkuehler: > >> I got some screen captures forwarded to me by Rich Bowen of > >> SourceForge. > >> > >> I'm not sure if anyone wants to do anything with these, or if > >> you'd like me to post them to the site somewhere. > > > > If they show anything meaningful, Mike may add (one of) them to our > > profile page. > > > > And probably they are useful for the wiki documentation and David > > can take care about...? > > Oops...I forgot the list strips attachments. I've put the three files > on-line for reference: > > http://neo.steinkuehler.net/leaf/ Hi, We do have one screen capture in the Wiki already, referenced at http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_User_Guide_-_Appendices_-_Overview_of_the_Startup_Sequence#Step_2:_Boot_Loader but more are always welcome. I will upload these to the Wiki as "media" files, after which they will show up at: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Special:ListFiles dMb -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Additional Perl Modules from CPAN - Add to perl.lrp ?
On Thu, 2011-11-03 at 22:25 +0100, KP Kirchdoerfer wrote: > Am Donnerstag, 3. November 2011, 18:50:47 schrieb davidMbrooke: > > Hi, > > > > Just wondering if anyone has got a preferred approach for handling Perl > > modules (.pm files) which are required for Perl-based LRP Packages but > > which are: > >- Not included in the standard Perl distribution > >- Available from CPAN (http://www.cpan.org/) > >- Potentially used by several Packages > > > > Main options seem to be: > >1. Include them in perl.lrp > > - This currently has Socket6.pm added > > - It is firmly aimed at supporting "Shorewall" though > >2. Include them in 'package'.lrp and hope that no other Package needs > > them (or include them in multiple Packages?) > >3. Include them in an optional Package called e.g. cpan.lrp which > > contains numerous "non-standard" but (potentially) shared Perl modules > >4. Include them in their own individual Packages > > > > I don't favour #1 (too much overhead if just using Perl for Shorewall) > > or #4 (too much work for me :-) but I can't easily decide between #2 and > > #3. > > I vote for #3. > > We've made a similar decision while moving from Bering to Bering-uClibc, > where we decoupled libs from the packages built against libs, because it > was too confusing and you had to install a package only because of the libs > included, on other times the libs has been packaged twice or three times. > > I agree that #4 may too much work and may too much packages. > > kp kp, Erich, Andrew, Thanks for the feedback. Erich: Agree that an LRP dependency mechanism is highly desirable. We have this logged in Trac https://sourceforge.net/apps/trac/leaf/ticket/2 with a high-level design sketched out already. Perhaps you could review / commment? My conclusion on Perl modules is "it depends". If a module is only likely to be required for one application it should be bundled into the .lrp for that application. If it is genuinely "shared" then it should be separate (either standalone or in e.g. cpan.lrp). I will add some notes to the "Development Policies and Guidelines" page in the Wiki. Note that compiling a new Perl module isn't as easy as I was expecting. Those modules which use "MakeMaker" (i.e. you run "perl Makefile.PL") pick up a lot of the build host Perl installation directories rather than the target / staging directories, and since perl.lrp is specifically aimed at supporting Shorewall it is missing some of the "standard" files. More thought required... dMb -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Additional Perl Modules from CPAN - Add to perl.lrp ?
Hi, Just wondering if anyone has got a preferred approach for handling Perl modules (.pm files) which are required for Perl-based LRP Packages but which are: - Not included in the standard Perl distribution - Available from CPAN (http://www.cpan.org/) - Potentially used by several Packages Main options seem to be: 1. Include them in perl.lrp - This currently has Socket6.pm added - It is firmly aimed at supporting "Shorewall" though 2. Include them in 'package'.lrp and hope that no other Package needs them (or include them in multiple Packages?) 3. Include them in an optional Package called e.g. cpan.lrp which contains numerous "non-standard" but (potentially) shared Perl modules 4. Include them in their own individual Packages I don't favour #1 (too much overhead if just using Perl for Shorewall) or #4 (too much work for me :-) but I can't easily decide between #2 and #3. Thanks, dMb -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
On Wed, 2011-11-02 at 15:36 +0200, Andrew wrote: > 01.11.2011 21:34, davidMbrooke пишет: > > On Tue, 2011-11-01 at 21:21 +0200, Andrew wrote: > >> 01.11.2011 20:11, KP Kirchdoerfer пишет: > >>> Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: > > > > The Yocto Project has the backing of The Linux Foundation. There is an > > overview and Quick Start guide at > > http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html > > > > dMb > > > At first look on documentation - it looks like enough complex system > that is covered by enough simple front-end - and IMHO such type of > systems usually are hard in customization for needed objectives. > Integrated qemu for testing looks good, but I suspect that it's working > only with GUI. > If you use it, I have a question: it has possibility to work in this > buildenv w/o GUI, just from CLI terminal? Even w/o all features, just > package building/editing? I have now done a little testing with Yocto Project 1.1. It works OK though it is slow to build the default configuration (because it is building so much - including an X11 GUI for the embedded device!). The developers do seem to have thought about customization of the toolchain and support add-on "layers" which can be managed separately from the underlying build system. This means that updates can be integrated easily - we would not need to fork the Yocto Project tools but would develop and maintain an add-on "layer". It does seem possible to use it from a CLI terminal - the command "bitbake" (equivalent of our buildtool/buildpacket/buildimage) runs from the command line and can build anything from a single Package to a whole Image. See also http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#platdev-appdev Switching to this would be big change though. dMb -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] BuC-next branch
On Tue, 2011-11-01 at 21:21 +0200, Andrew wrote: > 01.11.2011 20:11, KP Kirchdoerfer пишет: > > Am Dienstag, 1. November 2011, 00:06:50 schrieb Andrew: > > > > Not a proposal, just a quick idea: it might be easier longterm to fork > > again from buildroot and adjust it to our needs, instead of hacking a hack > > once more. AFAIK David looked into OPenyoko(?), maybe he'll has something > > to add about his findings... > If somebody can move current infrastructure (.lrp creation, etc) to > other building environment and it'll be enough useful and simple (not > worse than current buildenv) - I haven't any votes against this. In any > case, cleaned/ported packages can be moved to new building system easier. That would be http://www.yoctoproject.org/ which does look interesting. I did some tests with the 1.0 release and hit some problems but 1.1 is out since October. I will download now and check if the new version works better. The Yocto Project has the backing of The Linux Foundation. There is an overview and Quick Start guide at http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html It would need to be modified to create .lrp files (rather than .rpm or .deb) and I do not know how difficult that might be. dMb -- RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Separate Git branch for 4.1-fixes ?
On Tue, 2011-10-18 at 20:41 +0200, KP Kirchdoerfer wrote:
> Am Sonntag, 16. Oktober 2011, 10:38:08 schrieb davidMbrooke:
> > Hi kp,
> >
> > Just wondering if we're planning to have a "4.1-fixes" branch in Git
> > like we did for 4.0, with the changes for 4.1.1 going into there as well
> > as the master?
>
> Hi David;
>
> sorry for late reply, was away for three days...
No need to apologize.
> I don't think we do need a 4.1-fixes branch, because the current master
> contains just fixes and non-intrusive updates for 4.1 (which will become
> 4.1.1 sometimes later). In fact nearly each change results in packages
> which are more or less a drop-in replacement for the 4.1 packages (openssl
> update is a bit different, it affects all packages that are build with
> openssl support).
>
> So unless anyone wants to change the kernel, which I don't think will
> happen in the next weeks, master is similar to 4.1-fixes.
>
> If this approach slowes down development, I'll of course vote to create
> 4.1-fixes ASAP :)
OK, so unless / until we add something which belongs in 4.2 we can
continue without a separate branch. I am happy with that.
> On the other hand, I'm currently thinking about the idea to build a "later"
> branch to testdrive uClibc 0.9.32. I haven't tested the already built
> packages and images in production, but a first try looks promising (see Trac
> ticket #36).
>
> But I'd like to see, what Andrew thinks about it ("how do we merge between
> master and a "later" branch without having too much working maintaing both?
> etc).
>
> kp
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Separate Git branch for 4.1-fixes ?
Hi kp, Just wondering if we're planning to have a "4.1-fixes" branch in Git like we did for 4.0, with the changes for 4.1.1 going into there as well as the master? dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] igitt igitt igitt
On Wed, 2011-09-28 at 18:11 +0200, KP Kirchdoerfer wrote: > > I suggest that we freeze 4.1 for the rc1 and I'll try to accomplish that > task over the weekend. OK with me. > > David, there is one task open - license.lrp should be added to the images > (leaf.cfg). I know we are not finished adding a license tag to all packages > but for it will be a start. Agreed. I have just done this. We can add the remaining tags later; no hurry. > About packages with different source packages and (eventually) various > licenses (e.g. initrd) I suggest to support something like > License = GPL-2, ISC > > Maybe that's enough - given that a very few will even follow the links and > read the license :) I know, but at least we comply with the terms of the licenses, which helps me sleep at night :-) > > Opinions? > > kp Many thanks for your efforts adding so many of the license tags. I had planned to help, but recently there have been other priorities. dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] www.(de.)kernel.org is down
On Sun, 2011-09-18 at 14:00 +0200, KP Kirchdoerfer wrote: > Am Sonntag, 18. September 2011, 13:38:27 schrieb davidMbrooke: > > On Sun, 2011-09-18 at 11:42 +0100, davidMbrooke wrote: > > > On Sat, 2011-09-17 at 17:41 +0300, Andrew wrote: > > > > Kernel was taken from kernel.org because kernel.org was one of > > > > constantly-available resources and because kernel is enough > > > > heavy - just to make git/cvs repo smaller. Another things that > > > > are taken from internet - gcc/binutils. > > > > I added 2.6.35.14 into git tree. IMHO it isn't too much place > > > > for discussions here - in any case, missed source shouldn't be > > > > a showstopper for developers; decision will be done when > > > > kernel.org backs online - but I think that sources were laid > > > > into tree just because they are already into git tree :) > > > > > > Thanks Andrew. That fixed it for me. > > > > > > dMb > > > > I spoke to soon. The build env is OK but the kernel compile fails > > because module-init-tools-3.12.tar.bz2 also comes from kernel.org > > > > Anyone have a copy of that they can upload? > > David, > the tarball is in git, you just need to change the "Server" line to > localrepo. > > kp Thanks kp. Done, and working OK now. I have checked-in the updated module-init-tools/buildtool.cfg. dMb -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] www.(de.)kernel.org is down
On Sun, 2011-09-18 at 11:42 +0100, davidMbrooke wrote: > On Sat, 2011-09-17 at 17:41 +0300, Andrew wrote: > > Kernel was taken from kernel.org because kernel.org was one of > > constantly-available resources and because kernel is enough heavy - just > > to make git/cvs repo smaller. Another things that are taken from > > internet - gcc/binutils. > > I added 2.6.35.14 into git tree. IMHO it isn't too much place for > > discussions here - in any case, missed source shouldn't be a showstopper > > for developers; decision will be done when kernel.org backs online - but > > I think that sources were laid into tree just because they are already > > into git tree :) > > Thanks Andrew. That fixed it for me. > > dMb I spoke to soon. The build env is OK but the kernel compile fails because module-init-tools-3.12.tar.bz2 also comes from kernel.org Anyone have a copy of that they can upload? Thanks, dMb -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] www.(de.)kernel.org is down
On Sat, 2011-09-17 at 17:41 +0300, Andrew wrote: > 17.09.2011 16:43, davidMbrooke пишет: > > Hi, > > > > I'm trying to do a complete rebuild and "build buildenv" is failing > > almost right away. In log/buildtoollog I get: > > buildtool::Download::download:file key: linux-2.6.35.13.tar.bz2 > > --2011-09-17 13:33:50-- > > http://www.de.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.35/linux-2.6.35.13.tar.bz2 > > Resolving www.de.kernel.org... failed: Name or service not known. > > wget: unable to resolve host address “www.de.kernel.org” > > > > When I try to browse www.kernel.org I get a message saying "Down for > > maintenance". Presumably this is related to the recent security issues > > at kernel.org. > > > > IMHO we would be better off storing the kernel source as part of our own > > repository. I deleted all of my downloaded source so I don't now have a > > copy of the kernel source to upload. > > > > Does anybody else have a copy of the 2.6.35.13 source, and does anyone > > disagree that we should maintain our own copy? > > > > Thanks, > > davidMbrooke > > > Kernel was taken from kernel.org because kernel.org was one of > constantly-available resources and because kernel is enough heavy - just > to make git/cvs repo smaller. Another things that are taken from > internet - gcc/binutils. > I added 2.6.35.14 into git tree. IMHO it isn't too much place for > discussions here - in any case, missed source shouldn't be a showstopper > for developers; decision will be done when kernel.org backs online - but > I think that sources were laid into tree just because they are already > into git tree :) Thanks Andrew. That fixed it for me. dMb -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] www.(de.)kernel.org is down
Hi, I'm trying to do a complete rebuild and "build buildenv" is failing almost right away. In log/buildtoollog I get: buildtool::Download::download:file key: linux-2.6.35.13.tar.bz2 --2011-09-17 13:33:50-- http://www.de.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.35/linux-2.6.35.13.tar.bz2 Resolving www.de.kernel.org... failed: Name or service not known. wget: unable to resolve host address “www.de.kernel.org” When I try to browse www.kernel.org I get a message saying "Down for maintenance". Presumably this is related to the recent security issues at kernel.org. IMHO we would be better off storing the kernel source as part of our own repository. I deleted all of my downloaded source so I don't now have a copy of the kernel source to upload. Does anybody else have a copy of the 2.6.35.13 source, and does anyone disagree that we should maintain our own copy? Thanks, davidMbrooke -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Design Article
On Sat, 2011-08-06 at 22:10 -0700, Mike Noyes wrote: > Open Embedded: An alternative way to build embedded Linux distributions > http://www.eetimes.com/design/embedded/4218490/Open-Embedded--An-alternative-way-to-build-embedded-Linux-distributions > Thanks Mike. Interesting. I have started looking at the Yocto Project http://www.yoctoproject.org/ which is based on OpenEmbedded, but I haven't got very far. See also http://lwn.net/Articles/437929/ which has a quote saying they'd "like to see more community projects, like OpenWRT for example, switching to use Yocto". LEAF is a *bit* like OpenWRT... dMb -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] preparation for 4.1-beta1?
On Sun, 2011-07-24 at 01:39 +0200, KP Kirchdoerfer wrote: > David, do we need to wait for your work on isc-dhcp? I guess it can be > done > later... Yes, no need to wait. The Package is almost ready but I need to do some testing - with both DHCPv4 and DHCPv6... dMb -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Package name / rename, Debian patches etc.
On Mon, 2011-07-11 at 21:55 +0200, Erich Titl wrote: > Hi David > > on 11.07.2011 21:15, davidMbrooke wrote: > > Hi, > > > > I am looking at updating dhcpd.lrp to add the option of IPv6 (i.e. > > DHCPv6 Server) support. Right now we build dhcp.lrp from ISC DHCP 2.0pl5 > > plus the -19.1 Debian patches, now more than 10 years old. > > That is real old, I ported 3.x a long time ago to Bering, because I felt > I needed it, the vanilla stuff was sufficient for me those days. > > > > > IPv6 support was added in the ISC DHCP 4.x versions, so we need to > > upgrade to at least 4.0 and ideally at least 4.1. The latest stable > > upstream version is currently 4.2. > > > > I have some questions about how closely we should try to follow what > > Debian does: > >- Debian "squeeze" ships with ISC DHCP 4.1.1-P1-15+squeeze2 (i.e. > > upstream 4.1.1-P1 with the -15+squeeze2 Debian patches. Should we > > continue to apply the Debian patches or revert to the "vanilla" upstream > > and remove the Debian changes? > > Again, what do these patches do? The way I understand the Debian way is, > that they add patches to their source tree before committing fixes to > upstream. While I understand that motive I'd rather stick to the vanilla > version unless there is a real need to follow the Debian way (there may > be other too though). > > >- Debian have changed the Package name to isc-dhcp-server, presumably > > to distinguish it from other software options for a DHCP server (and to > > distinguish it from -relay and -client). I was already thinking that > > adding an "isc" prefix was a good idea before I found that Debian had > > done it. However, if we do the same then "dhcpd.lrp" will become e.g. > > "isc-dhcp-server.lrp" which may confuse some users. > > Do we have a name collision somewhere? Is there another dhcpd or dhcp > package? Should we rather sack pump? > > > cheers > > Erich Hi Erich & kp, I was thinking that some users might miss the Debian "flavouring" but from kp's analysis that the changes are (mainly) back-ports of security patches that probably is not the case. My personal preference is for the latest, vanilla upstream versions, so we have 3 votes there. My focus right now is on DHCPv6, and server rather than client. There are certainly other DHCPv6 server package options: - Dibbler http://klub.com.pl/dhcpv6/ (which we have already as dibbler-server.lrp) - Wide-DHCPv6 http://sourceforge.net/projects/wide-dhcpv6/ My experience from testing Dibbler server and ISC DHCPv6 server is that DHCPv6 is immature technology and each implementation has strengths and weaknesses, so we probably want to offer multiple alternatives. Naming the package isc-dhcp-server emphasizes which DHCP code base is being used, but we can stick with dhcpd.lrp - at least for now. dMb -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Package name / rename, Debian patches etc.
Hi, I am looking at updating dhcpd.lrp to add the option of IPv6 (i.e. DHCPv6 Server) support. Right now we build dhcp.lrp from ISC DHCP 2.0pl5 plus the -19.1 Debian patches, now more than 10 years old. IPv6 support was added in the ISC DHCP 4.x versions, so we need to upgrade to at least 4.0 and ideally at least 4.1. The latest stable upstream version is currently 4.2. I have some questions about how closely we should try to follow what Debian does: - Debian "squeeze" ships with ISC DHCP 4.1.1-P1-15+squeeze2 (i.e. upstream 4.1.1-P1 with the -15+squeeze2 Debian patches. Should we continue to apply the Debian patches or revert to the "vanilla" upstream and remove the Debian changes? - Debian have changed the Package name to isc-dhcp-server, presumably to distinguish it from other software options for a DHCP server (and to distinguish it from -relay and -client). I was already thinking that adding an "isc" prefix was a good idea before I found that Debian had done it. However, if we do the same then "dhcpd.lrp" will become e.g. "isc-dhcp-server.lrp" which may confuse some users. Personally I think the rename is a good idea but I am not sure about the Debian patches. What do others think? davidMbrooke -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote branch
On Sat, 2011-06-25 at 18:33 +0200, KP Kirchdoerfer wrote: > > Hi David > > ok, done. 4.0.1 deleted, 4.0-fxies created. > Please adjust your local git. You may need to delete 4.0.1 locally and add > the > tracking command for 4.0-fixes, don't know... Don't used any magic tricks as > Andrew can do :) > > kp Hi kp, Like you I am not sure of all the Git magic spells yet so I deleted everything, re-cloned the bering-uclibc repository and re-created my tracking branch. Looks fine. I am happy with the branch name now :-) Where we are applying bug-fixes for 4.0.1 we also need to apply those to the master branch so that they are included in 4.1. Unless Git has some clever way to do that we presumably need to just make the edits separately in each branch. dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote branch
On Sat, 2011-06-25 at 17:15 +0200, KP Kirchdoerfer wrote: > HI David; > > Am Samstag, 25. Juni 2011, 14:32:38 schrieb davidMbrooke: > > On Sat, 2011-06-25 at 12:53 +0200, KP Kirchdoerfer wrote: > > > Anyway I'd like test a bit further, so if David can just a a change, so > > > that I can see what happens > > > > > > I will update the wiki once we have a stable layout. > > > > > > kp > > > > Hi kp, > > > > I have just pushed a commit to the 4.0.1 branch - a small change to file > > bering-uclibc4/buildtool/repo/linux/Bering-2.6.35.11.config to add four > > USB-to-Ethernet driver Modules. > > > > Depending on how you created the new branch you might be missing the > > configuration to pull changes down from the remote branch to your local > > branch. Here is what I see: > > > > $ git remote show origin > > * remote origin > > Fetch URL: > > ssh://davidmbro...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc > > Push URL: > > ssh://davidmbro...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc > > HEAD branch: master > > Remote branches: > > 4.0.1 tracked > > master tracked > > Local branches configured for 'git pull': > > 4.0.1 merges with remote 4.0.1 > > master merges with remote master > > Local refs configured for 'git push': > > 4.0.1 pushes to 4.0.1 (up to date) > > master pushes to master (up to date) > > > > If you have the same last 6 lines you are all set, but maybe you are > > missing "4.0.1 merges with remote 4.0.1"? > > Yes I did :) > > > >From my research, the "-u" argument to "git push" when creating the > > > > remote branch from a local branch seems to be important. For example: > >git push -u origin 4.0.1:refs/heads/4.0.1 > > > > If you missed that out you can now create the same effect with: > >git branch --set-upstream 4.0.1 origin/4.0.1 > > -u and --set-upstream are synomyms for the same option; not shure if it can > done in one step; guess I'll document as two - that worked for me :) > > Will delete 4.0.1, create 4.0-fixes, (re-)add content and of course document. > > kp Hi kp, >From what I read, if you specify "-u" (or "--set-upstream") when you run "git push" to send the local branch to the remote repository that should be all you need to do. The second command is only to fix things afterwards, if you omit the argument to "git push". I can re-add the .config changes for the USB-to-Ethernet adaptors if you like, as a further test after you re-create the branch with your content. Should be a good test for your local branch getting updated from the remote. dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote branch
On Sat, 2011-06-25 at 12:53 +0200, KP Kirchdoerfer wrote: > Anyway I'd like test a bit further, so if David can just a a change, so that > I > can see what happens > > I will update the wiki once we have a stable layout. > > kp Hi kp, I have just pushed a commit to the 4.0.1 branch - a small change to file bering-uclibc4/buildtool/repo/linux/Bering-2.6.35.11.config to add four USB-to-Ethernet driver Modules. Depending on how you created the new branch you might be missing the configuration to pull changes down from the remote branch to your local branch. Here is what I see: $ git remote show origin * remote origin Fetch URL: ssh://davidmbro...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc Push URL: ssh://davidmbro...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc HEAD branch: master Remote branches: 4.0.1 tracked master tracked Local branches configured for 'git pull': 4.0.1 merges with remote 4.0.1 master merges with remote master Local refs configured for 'git push': 4.0.1 pushes to 4.0.1 (up to date) master pushes to master (up to date) If you have the same last 6 lines you are all set, but maybe you are missing "4.0.1 merges with remote 4.0.1"? >From my research, the "-u" argument to "git push" when creating the remote branch from a local branch seems to be important. For example: git push -u origin 4.0.1:refs/heads/4.0.1 If you missed that out you can now create the same effect with: git branch --set-upstream 4.0.1 origin/4.0.1 I found this page useful: http://postgresql.1045698.n5.nabble.com/Creating-new-remote-branch-in-git-td4475029.html dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote branch
On Sat, 2011-06-25 at 12:23 +0200, Erich Titl wrote: > Hi KP > > on 24.06.2011 20:31, KP Kirchdoerfer wrote: > > Hi; > > > > just created the remote branch 4.0.1 > > > > This branch is intended to work fixes for 4.0.1. > > I've currently only > > - updated webconf to fix Trac tickets #50, #51 and #52 > > What are those, I am (trying) working on webconf as soon as all this > confusion with the repository is over. Hi Erich, See https://sourceforge.net/apps/trac/leaf/report/6 for details of all the Trac tickets. > > - fixed bug in hash shaper (crash on initialization more than 9 networks > > up to > > /24 width) > > and removed /bin directory. > > > > Feel free to add some bugfixes for 4.0.1 as well :) > > > > Note: It has still the old layout (bering-uclibc4). > > This is confusing, could we stick to one single layout? Not really. The 4.0.1 branch is a snapshot of how the Git repository looked when 4.0 was released, and at that time we had the old directory structure. > > > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_- > > _Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM#Remote_Branches > > I am not sure we want to work on many different branches, unless one > goes in a completely different direction. Working on many branches just > generates (at least at my end) confusion about the merging process and > my recent experience has not made me really confident. > > So apparently there is more than one layout, which one is the one we > should stick to? > Which branch should be the one to work on? The "master" branch in the leaf/bering-uclibc repository should be used for all new work. This will be released as 4.1-beta1 and then 4.1, and then 4.2 etc. Only if you are *specifically* fixing a *minor* bug in 4.0 which needs to be released in 4.0.1 should you work on the 4.0.1 branch. > > cheers > > Erich You can probably just ignore the new branch. It is mostly for kp and me to use to check we understand how branches (especially remote branches) work. dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote branch
On Fri, 2011-06-24 at 20:31 +0200, KP Kirchdoerfer wrote: > Hi; > > just created the remote branch 4.0.1 > > This branch is intended to work fixes for 4.0.1. > I've currently only > - updated webconf to fix Trac tickets #50, #51 and #52 > - fixed bug in hash shaper (crash on initialization more than 9 networks up > to > /24 width) > and removed /bin directory. > > Feel free to add some bugfixes for 4.0.1 as well :) > > Note: It has still the old layout (bering-uclibc4). > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_- > _Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM#Remote_Branches > > should us help to work with a remote branch. > > Question: Do I have as "creator" of that branch to run > git branch --track 4.0.1 origin/4.0.1 > as well? > > kp Hi kp, Thanks. I can now see that listed when I run "git branch -r" and I can create a tracking branch with "git branch --track 4.0.1 origin/4.0.1" (which then gets listed when I run "git branch"). Do you see a local branch called 4.0.1 too? If so you won't be able to create another one. I will add some changes to the new branch so you can see if yours gets updated. Out of interest, how did you create the remote branch? Feel free to add the info to the Wiki :-) Just wondering how that branch naming is going to work out when we get to releasing 4.0.1. Normally we would create a tag "4.0.1" for the release. Won't it be confusing to have a tag and a branch with the same name? If we also need a 4.0.2 where will we maintain that - also on the branch called "4.0.1"? IMHO the branch name might be less confusing without the ".1" so e.g. simply "4.0" - but then it's the same as the 4.0 tag... Maybe "4.0-branch" or "4.0-fixes" instead? dMb -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git tree developements
On Tue, 2011-06-21 at 22:25 +0300, Andrew wrote: > 21.06.2011 21:43, Andrew пишет: > > 21.06.2011 21:29, KP Kirchdoerfer пишет: > >> Ok; created the repository leaf/bering-uclibc. > >> git clone ssh://u...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc > >> > >> It's currently empty. Maybe someone will git knowledge will move the > >> content > >> of leaf/leaf/buildtool to leaf/bering-uclibc/bering-uclibc4? > >> I believe a date for this should be given, so everyone can clean > >> up/save/whatelse his local repositories just to be safe. > >> > >> kp > > I'll try to do it now. It shouldn't be too hard :) > > > Done. To move on new repository with minimal wasting of time, just do > next commands: > > git remote add BuC > ssh://nitr0...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc > git config branch.master.remote BuC > git config branch.master.merge refs/heads/master > git pull > cd buildtool; mv package source staging log build conf ..; cd .. > > After that you'll need to reassemble toolchain or to move all content of > git root into same dir as buildtool was before - create some temporary > directory (for ex., tmp), move all into it (don't forget about files > that are started ftom '.' - they may be omitted by mv), and then rename > it to buildtool (so much moves are needed because there are already > 'buildtool' dir). Hi all, I don't know - I go away for a few days and everything changes! Just kidding :-) So basically we are now using the leaf/bering-uclibc Git repository instead of leaf/leaf, is that right? Makes more sense IMHO. I will fix the Git page in the Developer Guide. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Next Beta version number, Git Branching etc.
On Thu, 2011-06-16 at 21:47 +0300, Andrew wrote: > 16.06.2011 21:07, KP Kirchdoerfer пишет: > > hello gents; > > > > Am Dienstag, 14. Juni 2011, 22:40:55 schrieb Andrew: > >> 14.06.2011 22:31, davidMbrooke пишет: > >>> Hi, > >>> > >>> We are getting a few requests for additional kernel modules for 4.0: one > >>> request on leaf-user for asix.ko and I also got a direct request for > >>> r8168.ko the other day. IMHO it would be good to make those available > >>> via version 4.0.1 and maybe later a 4.0.2 etc. > >>> > >>> We also have a large number of fairly major changes (including a kernel > >>> version change) building up in Git. My expectation is those will take a > >>> while to mature, via several Beta releases, and so aren't likely to make > >>> it to "final" release status anytime soon. > >>> > >>> I therefore suggest that we call the next release of the Git HEAD > >>> 4.1-beta1 and then also release 4.0.1 as a "branch" release containing > >>> just *minor* enhancements and bug fixes for 4.0. > >>> > >>> Comments? > > I like the idea. Time to rethink our version strategy we have outlined for > > the > > versions< 3.x > > http://leaf.sourceforge.net/bering- > > uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=8:8 > > > > This approach is coming into age and should be updated, as all of the > > remaining pages needs a review. > > > >>> davidMbrooke > >> IMHO before tagging other versions we should make decisions on some > >> questions on git: > >> 1) In what way we should maintain releases - as branches, or as > >> repositories? 1st IMHO is preferrable when there is not many different > >> branches; > > Andrew; I think for Bering-uClibc we will have less than five branches: > > 1. fixes for the stable version (Davids 4.0.1 branch) > > 2. the development branch (Davids Git HEAD 4.1-beta1) > > 3. a "playground branch" where for example a move to a new kernel or uClibc > > can be tested > > 4. one I forgot yet... > > > > Do you think, that is too much to maintain in branches? > No, this is not much branches. > Main advantage of branches - ability to do 'git rebase' to import all > fixes from one branch into another (for ex., if other branches are based > on stable one) - actually each branch is subset of diffs(patches) that > are applied to first commit. I agree. A few Branches in one Repository are OK (at least for now). dMb > > >> 2) How about reducing directory depth? IMHO it'll be good to move > >> buildtool and binary to the git root - separate directories for projects > >> are meanles for git (for that purposes there are repositories)ю Ьфниу we > >> should bove BuC4 into separete gepository (for ex., leaf/buc4 instead of > >> leaf/leaf)? > > Hmm; I don't have any pb with depth - I'm used to it and it will cause some > > work to change it. I just do not understand what we win changing it - but > > then > > I'm no git expert. Maybe you can explain to a mere git user? > > > IMHO it isn't good if there are meanless directories. At least it > requires more time to change directory :) OK with me to rename the "leaf" repository to e.g. "buc4" and to remove the "bering-uclibc4" level. dMb > > Anway, if you think it's necessary to refine and can provide patches that > > makes > > it seamless, I for shure won't oppose :) > > > > kp > git mv should do all job without problems. If nobody has objections - > IMHO we should move all on top. > > P.S. Should we store compiled packages into git? Maybe there are more > useful places for them (file archive/FTP/etc)? Git is more oriented for > source distribution/versioning... -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Next Beta version number, Git Branching etc.
Hi, We are getting a few requests for additional kernel modules for 4.0: one request on leaf-user for asix.ko and I also got a direct request for r8168.ko the other day. IMHO it would be good to make those available via version 4.0.1 and maybe later a 4.0.2 etc. We also have a large number of fairly major changes (including a kernel version change) building up in Git. My expectation is those will take a while to mature, via several Beta releases, and so aren't likely to make it to "final" release status anytime soon. I therefore suggest that we call the next release of the Git HEAD 4.1-beta1 and then also release 4.0.1 as a "branch" release containing just *minor* enhancements and bug fixes for 4.0. Comments? davidMbrooke -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Error building haserl 0.9.25
On Tue, 2011-06-14 at 09:01 +0200, Erich Titl wrote: > Hi > > at 12.06.2011 21:59, Erich Titl wrote: > > Hi David > > > > on 12.06.2011 15:55, davidMbrooke wrote: > >> On Sun, 2011-06-12 at 14:21 +0100, davidMbrooke wrote: > >>> I will investigate haserl further. > >> > > Just pushed haserl 0.9.29, I will also push webconf-1.2 which should > acommodate the changes necessary for haserl 0.9.x plus a few extensions > like a ping and traceroute interface, reboot from the web interface and > tooltips if one wants to implement them in the web GUI, see > http://www.walterzorn.de/tooltip/tooltip.htm > > cheers > > Erich Thanks Erich. Everything builds OK for me now. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] RADIUS build problems (was Error building haserl 0.9.25)
On Sun, 2011-06-12 at 15:57 +0200, KP Kirchdoerfer wrote: > > Hi kp, > > > > Sigh. No problem with radius for me... > > Seems that radius decided not to build your LDAP integration module. > > Did openldap build OK for you? > > openldap build is ok; > > > If so, what do you get in log/buildtoollog after line: > >=== configuring in src/modules/rlm_ldap > > No signs for rlm_ldap in the log...?? > > kp Hi kp. Thanks for checking. Please will you try with the new repo/radius/buildtool.mk I have just uploaded to Git. I have explicitly specified to configure "--with-" all of the rlm files referenced in radius.lrp. Perhaps that will help... dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] mbr.bin
On Thu, 2011-06-09 at 20:45 +0100, davidMbrooke wrote: > On Thu, 2011-05-19 at 20:41 +0200, Per Sjoholm wrote: > > Web interface hdsupp > > > > > > Package Help Text > > > > HD support tools > > 4. Copy the MBR to the drive using (assuming your harddrive is /dev/hda) > > cat /usr/bin/mbr.bin > /dev/hda > > > > I can't find mbr.bin (find / -name mbr\*) > > > > /Per > > Hi Per, > > Looks like nobody has responded yet (at least not to the list). > > The entry for mbr.bin has been commented out in hdsupp/buildtool.cfg but > I don't know why. I'm inclined to agree this would be a useful file to > have around, though IMHO /usr/bin/ is not a great location for it. > > On Fedora this is in /usr/share/syslinux/ along with other similar > files. > > Does anyone have any objections if I add /usr/share/syslinux/mbr.bin to > hdsupp.lrp? (And update the help text for Buc 4.x.) > > dMb Fixed in Git. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Error building haserl 0.9.25
On Sun, 2011-06-12 at 14:21 +0100, davidMbrooke wrote: > I will investigate haserl further. My haserl build error is described here: https://sourceforge.net/mailarchive/message.php?msg_id=26091302 I am using make version 3.82 on Fedora 15. Erich: The error is fixed in haserl version 0.9.27 and 0.9.29 is now available. Is there a special reason for using 0.9.25? I'd prefer to upgrade than to apply the patch described in the mail. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Error building haserl 0.9.25
On Sun, 2011-06-12 at 14:49 +0200, KP Kirchdoerfer wrote:
> Am Sonntag, 12. Juni 2011, um 14:44:16 schrieb davidMbrooke:
> > Hi,
> >
> > I'm getting an error building haserl:
> >make -C haserl-0.9.25 all
> >make[1]: Entering directory
> > `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25'
> >Making all in src
> >make[2]: Entering directory
> > `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25/src'
> > Makefile:472: *** missing separator (did you mean TAB instead of 8
> > spaces?). Stop.
> >make[2]: Leaving directory
> > `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25/src'
> >make[1]: *** [all-recursive] Error 1
> >make[1]: Leaving directory
> > `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25'
> >make: *** [.build] Error 2
> >make: Leaving directory
> > `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl'
> >
> > Anybody else seeing the same error?
> >
> > dMb
>
> Hi David;
>
> haserl builds without pb,
>
> Making all in src
> make[2]: Entering directory `/opt/buildtool-
> dmb/source/haserl/haserl-0.9.25/src'
> make all-am
> make[3]: Entering directory `/opt/buildtool-
> dmb/source/haserl/haserl-0.9.25/src'
> /opt/buildtool-dmb/staging/bin/gcc-m32 -DHAVE_CONFIG_H -I. -g -O2 -Wall -
> MT common.o -MD -MP -MF .deps/common.Tpo -c -o common.o common.c
>
> but radius failed :)
>
> Generating package radius
> cp: Aufruf von stat für „/opt/buildtool-
> dmb/staging/usr/lib/rlm_ldap-2.1.10.so“ nicht möglich: Datei oder Verzeichnis
> nicht gefunden
> Copying file /opt/buildtool-dmb/staging/usr/lib/rlm_ldap-2.1.10.so failed.
> Datei oder Verzeichnis nicht gefunden at ./buildpacket.pl line 461
> main::system_exec('cp -r /opt/buildtool-
> dmb/staging/usr/lib/rlm_ldap-2.1.10.so /...', 'Copying file /opt/buildtool-
> dmb/staging/usr/lib/rlm_ldap-2.1') called at ./buildpacket.pl line 565
> main::copyBinariesToPackageStaging('HASH(0x9781a50)', '/opt/buildtool-
> dmb/staging') called at ./buildpacket.pl line 1215
Hi kp,
Sigh. No problem with radius for me...
Seems that radius decided not to build your LDAP integration module.
Did openldap build OK for you?
If so, what do you get in log/buildtoollog after line:
=== configuring in src/modules/rlm_ldap
I will investigate haserl further.
dMb
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Error building haserl 0.9.25
Hi, I'm getting an error building haserl: make -C haserl-0.9.25 all make[1]: Entering directory `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25' Making all in src make[2]: Entering directory `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25/src' Makefile:472: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. make[2]: Leaving directory `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl/haserl-0.9.25' make: *** [.build] Error 2 make: Leaving directory `/home/leaf/leaf/bering-uclibc4/buildtool/source/haserl' Anybody else seeing the same error? dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Just added UCLIBC_HAS_WCHAR=y
Hi, For the OpenLDAP Package (required for LDAP support in FreeRADIUS) I need to add UCLIBC_HAS_WCHAR=y to the uClibc .config. I have been testing with this enabled for a while and it doesn't seem to affect any other Packages (that I use :-) ) so I have just checked it into Git. All active developers will need to re-build uClibc before OpenLDAP (once I also check that in) will build cleanly. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] mbr.bin
On Thu, 2011-05-19 at 20:41 +0200, Per Sjoholm wrote: > Web interface hdsupp > > > Package Help Text > > HD support tools > 4. Copy the MBR to the drive using (assuming your harddrive is /dev/hda) > cat /usr/bin/mbr.bin > /dev/hda > > I can't find mbr.bin (find / -name mbr\*) > > /Per Hi Per, Looks like nobody has responded yet (at least not to the list). The entry for mbr.bin has been commented out in hdsupp/buildtool.cfg but I don't know why. I'm inclined to agree this would be a useful file to have around, though IMHO /usr/bin/ is not a great location for it. On Fedora this is in /usr/share/syslinux/ along with other similar files. Does anyone have any objections if I add /usr/share/syslinux/mbr.bin to hdsupp.lrp? (And update the help text for Buc 4.x.) dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] shorewall documentation in configfiles
On Sun, 2011-06-05 at 22:09 +0200, KP Kirchdoerfer wrote: > Hello; > > > in the beginning the shorewall configuration files had an exhaustive > documentation including examples. > > Later the documentation has been removed to improve support size-constrained > distros like LEAF, and was only available online or in the man-pages (which > we > never added to our packages). > > With the latest upstream version 4.4.20 the documentation has been > reintroduced into the config files, though the shrinked config files are > still > around (using the -p option during install, or for our buildtoool setup to > package *.plain). > > Beginning with Bering-uClibc 4.x we do not support a floppy-only setup any > longer and size can weighted up convenience. > > My question is, do we want to include again the documented config files, or > shall we stick with the shrinked versions and pointing to the online docs at > shorewall.net? > > kp Hi kp, I have just looked at the "annotated" config files in the Shorewall 4.4.20 distribution and IMHO the documentation will just get in the way when editing the files. My /etc/shorewall/rules file is already large enough :-) My vote is therefore to stay as we are, using the "plain" files, and to clearly direct users to the online documentation at shorewall.net, though I am happy to be outvoted if others disagree. dMb -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] glitch in buildtool
On Wed, 2011-06-08 at 09:41 +0200, Erich Titl wrote: > Hi David > > at 16.05.2011 21:33, davidMbrooke wrote: > > On Mon, 2011-05-16 at 10:40 +0200, Erich Titl wrote: > ... > > > Hi Erich, > > > > I have noticed the same behaviour. Some of the makefiles automatically > > derive the directory name from the source .tar.gz contents but that does > > not work for buildclean / srcclean so they have to save off the > > directory name to a file (called "DIRNAME") in order to use the name > > later, when the environment variables are not set. > > > > Would a similar approach work for you? Look at the first few lines of > > e.g. repo/nfs-utils/buildtool.mk as an example. > > > > I have not thought about this for some time, honestly I was a bit > disappointed y this behaviour. > Not feeling compelled to dig into the perl modules I have decided to use > the following approach to this im my makefiles. > > There is always a .source .build e.t.c created in the build > directory, for the sake of makefile dependencies. These files do not > need to be in the actual source tree of the package, but can reside on > top of it. Also these files need not be stubs but may contain > information, thus instead of just touching .source I echo the root of > the unpacked tarball into it, for example in openswan. > > OPENSWAN_DIR:=$(OPENSWAN_SOURCE:.tar.gz=) > OPENSWAN_TARGET_DIR:=$(BT_BUILD_DIR)/openswan > > export USE_AGGRESSIVE=false > export USE_XAUTH=true > export USE_BASH=false > export USE_EXTRACRYPTO=true > > > .source: > zcat $(OPENSWAN_SOURCE) | tar -xvf - > echo $(OPENSWAN_DIR) > .source > > . > > clean: > -rm -f .build > rm -rf $(OPENSWAN_TARGET_DIR) > for i in $(KARCHS); do \ > rm -rf > $(BT_STAGING_DIR)/lib/modules/$(BT_KERNEL_RELEASE)-$$i/kernel/net/ipsec ;\ > done; > make -C `cat .source` clean > > srcclean: clean > rm -rf `cat .source` > > This allows to get rid of the redundant information in buildtool.mk > while maintaining the current infrastructure. > > cheers > > Erich Yes, so that's the same basic approach as with the "DIRNAME" file in my nfs-utils example. It's not ideal but I agree it's better than hard-coding the directory name in buildtool.mk as well as having the .tar.gz filename in buildtool.cfg. Note that some applications do not follow the naming convention of DIRECTORYNAME.tar.gz which I presume is why the tools/getdirname.pl script was created. This actually looks inside the file to see what the directory is called. davidMbrooke -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Error building bind - OpenSSL check is looking at build host, not target
Hi Andrew, I'm getting an error building bind, at the "configure" step: ... checking whether byte ordering is bigendian... no checking for OpenSSL library... not found configure: error: OpenSSL was not found in any of /usr /usr/local /usr/local/ssl /usr/pkg /usr/sfw; use --with-openssl=/path make: *** [bind-9.8.0-P1/.configured] Error 1 Seems that it's looking on my build host, not under the staging directory. I don't have the OpenSSL header files on my build host. A workaround is to specify the directory in bind/buildtool.mk: --with-openssl=$(BT_STAGING_DIR)/usr \ dMb -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Open Source License(s) for LEAF, Bering-uClibc, Wiki etc.
On Sun, 2011-05-15 at 16:17 -0700, Mike Noyes wrote: > On Sun, 2011-05-15 at 22:48 +0200, KP Kirchdoerfer wrote: > > Am Sonntag, 15. Mai 2011, um 22:02:45 schrieb Mike Noyes: > > > On Sun, 2011-05-15 at 21:45 +0200, KP Kirchdoerfer wrote: > > > > Am Sonntag, 15. Mai 2011, um 15:08:12 schrieb davidMbrooke: > > > -snip- > > > > > > > > > > With specific reference to the Wiki, there is currently no > > > > > > > statement about the license which applies to the Wiki text itself. > > > > > > > For my own contributions I would prefer to apply the "Creative > > > > > > > Commons Attribution-ShareAlike > > > > > > > License" (http://creativecommons.org/licenses/by-sa/3.0/) which is > > > > > > > what Wikipedia uses. > > > > > > > However there is some text imported from the previous > > > > > > > DocBook documentation which may use a different license. > > > > > > > > > > > > I'm not aware that any docbook content has been written with a > > > > > > special license in mind. Is it necessary to ask the original authors > > > > > > individually? > > > > > > > > > > > > Anyway I think the license sound good and reasonable for the wiki > > > > > > content, at least as far as I'm concerned. > > > > > > > > > > I will review the DocBook source for any license statements, but I > > > > > propose to declare that the cc-by-sa license applies to the Wiki > > > > > content if there are no objections. > > > > > > > > No need to inverstigate the docbook license IMHO. My question was if we > > > > have to ask those who has written the docbook-based contents > > > > individually for permission (Arne, Martin, Jacques, EricS, ETitl, Luis > > > > et al)...? As I said we've never discussed license issues before, and > > > > I'm confident they'll agree, if we add the license to the wiki you > > > > proposed - but better be safe than then sorry. > > > > > > KP & David, > > > We've discussed documentation licensing in the past too. I think most of > > > our current documentation was released into the public domain. > > > http://www.mail-archive.com/search?l=leaf-devel%40lists.sourceforge.net&q=d > > > ocumentation+license > > > > Phew; you'll show a good memory (again) - the discussions are from > > 2000-2002... > > > > Do you think it's a pb if we change the documentation license to the one > > dmb > > proposed? > > KP, > Not for my part. You, David, and Andrew have put most of the work in on > the wiki. I recommend you give the other contributers time to respond. I > seriously doubt there will be any objections though. Mike, Thanks for the feedback. I suspected there must have been some discussions in the early days of LEAF. My searches did not turn up any license discussions but I did not think to go back as far as 2001. :-) The "GNU Free Documentation License" is my second choice for the Wiki content but IMHO CC-BY-SA seems more in line with the spirit of the GPL. By the way, if you get chance, please could you investigate whether our MediaWiki installation can be configured to show the license on every page. If your admin access lets you edit LocalSettings.php then variables like $wgRightsUrl can be set as described at http://www.mediawiki.org/wiki/Manual:LocalSettings.php#Setting_copyright_for_the_site dMb -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] glitch in buildtool
On Mon, 2011-05-16 at 10:40 +0200, Erich Titl wrote: > Hi Folks > > It appears that the environment variables from buildtool.cfg are not > passed to the makefile for the buildclean and srcclean operations. Could > someone with insight in these modules please comment? > > Thanks > > Erich Hi Erich, I have noticed the same behaviour. Some of the makefiles automatically derive the directory name from the source .tar.gz contents but that does not work for buildclean / srcclean so they have to save off the directory name to a file (called "DIRNAME") in order to use the name later, when the environment variables are not set. Would a similar approach work for you? Look at the first few lines of e.g. repo/nfs-utils/buildtool.mk as an example. Obviously it would be possible to change the buildtool source code to implement different behaviour but I think I looked at doing that and it was not trivial. Feel free to create a Trac ticket to log the request for an enhancement. dMb -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Open Source License(s) for LEAF, Bering-uClibc, Wiki etc.
Hi kp, On Sun, 2011-05-15 at 01:06 +0200, KP Kirchdoerfer wrote: > Hi David; > > I've been afraid that some day this discussion will come up on the list :) Sorry about that... :-) > > Am Freitag, 13. Mai 2011, um 20:31:58 schrieb davidMbrooke: > > Hi, > > > > In my professional life I have recently been researching the terms of > > the various Open Source licenses and I'm thinking that we should do more > > to clarify the license(s) which apply to LEAF releases, in particular > > Bering-uClibc 4.0. > > I confess I have no idea about all the licenses in general and the pros and > cons speficially. Maybe you can give a short summarize as decision help. > But I don't like to move 4.0 into the future until the license question has > been solved. I think it does need some serious thoughts and it will take some > time to find an answer that we all agree on. I will create a "License" page in the Wiki, and use that (and its "Discuss" page) to capture my understanding. I did not mean to imply that this should delay or change 4.0 in any way, just that it is 4.x (rather than 3.x) which should be our focus for understanding and clarification. > > Obviously we mostly inherit licenses from the upstream sources, so GNU > > GPL v2 for the Linux kernel, Busybox, Shorewall and LGPL for uClibc and > > so on. However there are some "custom" additions like buildtool where > > the author might want to declare that a different license applies. > > > > My thoughts: > >- Shouldn't we include a copy of the GPL in all of the disk images, > > because the GPL says that every user "...should have received a copy of > > the GNU General Public License along with this program"? > >- Shouldn't we add a License statement / page to the Wiki which > > clarifies which license (or licenses) applies to LEAF? > > Yes to both :) If we simply add e.g. the GPLv2 "COPYING" file to each disk image then we would be declaring that license applies to LEAF Bering-uClibc 4.0, which would be premature if there is no consensus. I guess we should do nothing for the 4.0 release. > > With specific reference to the Wiki, there is currently no statement > > about the license which applies to the Wiki text itself. For my own > > contributions I would prefer to apply the "Creative Commons > > Attribution-ShareAlike > > License" (http://creativecommons.org/licenses/by-sa/3.0/) which is what > > Wikipedia uses. > > However there is some text imported from the previous > > DocBook documentation which may use a different license. > > I'm not aware that any docbook content has been written with a special > license > in mind. Is it necessary to ask the original authors individually? > > Anyway I think the license sound good and reasonable for the wiki content, at > least as far as I'm concerned. I will review the DocBook source for any license statements, but I propose to declare that the cc-by-sa license applies to the Wiki content if there are no objections. > > Is there already consensus on which license applies to LEAF and the > > documentation? I have failed to find a clear statement so far. > > There is AFAIK no consens yet. > > > kp dMb -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Open Source License(s) for LEAF, Bering-uClibc, Wiki etc.
Hi, In my professional life I have recently been researching the terms of the various Open Source licenses and I'm thinking that we should do more to clarify the license(s) which apply to LEAF releases, in particular Bering-uClibc 4.0. Obviously we mostly inherit licenses from the upstream sources, so GNU GPL v2 for the Linux kernel, Busybox, Shorewall and LGPL for uClibc and so on. However there are some "custom" additions like buildtool where the author might want to declare that a different license applies. My thoughts: - Shouldn't we include a copy of the GPL in all of the disk images, because the GPL says that every user "...should have received a copy of the GNU General Public License along with this program"? - Shouldn't we add a License statement / page to the Wiki which clarifies which license (or licenses) applies to LEAF? With specific reference to the Wiki, there is currently no statement about the license which applies to the Wiki text itself. For my own contributions I would prefer to apply the "Creative Commons Attribution-ShareAlike License" (http://creativecommons.org/licenses/by-sa/3.0/) which is what Wikipedia uses. However there is some text imported from the previous DocBook documentation which may use a different license. Is there already consensus on which license applies to LEAF and the documentation? I have failed to find a clear statement so far. Thanks, davidMbrooke -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Shorewall configuration
On Mon, 2011-05-09 at 16:28 +1000, ads...@genis-x.com wrote: > Hi all, > > Just playing with the latest RC1 > Bering-uClibc_4.0-rc1_i686_syslinux_vga.tar.gz > > Prep'd a USB boot stick and booted for the first time. I have a minimum > amount of packages at the moment. > > LRP="root config etc modules mawk iptables keyboard libm perl shorwall > dropbear" > > On start up I get the following error from shorewall. > ERROR: Your kernel/iptables do not include state match support. No version > of Shorewall will run on this system > > Have a missed a config step? Or a module? > > Cheers > Adam Hi Adam, That's really a leaf-user sort of question (rather than leaf-devel) but I'll let you off this one time... :-) An unmodified Bering-uClibc_4.0-rc1_i686_syslinux_vga.tar.gz works OK and if I edit leaf.cfg to match your LRP= list it still works OK. To me it sounds like you have managed to lose some of the standard modules from moddb.lrp The ERROR message comes from /usr/share/shorewall/Shorewall/Config.pm, line 2603, so I recommend you have a look at the commands which are run there to see if that provides any clues. davidMbrooke -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] building all packets / foul buildpacket
On Mon, 2011-05-09 at 11:12 +0200, Erich Titl wrote: > Hi KP > > at 05.05.2011 15:22, KP Kirchdoerfer wrote: > > Am Donnerstag, 5. Mai 2011, um 14:57:55 schrieb Erich Titl: > >> Hi Folks > >> > >> There is a buildall.sh in the tools directory which builds all the > >> defined packages, but is there a tool or quirk to buildpacket.pl to > >> assemble the packages? > > > > Hi Erich; > > > > buildall.sh builds also the packages. > > I believe buildpacket.pl is fouled up somehow in my installation > > here the trace for haserl > > mega@luna:~/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool> > ./buildtool.pl srcclean haserl > calling 'make clean' for haserl: [0.K.] > calling 'make srcclean' for haserl: [0.K.] > removing installed files for package haserl [0.K.] > deleting haserl type build from installed list [0.K.] > deleting haserl type source from installed list [0.K.] > mega@luna:~/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool> > ./buildtool.pl build haserl > make the list of required source packages: haserl [0.K.] > > source/package: haserl > > downloading: buildtool.cfg from server localrepo type filesymlnk [0.K.] > downloading: buildtool.mk from server localrepo type filesymlnk [0.K.] > downloading: haserl-0.8.0.tar.gz from server localrepo type filesymlnk > [0.K.] > downloading: buildtool.cfg from server localrepo type filesymlnk [0.K.] > calling 'make source' for haserl [0.K.] > make the list of required build packages: haserl [0.K.] > > build source/package: haserl > > calling 'make build' for haserl [0.K.] > mega@luna:~/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool> su > Password: > luna:/home/mega/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool > # ./buildpacket.pl --package=haserl > Key "package" does not exist within current object > at ./buildpacket.pl line 1102 > > this is weird, as git does not show anything > > mega@luna:~/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool> > git pull > et...@leaf.git.sourceforge.net's password: > Already up-to-date. > > here is the md5sum of buildpacket.pl > > luna:/home/mega/leaf/bering-uclibc/devel/src/leaf/bering-uclibc4/buildtool > # md5sum buildpacket.pl > aa7b722adb66ccb44134adc2a6b15e73 buildpacket.pl > > cheers > > Erich Hi Erich, That's normal behaviour for haserl. It doesn't generate its own .lrp file but instead gets installed as a component of another Package. The message is correct - there is no "" entry in haserl/buildtool.cfg Do other Packages build OK for you? If not, what OS are you running on your build host? Note that we normally use "fakeroot" when running buildpacket.pl rather than su'ing to "real" root. davidMbrooke -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] tagging 4.0?
On Mon, 2011-04-25 at 19:42 +0200, KP Kirchdoerfer wrote: > Gents; > > I propose to tag 4.0 until end of week and start release work. > > Currently there are no showstoppers, the number of reported bugs has only a > few for rc1. And I think it's a good and stable final release after nearly a > year of developement. > > opinions? > > kp Hi kp, Sounds good to me. I have been running -rc1 since the day it was released with no problems so I believe it is ready to become 4.0. Like you I have some draft changes for 4.1-beta1 (freeradius, LDAP client, asterisk, PXE booting) and it would be good to get those into the main Git repository. I presume that once 4.0 is tagged we can start to load 4.1 content into the "master" branch in Git? If there is a bug in 4.0 which needs to be fixed we can always branch off a 4.0.1 based on the 4.0 tag. dMb -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] PXE Booting - Not installing
On Tue, 2011-04-05 at 17:00 +1000, ads...@genis-x.com wrote: > I LOVE YOU GUYS > > I just finally had time to catch up on the progress with the RC1 release, > omg you lot are amazing in how far this has come. > I then read the trac ticket on PXE booting, I can't sit still. > > Where/how can I get my hands on this to play with? > > I read the trac ticket, and was just wondering why don't you just stick with > the very basics for now. > Get the system booting from PXE using the good ole trusted tftp transfer. > (which is supported in busybox) and for saving config use tftp put. > > Anyways I have a lot of my systems PXE boot (including a quite large VMWare > cloud), if I can test/help out anyway let me know. > > Cheers > Adam Hi Adam, Glad you like what you see so far... :-) My plan is to add PXE boot (not install, or at least not automatically saving config) to 4.1-beta1 soon after we get 4.0 released. As soon as I have something that is Beta quality (even before 4.0) I will happily let you have a copy to play with. Part of the problem is defining the buildtool configuration to create a very different initrd for PXE boot without duplicating all of the config for the non-PXE boot. Personally I am not a fan of TFTP - it is slow and insecure. I know we need it for part of the PXE boot sequence but IMHO other protocols like HTTP or SSH are better for the main file downloads, so I would prefer to support those. With "curl" you get the choice to use TFTP or something else. davidMbrooke -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc4 - Strange build failures for kernel - Git-related - Solved (I think)
On Tue, 2011-02-22 at 20:15 +, davidMbrooke wrote: > Hi, > > I'm getting some strange failures running "tools/buildall.sh" on a clean > git clone from the latest (2011-02-22) master repository. > > Specifically: >- Building the Packages for "kernel" and "kmodules" >- Building the Source and Package for "iscsi" >- Building the Packages for "initrd" > > All are related to the same problem. For some reason the kernel build is > writing the results into directories called e.g. > "2.6.35.10-geode-g8373740" rather than simply "2.6.35.10-geode" and > attempts to copy files from the "expected" locations do not work. > > The same -g8373740 suffix is applied to the i486, i686 and geode > variants. > > I notice that UTS_RELEASE and kernel.release are being defined with the > suffix. For example: >$ cd leaf/bering-uclibc4/buildtool/source/linux/ >$ cat linux-geode/include/generated/utsrelease.h >#define UTS_RELEASE "2.6.35.10-geode-g8373740" >$ cat include/config/kernel.release >2.6.35.10-geode-g8373740 > > Surely that's not right... > > > Typical. While composing this email I solve the problem myself. Oh well, > let me finish this so we have a record in the email archive. > > > File kernel.release is generated from Makefile by running script > linux-2.6.35.10/scripts/scripts/setlocalversion which has comments: > # This scripts adds local version information from the version > # control systems git, mercurial (hg) and subversion (svn). > > That script runs this git command: > $ git rev-parse --verify --short HEAD > which sure enough says: > 8373740 > The "-g" is added by the script to show that it is a Git version number. > > This behaviour can be suppressed by a change to the kernel .config. > Right now we have: >CONFIG_LOCALVERSION_AUTO=y > and changing this to ># CONFIG_LOCALVERSION_AUTO is not set > seems to fix it for me. > > I propose to do another clean build to check for any side-effects and if > all is successful commit the change to the kernel .config. > > davidMbrooke Having fixed it for 2.6.35.10 this problem came back again in 2.6.35.11. Fixed again. I don't know why it's only me who seems to have problems with this... dMb -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Approach to updating the Wiki
On Mon, 2011-03-28 at 23:33 +0200, KP Kirchdoerfer wrote: > Am Montag, 28. März 2011, um 22:48:56 schrieb Martin Hejl: > > Hi again, > > > > I've been wondering - what's the "accepted" approach to updating the > > wiki? Should everybody with write access (I seem to have write access) > > just go ahead, or should there be some discussion about proposed changes > > first? I know, changes in the Wiki can be backed out again relatively > > easily, but just like in CVS (or git, or whatever), that causes extra > > work, that might be avoided by simply talking about changes one wants to > > make. > > > > For now, what I have in mind is to make some minor changes to the > > OpenVPN chapter (since it obviously needs work) - but I don't want to > > alienate those who did all of the work so far, by making some changes > > and "breaking the rules" in the process. > > > > So, I figured I'd ask first... > > > > Hi Martin; > > Write access is restricted to registered LEAF developers only (and for > obvious > reasons you do have write permissions). > > For discussion about wiki content, esp. if you are concerned about new > content, we use the "talk option" in the wiki itself. > > For rules contributing to in the wiki see: > https://sourceforge.net/apps/mediawiki/leaf/index.php?title=Wiki_Contributor_Guidelines > > And yes a backout is every time possible, and it may some work (for David > esp, > who did most of the work on the wiki and had the patience to deal me writing > to the wiki), but every improvement is welcome. > > kp Hi Martin, Thanks for asking but please go ahead! Many of the existing pages are unmodified copies of Bering-uClibc 3.x content and need correcting and expanding. One good thing about the Wiki is that it is easy to make minor corrections, and to see what has been changed. kp has covered most of the "rules". In my view, correcting or expanding existing pages is always OK. Adding new pages needs more thought, so please "discuss" those here or on a Wiki Discussion page first. It is also possible to raise a Trac ticket for Component = Documentation, useful if a major topic needs to be added. davidMbrooke -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remaining tickets for beta3
On Sun, 2011-03-06 at 17:14 +0100, KP Kirchdoerfer wrote: > Am Sonntag, 6. März 2011, um 17:03:08 schrieb davidMbrooke: > > On Sun, 2011-03-06 at 17:11 +0200, Andrew wrote: > > > 06.03.2011 17:06, KP Kirchdoerfer пишет: > > > > Am Sonntag, 6. März 2011, um 15:53:34 schrieb Andrew: > > > >> 05.03.2011 16:12, KP Kirchdoerfer пишет: > > > >>> Hi; > > > >>> > > > >>> can someone else pls have a look at trac ticket #18? I triied, but > > > >>> can't find a solution... > > > >>> > > > >>> Ticket #9 and #13 can be moved to later IMHO. > > > >>> > > > >>> kp > > > >> > > > >> It looks like now it's fixed, by one small patch. Can anyone re-check > > > >> this? > > > > > > > > Once you commit errno_fix.patch I'll give it a try :) > > > > > > > > kp > > > > > > Fixed. > > > > I also found the problem "the hard way" - and *then* I spotted there is > > an official patch: > > http://djbware.csi.hu/patches/daemontools-0.76.errno.patch > > > > Basically the same as Andrew's patch, but might be cleaner to use that > > one? > > Why? Do you believe this one is more "official"? > > kp > btw: I can confirm that Andrews patch worked on my box. It's a small point, but my logic is that if we call the patch with the "standard" name daemontools-0.76.errno.patch then Google tells us about http://djbware.csi.hu/patches/ which contains other DJB patches. In the future, there might be further patches there we can/should use, and leaving a clue about that location might save someone a little time in a year or two. It's probably not worth changing this now, My preference is always to use a patch from elsewhere rather than creating our own. dMb -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remaining tickets for beta3
On Sun, 2011-03-06 at 17:11 +0200, Andrew wrote: > 06.03.2011 17:06, KP Kirchdoerfer пишет: > > Am Sonntag, 6. März 2011, um 15:53:34 schrieb Andrew: > >> 05.03.2011 16:12, KP Kirchdoerfer пишет: > >>> Hi; > >>> > >>> can someone else pls have a look at trac ticket #18? I triied, but can't > >>> find a solution... > >>> > >>> Ticket #9 and #13 can be moved to later IMHO. > >>> > >>> kp > >> It looks like now it's fixed, by one small patch. Can anyone re-check this? > > Once you commit errno_fix.patch I'll give it a try :) > > > > kp > Fixed. I also found the problem "the hard way" - and *then* I spotted there is an official patch: http://djbware.csi.hu/patches/daemontools-0.76.errno.patch Basically the same as Andrew's patch, but might be cleaner to use that one? dMb -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] New kernel needs .config changes
Hi, For me, on a clean clone of the git repository, "make source" on the new 2.6.35.11 kernel prompts for some missing settings in .config. Looks like we need to add: CONFIG_NET_SCH_ESFQ=m CONFIG_NET_SCH_ESFQ_NFCT=y - assuming that we want those included. dMb -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remaining tickets for beta3
On Sat, 2011-03-05 at 15:12 +0100, KP Kirchdoerfer wrote: > Hi; > > can someone else pls have a look at trac ticket #18? I triied, but can't find > a > solution... > > Ticket #9 and #13 can be moved to later IMHO. > > kp Hi kp, #9 is almost complete - docs are in place; I just need to be brave and delete the files we no longer need. #13 can be postponed, I agree. I will look at #18 today. dMb -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buildimage.pl is broken
On Sat, 2011-03-05 at 09:06 +, davidMbrooke wrote: > On Sat, 2011-03-05 at 01:46 +0100, KP Kirchdoerfer wrote: > > Hi kp, > > Thanks for the report. I thought I had tested that, but I did not try a > complete re-build. I will fix now. > > dMb So the change was easy enough but I messed up the Git transactions because I forgot to "pull" the other changes from the SourceForge repository first. I *think* I have managed to revert my unintentional "Merge branch". Initially I tried: $ git revert HEAD but that failed: fatal: Commit 36d32e327119dc57b18ad8cd2410fd659d0a7887 is a merge but no -m option was given. So then I used: $ git revert HEAD -m 1 which seemed to work OK. If that isn't right then I probably need a Git expert to put things back how they used to be - keeping the "Corrected path to isolinux.bin" change but not the later one(s). dMb -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buildimage.pl is broken
On Sat, 2011-03-05 at 01:46 +0100, KP Kirchdoerfer wrote:
> Hi David;
>
> some of the latest commits broke buildimage.pl
>
> After a fresh and complete rebuild of my buildenv I tried to create a iso-
> image.
>
> I get the error:
> fakeroot ./buildimage.pl --image=Bering-uClibc_i486_isolinux_vga --relver 4.0-
> beta3
> cp: Aufruf von stat für „/opt/buildtool-git/staging/usr/bin/isolinux.bin“
> nicht möglich:file not found
> Failed to copy files: file not found at ./buildimage.pl line 273
> main::system_exec('cp -r /opt/buildtool-
> git/staging/usr/bin/isolinux.bin /tmp/BU...', 'Failed to copy files: ')
> called
> at ./buildimage.pl line 314
> main::copyFilesToTempDir('staging/usr/bin/isolinux.bin',
> 'isolinux/isolinux.bin') called at ./buildimage.pl line 189
>
> isolinux.bin is indeed not in staging/usr/bin any longer, but in
> staging/usr/share/syslinux.
>
> You modified syslinux buildtool.mk for preparation of pxe-boot. This commit
> raised the error.
>
> kp
Hi kp,
Thanks for the report. I thought I had tested that, but I did not try a
complete re-build. I will fix now.
dMb
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering-uClibc4 - Strange build failures for kernel - Git-related - Solved (I think)
Hi, I'm getting some strange failures running "tools/buildall.sh" on a clean git clone from the latest (2011-02-22) master repository. Specifically: - Building the Packages for "kernel" and "kmodules" - Building the Source and Package for "iscsi" - Building the Packages for "initrd" All are related to the same problem. For some reason the kernel build is writing the results into directories called e.g. "2.6.35.10-geode-g8373740" rather than simply "2.6.35.10-geode" and attempts to copy files from the "expected" locations do not work. The same -g8373740 suffix is applied to the i486, i686 and geode variants. I notice that UTS_RELEASE and kernel.release are being defined with the suffix. For example: $ cd leaf/bering-uclibc4/buildtool/source/linux/ $ cat linux-geode/include/generated/utsrelease.h #define UTS_RELEASE "2.6.35.10-geode-g8373740" $ cat include/config/kernel.release 2.6.35.10-geode-g8373740 Surely that's not right... Typical. While composing this email I solve the problem myself. Oh well, let me finish this so we have a record in the email archive. File kernel.release is generated from Makefile by running script linux-2.6.35.10/scripts/scripts/setlocalversion which has comments: # This scripts adds local version information from the version # control systems git, mercurial (hg) and subversion (svn). That script runs this git command: $ git rev-parse --verify --short HEAD which sure enough says: 8373740 The "-g" is added by the script to show that it is a Git version number. This behaviour can be suppressed by a change to the kernel .config. Right now we have: CONFIG_LOCALVERSION_AUTO=y and changing this to # CONFIG_LOCALVERSION_AUTO is not set seems to fix it for me. I propose to do another clean build to check for any side-effects and if all is successful commit the change to the kernel .config. davidMbrooke -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] download type filesymlink
On Tue, 2011-02-15 at 20:03 +0100, KP Kirchdoerfer wrote: > Hi Andrew; > > Am Sonntag, 13. Februar 2011, um 22:45:13 schrieb Andrew: > > P.S. I found that using of symlinks broke all packages with config files > > into git (by default symlinks were copied) - now I fixed this (triveally > > added -L option for cp for files from repository), so I'll run rebuild > > of all tree from scratch, and then - push commit into git. > > It is my understanding that the difference between the download types "File" > and "FileSymlink" are that files are copied with File.pm and linked with > FileSymlink. > > The space a buildenv needs on a developers box isn't that different (5.8GB > with FileSymlink, 5.9 GB with File - maybe your stats are different, but most > the space in a buildenv is needed by the unpacked source packages which are > not linkable). > > On the other hand it requires a different handling of config files provided > in > *our* source (cp -aL) compared to other files provided in the original source > (cp -a) - which is somewhat error-prone. > > The way I work is to build seperate buildenvs to test different versions and > changes. With FileSymlink I always work in the git repository (due to the > links). > > If I want to avoid unnecessary downloads, I can change the type and > serverpath > in sources.cfg, tested File, FileSymlink, gitweb - and it all works (luckily > the changes in buildtool.mk's for Filesymlink didn't break that). But the > least intrusive way is IMHO to use download type File. > > Unless I missed a major point, I'd vote to revert the changes and to go with > the DownloadTypes gitweb and File. > > kp Hi kp, Like you I am having problems with our buildtool.mk files copying links rather than the files they reference (e.g. for ".init" files). Sure, we can fix by adding "-L" but that means changing many buildtool.mk files. I would like to avoid the need to re-download the source files from SourceForge, but I agree we can afford the space to copy from repo/ into source/ rather than symlinking. Andrew: do you have a compelling reason to symlink rather than copy into source/ ? dMb -- Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] iPXE
On Tue, 2011-02-15 at 22:19 +0100, Per Sjoholm wrote: > On 2011-02-15 21:42, davidMbrooke wrote: > > On Tue, 2011-02-15 at 20:54 +0100, Per Sjoholm wrote: > >> On 2011-02-15 20:45, Per Sjoholm wrote: > >>> Anyone have experince with IPXE ? > >>> > >>> http://en.wikipedia.org/wiki/IPXE > >>> While traditional PXE clients use TFTP to transfer data, > >>> iPXE adds the ability to retrieve data through other protocols like HTTP > >>> , iSCSI , ATA over Ethernet (AoE), and Fibre Channel over Ethernet > >>> (FCoE), and can work with Wi-Fi rather than requiring a wired connection. > >>> > >> http://ipxe.org/ > >> You can use PXE to chainload into IPXE. > >> > >> You can boot something over the network. Unlike a traditional PXE ROM, > >> iPXE is able to boot over a wide area network > >> such as the Internet. If the machine you are testing is connected to the > >> Internet, you can boot the iPXE demonstration > >> image: > >> > >> iPXE> chain http://boot.ipxe.org/demo/boot.php > > Hi Per, > > > > iPXE is the new name for gPXE. Google Tech Talk video about gPXE and > > Etherboot is on YouTube here: > > http://www.youtube.com/watch?v=GofOqhO6VVM > > > > I was doing some testing with gPXE at the weekend. Some notes here: > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_User_Guide_-_Appendices_-_Hints_and_Tips_for_Network_Booting > > > > Specifically, using gPXELINUX rather than PXELINUX. > > > > dMb > > > Thanks David, good work > I will watch the gpxe gtalk tomorrow on my newly installed Fedora14 with xbmc > > If I understand correctly IPXE is more than a new name. IPXE continues were > GPXE stopped. > > chain loading means that dhcp server needs logic to avoid looping. > /Per The "chain loading" thing had me confused for a while. If you get PXE to load "pure" gPXE / iPXE then yes, you do need some careful DHCP configuration to avoid it loading the same thing again (and again...). gPXELINUX avoids that complexity, since it is basically PXELINUX but with gPXE / iPXE extensions and you don't need to do anything special to DHCP whereas you can load the kernel and initrd over FTP or HTTP etc. There are some specific instructions for the chain-loading config for dnsmasq here: http://www.etherboot.org/wiki/dnsmasq dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] iPXE
On Tue, 2011-02-15 at 20:54 +0100, Per Sjoholm wrote: > On 2011-02-15 20:45, Per Sjoholm wrote: > > Anyone have experince with IPXE ? > > > > http://en.wikipedia.org/wiki/IPXE > > While traditional PXE clients use TFTP to transfer data, > > iPXE adds the ability to retrieve data through other protocols like HTTP > > , iSCSI , ATA over Ethernet (AoE), and Fibre Channel over Ethernet > > (FCoE), and can work with Wi-Fi rather than requiring a wired connection. > > > http://ipxe.org/ > You can use PXE to chainload into IPXE. > > You can boot something over the network. Unlike a traditional PXE ROM, iPXE > is able to boot over a wide area network > such as the Internet. If the machine you are testing is connected to the > Internet, you can boot the iPXE demonstration > image: > >iPXE> chain http://boot.ipxe.org/demo/boot.php Hi Per, iPXE is the new name for gPXE. Google Tech Talk video about gPXE and Etherboot is on YouTube here: http://www.youtube.com/watch?v=GofOqhO6VVM I was doing some testing with gPXE at the weekend. Some notes here: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_User_Guide_-_Appendices_-_Hints_and_Tips_for_Network_Booting Specifically, using gPXELINUX rather than PXELINUX. dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Buildtool issues
On Sun, 2011-02-13 at 22:23 +1100, ads...@genis-x.com wrote: > You might want to note that you have to run buildall.sh from within the > buildtool directory not from the tools folder That's why we always refer to it as "tools/buildall.sh" not "./buildall.sh", and I claim the new Wiki page is *relatively* clear ;-) Glad to hear you are up and running now. dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ifconfig
On Sun, 2011-02-13 at 15:05 +0100, KP Kirchdoerfer wrote: > Gents; > > as you may have noted we do have at least two packages which requires > ifconfig > in addition to iproute2. > > A short term solution would be to enable the ifconfig in busybox (adds 3kb to > busybox), long-term solution to fix the packages affected to use iproute2 - > we > have had a patch for openswan. > > what do you think? > > kp Hi kp, There's another one - my development version of the Stallone NAT-PMP gateway daemon expects ifconfig as well (though I have modified the script to use ip instead.) My view: if the BusyBox ifconfig works OK we can afford 3KB of space for it. Some users will be more familiar with ifconfig syntax anyway. dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Buildtool issues
On Sun, 2011-02-13 at 10:04 +, davidMbrooke wrote: > It is not well documented in the Wiki - at least not yet. > I feel a new Chapter coming on... :-) Now written, although rather brief: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_Developer_Guide_-_Building_a_Distribution kp: Could use your help to flesh it out, if you don't mind giving away all your secrets :-) dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Buildtool issues
On Sun, 2011-02-13 at 19:58 +1100, ads...@genis-x.com wrote: > Awesome, > > ./buildtool.pl build buildenv > works a treat > ./buildtool.pl build did the job perfectly (iscsi package failed, but as > sources.cfg says it's in progress ;o). > > So far so good, the one thing I'm a little confused on, (cant' seem to find > it in the wiki) is how do I package all, as in I have everything built I wish > to now build the whole system, all .lrp etc. > I've made changes to busybox and changing a few scripts in /staging (backup > over tftp etc), but I'm a little lost on where to go from here. > > Cheers > Adam Hi Adam, It is not well documented in the Wiki - at least not yet. I feel a new Chapter coming on... :-) Once you have the buildenv built, run script "tools/buildall.sh" to compile all the sources and create all the .lrp files, based on the contents of sources.cfg. This creates file "build.html" in a date-stamped directory under /tmp which gives you a summary of success / failure for each step in the build. Then use buildimage.pl to generate an installation disk Image. Something like: fakeroot ./buildimage.pl --image=Bering-uClibc_i486_syslinux_vga --relver=4.0alpha --verbose That example creates a .tar.gz file in directory image/Bering-uClibc_i486_syslinux_vga dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Buildtool issues
On Fri, 2011-02-11 at 13:07 +1100, ads...@genis-x.com wrote:
> Hi Guys,
>
> Now that all the packages are in git I figured I would clone the latest from
> there.
>
> Alas there are some issues..
>
>
>
> [leaf@leafbuilder buildtool]$ ./buildtool.pl build buildenv
>
> make the list of required source packages: linux,buildenv [0.K.]
>
>
>
> source/package: linux
>
>
>
> downloading: buildtool.cfg from server localrepo type filesymlnk
> /home/leaf/leaf/bering-uclibc4/buildtool/repo/linux/buildtool.cfg
> /home/leaf/leaf/bering-uclibc4/buildtool/source/linux/buildtool.cfg
>
> /home/leaf/leaf/bering-uclibc4/buildtool/repo/linux/buildtool.cfg at
> buildtool/DownloadTypes/FileSymlink.pm line 82.
>
> Cheers
> Ad
Hi Ad,
So that will be the "die($self->{'SOURCEFILE'});" at line 82 of
buildtool/DownloadTypes/FileSymlink.pm then :-)
I guess Andrew is still working on this.
As a temporary workaround to get you started:
- Delete or comment out (with #) line 82 in FileSymlink.pm
- Edit conf/sources.cfg and globally replace "localrepo" with
"leaf4-sourceforge" to match what is in all the Package buildtool.cfg
files
dMb
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] next steps
On Wed, 2011-02-09 at 23:50 +0200, Andrew wrote: > 09.02.2011 00:05, KP Kirchdoerfer пишет: > > Am Sonntag, 6. Februar 2011, um 12:14:16 schrieb ads...@genis-x.com: > >> Is anyone able to push all the contrib packages into git? > > All package sources has been moved into git. > > kp: Thank you. I know how much work that must have been. You are a hero! > > Pls test and give feedback if it works - or report back errors you detect > > while building the packages. > > > > thx kp > > > All looks OK. > I moved all sources into buildtool/repo dir, and added new server type - > 'filesymlnk' that works like 'file' server type, but just creates > symlinks instead of file copying - to avoid space wasting. Now all > sources are placed into single place and it is no needed to re-download > all of them from overloaded SF servers. > Of course, this is a dirty hack; in future it'll be good to rewrite > buildtool logic to work with source tree w/o copying of files (or even > choose other building environment) - but it'll be later. > > P.S. I think that we should move all from bering-uclibc4 dir into root > of git? I think that in any case we shouldn't have 2 or more branches > paralelly into one repository - it's easy to create new repo for major > modifications, and it's easy to maintain separate repo branches for > minor changes. IMHO we should retain a "bering-uclibc4" level somewhere. Git is for the whole of LEAF, not just for bering-uclib4, and one day there will be a bering-uclibc5... Right now we have a repo called "leaf" within a project called "leaf". How about naming the repo to "bering-uclibc4" and then removing "being-uclibc4" as a directory level within the repo? dMb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] next steps
On Sat, 2011-02-05 at 12:32 +, davidMbrooke wrote: > On Thu, 2011-02-03 at 07:07 -0800, Mike Noyes wrote: > > On Tue, 2011-02-01 at 23:08 +0200, Andrew wrote: > > > This is quite easy: do git clone and set personal data (name/email); > > > copy bering-uclibc/apps and bering-uclibc/contrib into git dir; modify > > > config files (replace server names) into sources' buildenv.conf; do git > > > add * and then do git commit and git push. > > > After short look in leaf-commits mailing list, in current git snapshot > > > only last busybox commit (update to 1.18.2) is missed. > > > > Andrew, > > Is git functional for continued development, or are further actions > > necessary? > > > > Everyone, > > Here are a few links to help everyone get up to speed on git: > > > > http://sourceforge.net/apps/trac/sourceforge/wiki/Git > > http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html > > http://git-scm.com/documentation > > > > GitWeb > > http://leaf.git.sourceforge.net/ > > Thanks Mike. I have created a new wiki page for hints and tips on using > Git for LEAF as Appendix 2 in the Developer Guide, direct link is: > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM > > Personally I am new to Git and I plan to spend several hours > investigating it over the weekend. I have already spotted some things > that I think could be improved (see the Discussion page on the wiki) so > I suggest the main developers review the status in a couple of days. > I have no doubt that Git is the right new SCM tool for LEAF but it has > some different concepts from CVS and we may need to refine our approach. > > dMb Personally I am now through the pain barrier with Git, so I'm happy to use it in preference to CVS from now on. In fact, I'm *almost* at the point where I prefer it to CVS, though I keep typing "cvs add" by mistake... :-) Are we all agreed on that - do we now use Git even when (if?) CVS comes back on line? I believe the -beta2 busybox update is still missing in the Git snapshot, and as per other mails on this list there are still many packages to migrate from the pre-4.x CVS branch. dMb -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] next steps
On Sun, 2011-02-06 at 12:17 +, davidMbrooke wrote: > On Sun, 2011-02-06 at 22:14 +1100, ads...@genis-x.com wrote: > > Is anyone able to push all the contrib packages into git? > > Hi Ad, > > Your messages aren't showing up in leaf-devel for some reason, even > though you seem to specify the right address in the "Cc:" field. > > There are people with the capability to push to git, but maybe they > don't have the time or the motivation right now :-) > > I see that kp has made a start (haserl and pwcrypt). > > Do you have a definitive list of what is missing? I can do a few > Packages but I don't have time to do 20. I am still learning Git (and > writing the Wiki page as I go) which slows things down. > > I suspect that Git is also wide open for write access right now, so > others could help with this job if we can co-ordinate the team. > > dMb I have added a few of the missing source Packages: - keyboard - hdparm (which was WAY out of date so I upgraded to the latest) - this also fixes the failure on hdsupp - upnpbridge - pcre (also old so I upgraded) - this also fixes the failure on kismet Plenty more to fix though! dMb > > -Original Message- > > From: davidMbrooke [mailto:dmb.leaf-de...@ntlworld.com] > > Sent: Saturday, 5 February 2011 11:32 PM > > To: leaf-devel > > Subject: Re: [leaf-devel] next steps > > > > On Thu, 2011-02-03 at 07:07 -0800, Mike Noyes wrote: > > > On Tue, 2011-02-01 at 23:08 +0200, Andrew wrote: > > > > This is quite easy: do git clone and set personal data (name/email); > > > > copy bering-uclibc/apps and bering-uclibc/contrib into git dir; > > > > modify config files (replace server names) into sources' > > > > buildenv.conf; do git add * and then do git commit and git push. > > > > After short look in leaf-commits mailing list, in current git > > > > snapshot only last busybox commit (update to 1.18.2) is missed. > > > > > > Andrew, > > > Is git functional for continued development, or are further actions > > > necessary? > > > > > > Everyone, > > > Here are a few links to help everyone get up to speed on git: > > > > > > http://sourceforge.net/apps/trac/sourceforge/wiki/Git > > > http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html > > > http://git-scm.com/documentation > > > > > > GitWeb > > > http://leaf.git.sourceforge.net/ > > > > Thanks Mike. I have created a new wiki page for hints and tips on using Git > > for LEAF as Appendix 2 in the Developer Guide, direct link is: > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x > > _-_Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM > > > > Personally I am new to Git and I plan to spend several hours investigating > > it over the weekend. I have already spotted some things that I think could > > be improved (see the Discussion page on the wiki) so I suggest the main > > developers review the status in a couple of days. > > I have no doubt that Git is the right new SCM tool for LEAF but it has some > > different concepts from CVS and we may need to refine our approach. > > > > dMb -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
