Hi Erich
Am 03.01.2017 um 19:59 schrieb Erich Titl:
> Am 03.01.2017 um 16:04 schrieb Martin Hejl:
>> Hi all,
>>
>> the shorewall init script for 6.0.1 in /etc/init.d/shorewall currently
>> reads (relevant part only):
>>
>> ==
Hi all,
the shorewall init script for 6.0.1 in /etc/init.d/shorewall currently
reads (relevant part only):
=
start() {
echo "Starting IPv4 shorewall rules..."
wait_for_pppd
[ -x /usr/sbin/mount_modules ] && /usr/
Hi all,
there seems to be an issue with dropbear on Bering uClibc 6.0.1 - trying
to connect to it with putty fails with the following error:
"Couldn't agree a key exchange algorithm"
It looks like the defines to enable Diffie Hellman key exchange
(DROPBEAR_DH_GROUP1 and DROPBEAR_DH_GROUP14) ar
Hi Erich,
> I am not a lawyer, so I have the right to be convinced that
> as long as the source code of the project can be provided AND we
> document where it came from, that should be sufficient.
You're not a lawyer, and neither am I - but the rules set out at
http://sourceforge.net/apps/trac/si
Hi David,
of course, I'm only speaking for myself - but I like the logo very much.
Very generic and simple. To me, it brings across the idea of a framework
nicely, and the "leaf" idea is very well incorporated as well.
So speaking for myself, I'd be very happy with that logo for LEAF.
Martin
Hi Yves,
> i'm so sorry.
I'm sorry for my unfriendly first mail.
> My REAL name is Yves Blusseau from France. I have reconfigure my email system
> so it will never happen again.
Oh - so your mail client replaced your name with the "***"? If so, my
comment was even more out of line. Sorry again.
Hi kp,
> I know always/mostly used our (full and ) real names, and I see your
> point,but then, I think it's also questionable to respond to a new
> member the very first time.
Probably not, and for that I apologize (I probably shouldn't go through
my unread emails at midnight on a friday...)
I'
Dear
I wonder how " " is pronounced (either in French, or in
English, or German, if you prefer).
I don't speak for anybody but myself - but if you want to be part of a
team, don't hide behind a throw away email address and a name that
cannot be pronounced in any lang
Hi kp,
> To save 300kb we may better have a look into initrd-i486 or improve a
> script Erich posted some time ago, that adapts initrd to the modules
> really needed, which will be an one-time-effort - and serves all images.
sounds sensible to me. If we can have both (faster boot times, while
sti
Hi kp,
> It does cost about 300kb. Agreed that is a lot, but there is still room
> for improvements in other areas (AFAIK iptables and ip6tables has been
> merged, shorewall may shrink with the future versions) and finally speed
> and size will improved if we carefully cleanup initrd for i486 imag
eforge.net/apps/trac/sourceforge/wiki/Git#Commitemailhooksetup
>
> On Sat, 2011-08-06 at 22:42 +0200, Martin Hejl wrote:
>> Same here - having a commits list makes it easy to keep track of what's
>> happening (and possibly even avoid the redundant work, that Erich has
>> b
Same here - having a commits list makes it easy to keep track of what's
happening (and possibly even avoid the redundant work, that Erich has
been pointing out). So, if it can be set up, by all means, please do so.
I'll subscribe to it as soon as it's set up.
Martin
Am 06.08.2011 22:28, schrie
?).
Short version is, I'm still confused about operating this git thing :-)
Martin
Am 23.07.2011 20:21, schrieb KP Kirchdoerfer:
> Am Samstag, 23. Juli 2011, 19:53:17 schrieb Martin Hejl:
>> Hi everybody,
>>
>> it appears that the busybox version of inetd doesn't c
Hi everybody,
it appears that the busybox version of inetd doesn't create a pidfile,
hence "svi inetd stop" doesn't work (and "svi inted start" doesn't
notice it's already running).
The attached patch seems to fix the issue for me
Martin
--
I have always wished for my computer to be as easy
Hi kp,
>> - dropbear vs. sshd suite (dropbear does not appear to support sftpd)
>> - dnsmasq vs. djbdns suite and dhcp
>> - pump vs. isc-dhcp client vs. dhcpcd
>> there must be more of those...
>
> openvpn vs openswan? :))
I'm all for dropping unneeded extra packages (and sshd suite would be
one
Hi Erich,
> If we stick with the buildtool code I would suggest to port the
> _makeEnvString ($$) method from buildtool::Make::Source to
> buildtool::Make::Common. I have not completely checked this though.
> Maybe Martin would know.
I wouldn't - for all I know, I didn't write the code (
http://
Hi kp,
> 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?
I don't know if it's required, but just to be sure: feel free to publish
any documentation I have written under any reasonable* license
(CC
Hi Erich,
>> Sorry - I do not remember what exactly went wrong (and what I did to
>> solve the problems) almost 7 years ago...
>
> No surprise, I would believe the configure system for openssh has
> evolved some too.
hopefully it has, since it was a mess back then, from what I remember ;-)
Martin
> I tested without the patch and it compiled, how did you determine that
> the native openssl library leaked into openssh?
Most likely by trying it without a patch first. Things ended up breaking
during the compile, and while fiddling with things, I figured out that
things worked with that change
>> I don't know why we need to patch configure.ac for openssh in such a
>> drastic way, maybe someone can tell me. It will break with every new
>> release of the underlying ssl library.
>
> The question maybe answered by Martin, who wrote the buildtool.* files
> (looking
> into sources it is note
Hi David,
> 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
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
e
Am 08.02.2011 18:36, schrieb Andrew:
1. The contents of modules.tgz have UID/GID 1000/1000 rather than 0/0.
Perhaps buildimage.pl was not run using "fakeroot"?
>>> Yes, I missed that. Changed my notes.
>> +# Check we are running as (fake)root
>> +warn "WARNING: Not running as (f
Hi David,
> One practical challenge is that AFAIK most systems only PXE boot from
> the "WAN" NIC,
Indeed, that's also been the case for all of the PXE enabled boxes that
I've played with.
> so a bit of cable swapping will be required in order to
> boot from a machine on the internal network. Wo
Hi dMb,
Am 30.11.2010 22:51, schrieb e-mail dmb.leaf-devel:
> It *should* work but right now we have a problem with
> /sbin/fdisk from hdsupp.lrp which I have just confirmed - See
> http://sourceforge.net/apps/trac/leaf/ticket/11 :-(
Well, if all else fails, you might try booting with Bering uClin
Hi Per,
> Booted OK but stuck on /dev/sda1 does not exist as no partition exist.
>
>
> Tried several ways of creating a partition with no .
> Linux host does not recognize a filesystem.
>
> I also tried making a disk.img with qemu-img and from
> qemu -cdrom sysrecover.iso -hda disk.img -boot orde
Hi everybody,
if I'm not mistaken, support for the GPIO ports of the Elan and SC1100
processors are already included in kernel 2.6 (never tried it though),
so the gpio package is no longer needed.
Martin
Am 25.10.2010 16:34, schrieb davidMbrooke:
> On Mon, 2010-10-25 at 23:17 +0200, Erich Titl
Am 01.10.2010 22:47, schrieb Martin Hejl:
just to avoid misunderstandings
> (and to others working on the project, at least
> this was the case the last time this kind of thing was talked about on
> and off the list).
I should have said "and to those who work on the project"
Am 01.10.2010 22:24, schrieb Enrico Weigelt:
> For example bash:
>
>
> http://pubgit.metux.de/download/oss-qm/bash/VENDOR::leaf::bash-2.5.2.5.tar.bz2
>
>
> BTW: we really should consider upgrade these ancient packages ;-)
Well, remember, leaf is a distro that up until the latest (upcoming)
Hi Mike,
>> On that page it's mentioned 'FRS or other project resources' - so IMHO
>> at least it'll be good to ask about this to SF support - will
>> git/svn/etc snapshot meet source availability requirements.
>
> I'll talk with SF staff next week.
As always, I very much appreciate your help.
Th
Am 01.10.2010 11:38, schrieb Andrew:
>> So, looking for a different SCM, might be interesting (and
>> possibly/probably provide benefits) - but it doesn't address the issue
>> that we're not providing sources for binary releases in FRS.
>
> Source availability requirements are applicable for all ve
Am 30.09.2010 22:06, schrieb Enrico Weigelt:
> hmm, one thing we could do is:
>
> #1: adding download protocol specifiers, eg.:
>
>
> Protocolcurl
> URL http://
>
>
> (if no protocol is given, falling back to cvs)
>
>
> #2: adding a new object type "t
Am 30.09.2010 18:48, schrieb Enrico Weigelt:
> Of course. Perhaps you could explain the current process from
> fetching the tarball (and maybe other files, eg. patches) until
> the local source tree is set up and the actual package build begins
> to me. I'll try to find a solution for a soft migrat
Am 30.09.2010 19:22, schrieb Enrico Weigelt:
>> We also have the requirement (per Sourceforge terms of use) to provide
>> the sources for a binary release in the FRS (which we currently don't
>> do, since according to the link Mike provided, having those sources in
>> CVS is not sufficient).
>
> I
Hi Mike,
>> By the way - are you aware of a way to automate the process of uploading
>> something into FRS, apart from using some form of screen-scraping the SF
>> website?
>> Never having used the FRS in any shape or form, I'm afraid I don't know
>> much about it - other than hearing from a coupl
Am 30.09.2010 17:07, schrieb Enrico Weigelt:
> Recoursive wget would perform much better. CVS isn't particularily
> well suited for such things.
Possibly - I don't really want to get into an argument about what SCM
works better for whom under what circumstances (I'll leave that
discussion to othe
Hi Mike,
>> To me it sounds (if we want to stay in line with the terms of use with
>> SF), that we either do that (but then, what actually _is_ a "binary
>> releases made via our File Release System or any other project resource"
>
> Martin,
> The SF policy applies to the FRS only. If you release
Hi Erich,
> Either way, what is the canonical way to keep an existing build
> environment in sync with CVS. Buildtool does not check for modifications
> once a package is built.
since nobody else chimed in (and since I'm partly to blame for some of
the shortcomings of buildtool), I'll respond - I
Hi kp,
> (btw: the issue started with DavidMBrookes question, if sources should go into
> cvs or not? The discussion drifted away - any ideas on that topic?)
I'd say yes - it will be easier that way to provide a source tarball
(whatever that has to include remains to be seen) if it's decided we
Am 29.09.2010 08:38, schrieb Andrew:
> On 28/09/10 22:19, Martin Hejl wrote:
>> To me it sounds (if we want to stay in line with the terms of use with
>> SF), that we either do that (but then, what actually _is_ a "binary
>> releases made via our File Release S
Hi kp,
> Thx for the pointer.
>
> AFAIK that reads that we have to provide a tarball of our cvs with each and
> every release (currently 108M).
I didn't really want to respond to Mike's mail, since I was hoping that
I was misreading the implications. But unfortunately, I read the page
the same w
Hi Andrew,
> This cause on my system troubles with initrd package building through
> buildall script. Why it was done in that way? Possible it'll be good
> (and safe) to remove fakeroot call?
fakeroot (or "real" root) is needed for buildpacket because it needs to
"chown" the files before putting
Hi Mike,
> KP,
> See:
>
> http://leaf.cvs.sourceforge.net/viewvc/leaf/src/bering-uclibc4/
Something doesn't seem to be quite right either with the cvs-commits
list, or with Andrew's permissions to post to that list - at least,
that's how I read the total lack of messages on that list for the com
Hi everybody,
> the UnNamedOne was a "design study" two years ago by Martin Hejl, which is
> different from Andrews work.
the first part is not quite true - it was a joint effort by Dirk Gförer,
Eric Spakman and myself (and truth to be told, my part in it probably
was the small
Hi Mike,
> What assistance will help with 'buildtool' conversion from cvs to git?
>
> http://leaf.cvs.sourceforge.net/viewvc/leaf/src/bering-uclibc/buildtool/
For starters, somebody who knows something about git (if that person was
also a perl hacker, even better. But the code should be commente
Hi Mike,
> I'm willing to resume my duties as list manager.
feel free to do so if you'd like to. Due to the fact that the lists have
been _very_ low traffic lately (apart from the spam that's automatically
discarded), it's not been a burden - but if you'd like to take care of
the lists again, t
Hi Mike,
> Are there any objections to deleting the following mailing lists:
>
> leaf-announce, leaf-auto, leaf-hardware, leaf-wisp-dist
No objections at all - they've done nothing but receive spam for quite a
while now.
> leaf-cvs-commits (rename to leaf-commits, or delete in favor of
Hi Erich,
> Somehow this HOSTCC stuff is weird, in the process of building buildenv
> a gcc 3.3.3 is downloaded, despite all definitions im MasterInclude.mk.
I'm not sure what's so weird about it - it works the exact same way as
the Bering uClibc branch (unless things have changed since early 200
Hi again,
ok, forget what I just wrote - the instructions below are no longer
accurate, since kp just changed the config in CVS
Martin
Martin Hejl schrieb:
> Hi Erich,
>
>> I decided to give it a try and build a buildenv. Unfortunately I did not
>> get very far
>>
Hi Erich,
> I decided to give it a try and build a buildenv. Unfortunately I did not
> get very far
>
> source/package: linux
>
> downloading: buildtool.cfg from server cvs-sourceforge type file
> download failed: file ../apps/linux/buildtool.cfg does not exist
The follo
Hi kp,
> it seems that the cvs-commit mailinglist or the feature that commits activate
> a message on that list is broken.
> I've heard of various pb's with the latest SF platform update, maybe this ir
> related?
as discussed off list, the missing cvs-commit messages from our new team
memeber
Hi John,
>> this is a little depressing. After spending years (and tons of emails)
>> discussing the need for a kernel 2.6 version of LEAF, there has been
>> no response on this list on the topic.
>
> Sorry, Martin, I only read the list as a newsgroup, every week or so.
No problem. I just started
Hi David,
> I'm sort of fishing for stories about why that might be a bad idea, beyond
> that 1: it varies from standard practice and 2: the initramfs is not backed
> by swap, as normal shmfs is
Well, one downside of this approach is that you cannot control the size
of the root-fs by a variable in
oops - sorry
> Hi Nicol,
make that "Hi David"
sorry about that
Martin
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct
Hi Charles,
> Besides driver issues, another reason to migrate to a 2.6 kernel is
> support for IPV6, which will become vastly more important in the years
> to come, particularly outside the US, where the IPV4 address pool is
> already beginning to be exhausted.
Good point. I haven't had to touch
Hi Nicol,
thanks for your feedback,
> I had no trouble running the 3.1 release candidate with a static 2.6 kernel;
Well, but doesn't a static kernel (I assume you mean that everything you
needed was compiled into the kernel statically, rather than as a module)
pretty much stand against everythin
Hi Paul,
thanks for your feedback
> With that
> experience,
> my question would be, what significant benefits does the 2.6 kernel
> provide to a minimalist system?
For me, the main reason was new drivers. It appears that more and more
things are only added to the 2.6 kernel, and not to the 2.4
Hi Erich,
> And for all your effort which point into the future here it is _WELL DONE_
;-)
> One of my concerns in the 2.6 branch will be IPSEC, as now we need to
> use the native stack. It appears that with using the native stack IPSEC
> will be an application like any other, so we may have now
Hi Mike,
>> I didn't expect a storm of activity - but I (perhaps foolishly) expected
>> some sort of response. I'm not looking for a "good job, well done"
>> response - but some sort of feedback that somebody is actually giving
>> the latest developments a try would be helpful. Without any kind of
Hi all,
this is a little depressing. After spending years (and tons of emails)
discussing the need for a kernel 2.6 version of LEAF, there has been no
response on this list on the topic. Is somebody actually interested in
continued work on that image (and has just not had an issue with it what
I'v
Hi Mike,
> "LEAF - Linux Embedded Appliance Framework"
>
> Everyone,
> We seem to have agreement on a name switch from Firewall to Framework. I
> think we can make this change now, and continue work on a description
> for later adoption. Is this acceptable?
fine with me
Martin
Hi kp,
> I agree with you, that the main usage scenario is to build a network
> appliance
> with LEAF and most of them also acting as firewall.
>
> Anyway I think it has grown from a "firewall" to a "framework".
That's something I have no issues with - even though, that seems to a
change be t
Hi all,
KP Kirchdoerfer wrote:
> I always preferred the second one and that's, what I started with to
> enhance/change it:
>
> "LEAF is a Linux Embedded Appliance Framework.
> Branches provides various appliance-oriented tasks: LAN/WAN router, Internet
> border router/firewalls, wireless acces
Hi everybody,
for the last few weeks, Dirk Gfroerer, Eric Spakman and myself have been
working on getting kernel 2.6 to work with Bering-uClibc. By now, we
have things working enough that we feel it's fit to be shown to the
other leaf developers out there. It is by no means ready, probably not
eve
Hi Erich,
please keep replies on the list
> Thanks for the info, I tried to diff the buildtool tree, only got my own
> changes though.
>
> cvs diff: Diffing . (...)
That's not how "cvs diff" works. From the man page:
"The default action is to compare your working files with the revisions
they w
Hi Erich,
Erich Titl wrote:
> KP Kirchdoerfer schrieb:
>> I've commited the appropriate changes in buildtool.pl and
>> buildtool/Make/Source.pm.
>>
>> I've tested the changes on a newly build buildenv on kubuntu 7.04.
>>
>> It needed one change to build the buildenvironment - /bin/sh has to have
Hi Erich,
Erich Titl wrote:
> Hi Martin
>
> I have defined a number of links in my buildtool.cfg file, like
>
>
> Filename= usr/lib/cups
> Type= link
> Target = data/cups/usr/lib/cups
>
>
> Which suggests that the target di
Martin Hejl wrote:
>> Is it used to build
>> the package hash, and if so wouldn't that necessitate all files to be of
>> type 'list'?
> Nope - all files in the package are automatically added to ".list" - the
> keyword in buildtool.cfg is to ad
Hi Erich,
>>From this document it is not completely clear to me which files have to
> have the type 'list', because I don't know, what the .list file is
> actually used for now that we have the new configdb.
I don't think it is used for anything anymore (I don't see a single
buildtool.cfg file i
Hi Erich,
> While we're at it (and the document is still botched) is there a
> sepcific Type for symbolic links?
yup, there is.
See
http://leaf.sourceforge.net/doc/bucd-buildpacket.html (without the
colon, I should have put a space between the URL and the colon - sorry
about that)
In short:
Type
Hi Erich,
> I am about to build a cups package and I am wondering what entry is
> needed in buildtool.cfg to create an empty directory in the package, e.g.
>
>
> Filename= var/spool/cups
> Source = var/spool/cups
> Type= directory ?
>
yup, that's almost r
Hi Erich,
ok, this will have to be quick, since I have to work tomorrow - so
forgive me if I overlook something...
> - but we'd surely burn a lot of disk-space on the SF
>> servers...
>
> We would indeed, but hardly more than we do right now.
Actually, we would - since the sources would not be c
Hi Erich,
> Thank you, the biggest problem was to find the correct place for a
> module, in this case the r1000 thing. I don't know if a module sent to
> contrib gets included into the lib/modules tree/tarball.
Not as far as I know. Eric might be able to help with that.
> would you guys be think
Hi Erich,
> Now the question, I am apparently a bit too dense to understand the CVS
> setup for bering-uClibc.
>
> What _exactly_ do I have to do to to contribute it correctly. I have had
> limited success with the r1000 module I contributed.
Sorry for the late reply.
For the sources, it's quite
Adam Niedzwiedzki wrote:
> Resend, I couldn't attach the zip'd logfile (it can be gotten from
> http://www.genis-x.net/buildtoollog.zip)
tried it on Centos 5, and it works fine without any problems (well, I
temporarily had to replace gcc 4.1 with gcc 3.x, but that's a known
issue, and I think it'
Hi Mats,
since nobody else has spoken up so far, I'll give it a shot.
First of all, remember, I'm speaking for nobody but myself (seems like
in the past, statements of individual developers were misunderstood as
being the group's point of view).
Then, this kind of discussion is probably suited b
Hi Mike,
> I conclude you're
> indicating the UI looks to complex to grasp in a short time.
the UI isn't the problem - it's more about the time required to figure
out how to use everything properly (i.e. read the documentation provided).
It looks easy enough, but that doesn't change the fact that
Hi Mike,
> Is there a reason I'm the only one that's done anything with the new
> wiki?
as always, I can speak only for myself - but I'm going to assume that I
speak for at least a few of the developers who might look at the wiki at
some point.
While the wiki might be a big help down the road, at
Hi kp,
> the mailing list archive on SF is not up to date. The last archived messages
> for leaf-user is Feb 23th. Are there any known issues? SF status does not
> show a pb related to mailing list archives.
I've opened a tracker - see
https://sourceforge.net/tracker/index.php?func=detail&aid=16
Hi Mike,
Mike Noyes wrote:
> Martin or I should probably contact Vladimir, and inquire if the
> leaf-wisp-dist mailing list is still necessary.
leaf-wisp-dist currently has 150 subscribers, but it's extremely low
traffic (last message from November, as far as I can see).
I don't have an issue with
Hi Erich,
Erich Titl wrote:
> Starting with bering-uclibc3.x I observed an error when trying to use
> ssh/scp.
>
> debug2: calling socket with 10 , 1 , 6
> socket: Address family not supported by protocol
>
> This is due to the fact that the socket call is using an address family
> of inetv6 by
Hi Paul,
> lrpstat & friends aren't in the packages directory
lrpstat is commented out in conf/sources.cfg because it needs a jdk plus
some extras (a classes.zip file from a 1.1 JDK) to compile.
See the note in conf/sources.cfg what you need in order to build lrpstat
Martin
---
Hi Erich,
> OK, i have to admit it, I do not grok this buildtool.
>
> What is the canonical way to get up to date without building buildenv
> again?
There is no canonical way. The short version is that there simply isn't
any way to get the buildenv up to date, because it would most likely
caus
Hi Erich,
> BTW. does anyone know why S/MIME signed messages are _not_ showing up on
> the list?
most likely because the messages had a content type other than
multipart/mixed
multipart/alternative
message/rfc822
multipart/signed
text/plain
Please send a signed message to leaf-devel again (I chang
Hi Erich,
> I am not sure I understand completely.
>
> Example:
>
> I want to make a small modification in the kernel configuration. What
> directory will these changes be made in, as it is neither in apps nor
> contrib. Basically the sources reside in
>
> $BUILDROOT/source/linux/
>
> the mods
Hi Erich,
>>If you change the config, the safest way (I'm going from memory here, I
>>didn't double-check this) would be to do
>>
>>$ ./buildtool.pl srcclean busybox
>>$ ./buildtool.pl build busybox
>
>
> I am afraid this will erase my modifications.
No, it won't, unless you're making the modifi
Hi Erich,
sorry - I'm not around the computer much these days, so don't expect
speedy responses from me for the next few weeks.
> I found that in the corresponding apps/busybox, there is no unpacked
> busybox source. Will buildtool use such a source when it exists or just
> unpack the tar archive
Hi Erich,
> I know you want to avoid branches in CVS. What is the canonical way to,
> let's say
>
> - replace openswan with strongswan and still track current kernel
> development/configuration..
don't know about that one - the whole *swan integration into the kernel
is a bit obscure (due to the
Hi everybody,
now that CVS is back up again, we could finally add the tags for the
2.4.1 release of Bering-uClibc and test the ideas we had for how one
could build a specific release.
So, the sources in CVS are tagged (reflecting the state of CVS when
2.4.1 was released) - the tag name is "Releas
Hi Mike,
> It is operational now. The SF staff had to restart xinetd on that
> server.
Indeed - seems to work nicely now. Thanks.
Martin
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-de
Hi Mike,
> Rsync should be available from SF now too. Please check it if you have
> the time. Thanks.
>
> rsync://leaf.cvs.sourceforge.net/cvsroot/leaf/*
Either I'm doing something wrong, or rsync doesn't work yet - all I get is:
rsync: connection unexpectedly closed (0 bytes received so
Hi Andrea,
> What happens: is really run only the first time. A very easy workaround
> is to change in:
>
> #include common.cfg
> #include common1.cfg
> #include ...common2.cfg
>
> and so on. Simply create links with ln, and all initrd packages are
> built correctly (with ash, linuxr
Hi Charles,
> You don't understand how subversion works.
I never claimed otherwise ;-)
> It's like a file-system and
> making a tag or branch is like copying a directory. Everything
> underneath is copied too.
Well, to me, the way things are stored in the backend are pretty much
meaningless (l
Hi Charles,
> This is where subversion's branching would really shine. You would
> simply change the repository URL in the main config file and 'head'
> would point to the latest version of that branch, which is probably what
> you'd want (ie: security updates/bug fixes included).
Ah, ok, I get i
Hi Charles,
> This might be one benefit to subversion.
It might be (I don't know, I've not used subversion so far). But the
problem I see for buildtool is not so much that it's too hard to fetch a
file for a specific branch, but rather that buildtool currently isn't
fetching anything other than HE
Hi again,
Martin Hejl wrote:
> * Check out src/bering-uclibc/buildtool for the release branch of 2.4.1
> * check out src/bering-uclibc/apps for the release branch of 2.4.1
> * modify cvs-sourceforge use the "file" target for server
> cvs-sourceforge and make it point
Hi Mike,
> Is buildtool able to use a checked out working copy to build from?
It is, if one adjusts the main config (changes the "cvs-sourceforge"
server setting in conf/sources.cfg to use the "file" type, which will
use the local filesystem rather than CVS). But wether that will work to
build an
Hi Erich,
> I assume the code within buildtool to access a certain file is pretty
> central. How difficult is it for this piece of code to use an
> environment variable specifying a TAG (defaulting to HEAD).
It is, but that doesn't solve the problem. The idea behind buildtool is
that it can use wh
Hi Mike,
Mike Noyes wrote:
> Subject was: Re: [leaf-devel] Glitch in initrd backup when using
> alternative initrdfile
>
> On Fri, 2006-05-05 at 02:58, Eric Spakman wrote:
>
>>>How does one to go about building the buildenv for a specific release,
>>>e.g. does CVS have release tags? For example
Hi Erich,
> Thanks for the clarification. The release tags would not hurt though.
Sure.
>> When making a checkout from CVS, remember to use a SF developer account
>> - synching between the "real" CVS server and the backup server (which is
>> used for anonymous access) still doesn't seem to work (
1 - 100 of 196 matches
Mail list logo
