On 29/09/10 09:52, Martin Hejl wrote:
But either way - I didn't mean to start a which versioning system
should we use discussion, especially since it doesn't matter to the
problem at hand - no matter which versioning system is used, the source
tarballs still need to be uploaded into the
On 29/09/10 23:04, KP Kirchdoerfer wrote:
I haven't checked the sources, but AFAIK linux, buildenv and shorewall are
the
only sources left, staying outside of our repository.
I agree that having everything in a snapshot can be useful.
kp
What is reason of this? Kernel, gcc, binutils,
Andrew
at 30.09.2010 13:08, Andrew wrote:
On 29/09/10 09:52, Martin Hejl wrote:
But either way - I didn't mean to start a which versioning system
should we use discussion, especially since it doesn't matter to the
problem at hand - no matter which versioning system is used, the source
On Thu, 2010-09-30 at 14:16 +0200, Erich Titl wrote:
at 30.09.2010 13:08, Andrew wrote:
-snip-
So I think that it'll be good if we will discuss about versioning system
update (which system will be more preferred to this project) - so more
opinions from members will be better than closed
On Thu, 2010-09-30 at 14:20 +0300, Andrew wrote:
On 29/09/10 23:04, KP Kirchdoerfer wrote:
I haven't checked the sources, but AFAIK linux, buildenv and shorewall are
the
only sources left, staying outside of our repository.
I agree that having everything in a snapshot can be useful.
On Wed, 2010-09-29 at 20:28 +0200, Martin Hejl wrote:
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,
Am Donnerstag, 30. September 2010, 15:48:40 schrieb Mike Noyes:
On Thu, 2010-09-30 at 14:20 +0300, Andrew wrote:
On 29/09/10 23:04, KP Kirchdoerfer wrote:
I haven't checked the sources, but AFAIK linux, buildenv and shorewall
are the only sources left, staying outside of our repository.
* Andrew ni...@seti.kr.ua schrieb:
In any way, IMHO it'll be good to switch to one of more modern
versioning system. CVS has some limitations that affects project
development process - for ex., if we will use git or mercurial (about
SVN - I don't sure because I didn't use it at all), we can
* davidMbrooke dmb.leaf-de...@ntlworld.com schrieb:
Personally I agree. On balance it seems best to snapshot the upstream
sources in our CVS and only refer to our CVS for source downloads.
I doubt that it makes sense to copy snapshots into a big fat
cvs tree (especially cvs, which doesnt scale
* Erich Titl erich.t...@think.ch schrieb:
We have SVN as a versioning system and all that happens is that any
binary crap just lands there and produces an enormous binary pile of it.
Correct me, but I believe the S in SCM means 'source'
That's probably one of the reasons, why Git calls itself
* Martin Hejl mar...@hejl.de schrieb:
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
need to, but maybe more importantly, buildtool will not break if the
location of a source changes upstream.
See
* Mike Noyes mhno...@frontier.com schrieb:
Note: CVS doesn't scale well on the server side (per SF staff).
CVS can't do diffs of binary files.
CVS has lots of other (mostly fundamental architectural) drawbacks, eg.:
* _only_ supports central-server workflows, no private
On Thu, 2010-09-30 at 17:13 +0200, Enrico Weigelt wrote:
* Erich Titl erich.t...@think.ch schrieb:
I do not see the necessity to keep a tarball in CVS.
Erich,
Agreed. This is a legacy situation forced on us during SF service
changes. Now that the FRS supports sub-directories storing packages
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
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 couple of
* Mike Noyes mhno...@frontier.com schrieb:
ACK. IMHO we don't need tarballs at all. Just keep the complete
(uncompressed) trees in Git and selectively fetching them on-demand
(instead of a full clone).
Enrico,
We'll still need source tarballs for the SF FRS.
Could be easily created
* Martin Hejl mar...@hejl.de schrieb:
Just in case it got overlooked - we have a (mostly) working setup for
creating a buildenv and packages, for storing the sources and for
generating the packages page for the homepage including a changelog.
Git has an cvs-server for such legacy purposes,
On Thu, 2010-09-30 at 18:48 +0200, Enrico Weigelt wrote:
* Mike Noyes mhno...@frontier.com schrieb:
ACK. IMHO we don't need tarballs at all. Just keep the complete
(uncompressed) trees in Git and selectively fetching them on-demand
(instead of a full clone).
Enrico,
We'll still
Am Mittwoch, 29. September 2010, 22:19:41 schrieb davidMbrooke:
Thanks kp.
On Wed, 2010-09-29 at 19:41 +0200, KP Kirchdoerfer wrote:
- I had to recompile ulog without mysql support. Despite that mysql
seems to be fixed, ulogd does not compile with mysql enabled.
I've commited
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 could
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
On Thu, 2010-09-30 at 20:16 +0200, Martin Hejl wrote:
-snip-
Regarding moving away from SF for hosting the source - that would be up
to the other project members to decide. I'm not sure if abusing (I
don't know if it would be) SF to simply provide space for a mailinglist
and homepage and
* Mike Noyes mhno...@frontier.com schrieb:
Git is already enabled for our project. Would you like me to add you to
our project, so you can assist us?
Yes, of course :)
https://sourceforge.net/apps/trac/sourceforge/wiki/Git
git://leaf.git.sourceforge.net/gitroot/leaf/REPONAME (read-only)
on 30.09.2010 15:43, Mike Noyes wrote:
On Thu, 2010-09-30 at 14:16 +0200, Erich Titl wrote:
at 30.09.2010 13:08, Andrew wrote:
So what exactly is missing and what do we gain by using another
versioning system, given, I don't know git or mercurial, but I am
missing some features of CVS in
Am Donnerstag, 30. September 2010, 20:56:16 schrieb Erich Titl:
on 30.09.2010 15:43, Mike Noyes wrote:
On Thu, 2010-09-30 at 14:16 +0200, Erich Titl wrote:
at 30.09.2010 13:08, Andrew wrote:
So what exactly is missing and what do we gain by using another
versioning system, given, I
On Thu, 2010-09-30 at 20:09 +0200, KP Kirchdoerfer wrote:
Hi;
I've enabled traceroute in busybox and can change sources.cfg accordingly.
It's yet not committed, cause I also enabled busybox ntpd and gave it test.
As a user reported for 3.x on leaf-user openntpd fails to provide the to
Hi,
Further to the earlier discussion on Bering-uClibc 4.x kernel modules I
have done some analysis of the differences from 3.x based on the
respective kernel .config files, checking for items included in 3.x but
currently *not* included in 4.x.
IMHO we should not remove 3.x functionality
* Martin Hejl mar...@hejl.de schrieb:
Hi,
For an example, look at
http://leaf.cvs.sourceforge.net/viewvc/leaf/src/bering-uclibc4/source/dropbear/
buildtool.cfg is the file that holds the package metadata, what needs to
go into the package, and the links to the sourcecode
See
Hi DavidMbrooke;
Am Donnerstag, 30. September 2010, 22:06:56 schrieb davidMbrooke:
Hi,
Further to the earlier discussion on Bering-uClibc 4.x kernel modules I
have done some analysis of the differences from 3.x based on the
respective kernel .config files, checking for items included in 3.x
Am 30.09.2010 22:06, schrieb Enrico Weigelt:
hmm, one thing we could do is:
#1: adding download protocol specifiers, eg.:
file buildtool.mk
Protocolcurl
URL http://
/file
(if no protocol is given, falling back to cvs)
#2: adding a new
Hi kp,
On Thu, 2010-09-30 at 22:53 +0200, KP Kirchdoerfer wrote:
Looking on your list and having in mind that (all?) ISDN module are missing
in
the current config, which I do not see on your list, I believe that your
comparision is for shure a start, but may be flawed by changes in the
Hi dMb;
Am Donnerstag, 30. September 2010, 23:16:40 schrieb davidMbrooke:
Hi kp,
On Thu, 2010-09-30 at 22:53 +0200, KP Kirchdoerfer wrote:
Looking on your list and having in mind that (all?) ISDN module are
missing in the current config, which I do not see on your list, I
believe that
Hi Martin,
On Thu, 2010-09-30 at 23:03 +0200, Martin Hejl wrote:
snip My point simply is that we've not been
held back by the shortcomings of CVS in any way, as far as I can tell,
and that for this reason, switching to another SCM, just because it's
better might be a waste of resources).
Hi,
It looks like we have a problem building (some) packages which use Perl
as part of the build process now that we have a full Perl package for
Shorewall.
Running tools/buildall.sh is fine, but when I manually build Perl too
early in the sequence I get an error building e.g. openssl
On Thu, 2010-09-30 at 23:40 +0200, KP Kirchdoerfer wrote:
Agreed. I did not intend this comparison to be exhaustive, just a
starting point...
That's how I understood, and hoped to say in my response.
OK, good; I was just checking you understood my intention...
IMHO the more
On Thu, 2010-09-30 at 21:23 +0200, KP Kirchdoerfer wrote:
Am Donnerstag, 30. September 2010, 20:56:16 schrieb Erich Titl:
on 30.09.2010 15:43, Mike Noyes wrote:
On Thu, 2010-09-30 at 14:16 +0200, Erich Titl wrote:
at 30.09.2010 13:08, Andrew wrote:
So what exactly is missing
36 matches
Mail list logo
