On Thursday 12 May 2005 11:10, Mike Noyes wrote:
> On Thu, 2005-05-12 at 05:43, Nathan Angelacos wrote:
> > I would like write access (I just tried to commit something and just got
> > an access denied message.)
> >
> > I think you could also add the core Bering-uClib core team as well.
>
> Nathan,
On Thu, 2005-05-12 at 05:43, Nathan Angelacos wrote:
> I would like write access (I just tried to commit something and just got an
> access denied message.)
>
> I think you could also add the core Bering-uClib core team as well.
Nathan,
Done. Please let me know if you have any problems.
--
Mik
Mike,
I would like write access (I just tried to commit something and just got an
access denied message.)
I think you could also add the core Bering-uClib core team as well.
Thanks.
On Friday 22 April 2005 10:55, Mike Noyes wrote:
>
> Nathan,
> I had the SF staff move webconfig source. Please
On Thu, 2005-04-07 at 09:54, Nathan Angelacos wrote:
> Just to make things completely confusing...
Nathan,
I had the SF staff move webconfig source. Please let me know who you
wish to have write access.
mv /cvsroot/l/le/leaf/devel/nangel/webconf/src
/cvsroot/l/le/leaf/src/config/webconf
--
Mi
Hi Erich,
>But seperating binaries would mean yet another dependency and again
>an extra package.
>
>
>More flexibility though
Why? You need haserl and pwcrypt anyway, I don't see why seperating
it would be more flexible.
>I disagree about mini-httpd to be part of webconf, both haserl and
>pwcr
Eric Spakman wrote:
Erich,
Sure, I have no problem with backporting this when necessary. Like I
said, buildtool will makes this a matter of minutes. In the case we
change to a new uClibc version, I (we) will keep the previous
crosscompiler around.
I agree that seperating binaries from scripts e
Erich,
Sure, I have no problem with backporting this when necessary. Like I
said, buildtool will makes this a matter of minutes. In the case we
change to a new uClibc version, I (we) will keep the previous
crosscompiler around.
I agree that seperating binaries from scripts eliminates this to s
Eric
Eric Spakman wrote:
Erich,
Webconf is ported to buildtool, so making packages for a new uClibc
version would only mean run buildtool to automatically recompile and
create the packages.
Sure, but will you backport? Separating binaries from scripts eliminates
this. Else one could argue tha
Erich,
Webconf is ported to buildtool, so making packages for a new uClibc
version would only mean run buildtool to automatically recompile and
create the packages.
Eric
-
I recall suggesting this. Just as an example, one fine
Nathan
Nathan Angelacos wrote:
...
3. REMOVE the uclibc binaries from webconf.lrp and make EVERYONE choose a
library specific plugin? (Probably architecturally correct, but it will be a
mess trying to support - "I downloaded webconf.lrp and it doesn't work... You
have to download your appropria
Am Donnerstag, 7. April 2005 20:33 schrieb Mike Noyes:
> On Thu, 2005-04-07 at 11:13, K.-P. Kirchdörfer wrote:
> > Don't wait for the SF sandbox - I'm waiting for reactivated cron
> > for a few month.
>
> K.-P.,
> Cron won't help at this time (see SF SR below). All it would do,
> since my daily.sh
On Thu, 2005-04-07 at 11:13, K.-P. KirchdÃrfer wrote:
> Don't wait for the SF sandbox - I'm waiting for reactivated cron for a
> few month.
K.-P.,
Cron won't help at this time (see SF SR below). All it would do, since
my daily.sh script has no error checking, is remove our current exported
conten
Nathan;
Am Donnerstag, 7. April 2005 18:54 schrieb Nathan Angelacos:
> Thanks Mike,
>
> Just to make things completely confusing...
>
> webconf.lrp is a bunch of shell scripts plus 2 programs compiled
> for bering-uclibc. So there /is/ a dependency there.
This will end up in /bin/packages/ucli
Thanks Mike,
Just to make things completely confusing...
webconf.lrp is a bunch of shell scripts plus 2 programs compiled for
bering-uclibc. So there /is/ a dependency there. However, there are plugins
(lwp's) that contain /just/ the 2 binaries. (E.g. Erich Titl's wc207.lwp.
It makes webco
On Thu, 2005-04-07 at 04:55, Nathan Angelacos wrote:
> There are two different things in the present webconf cvs repository:
>
> Source code for the core; and I assume that it could go in config (or stay
> under devel/nangel)
>
> binary lrps & lwps; and for the binary "packaged" versions, K.-P.
Mike,
There are two different things in the present webconf cvs repository:
Source code for the core; and I assume that it could go in config (or stay
under devel/nangel)
binary lrps & lwps; and for the binary "packaged" versions, K.-P. makes a good
point - the finished packaged stuff should
Hi Nathan,
be careful with "moving" - that's a good place for beta's and new
developements...
I'd suggest a lwp reository in nolibc or something like that.
kp
Am Mittwoch, 6. April 2005 23:02 schrieb Nathan Angelacos:
> Mike,
>
> I'm all for anything that lets others share in development and
Mike,
I'm all for anything that lets others share in development and removes me as
the bottleneck. :-)
Your suggestion sounds great. Thanks!
The only thing is when it is moved, the webconf page will need to be updated
to link to the moved repository.
On Tuesday 05 April 2005 20:19, Mike No
On Tue, 2005-04-05 at 16:07, Nathan Angelacos wrote:
> I will be happy to post your webconf plugins in with the existing plugins for
> you. (Currently they are stored in my leaf devel cvs tree.)
>
> If you write a webconf plugin and would rather keep it somewhere else, thats
> fine too - if y
I will be happy to post your webconf plugins in with the existing plugins for
you. (Currently they are stored in my leaf devel cvs tree.)
If you write a webconf plugin and would rather keep it somewhere else, thats
fine too - if you drop me a note I'll put a pointer in the cvs tree giving
t
20 matches
Mail list logo
