Hi KP
I got access now and commited build_upgrade in the tools repository.
I cannot check accuracy, as there is no repository available which holds
all the prerequisites. Is there a way to publish a pre_alpha with all
the relevant files in the packages directory? I might be able to work
with
Am Donnerstag, 23. Juli 2015, 11:07:57 schrieb Erich Titl:
> Hi folks
>
> Does anyone know the status of our package repository, I still don't
> have access to it
>
> mega@leafbuilder:~/leaf/devel/packages$ git pull --rebase
> ssh: Could not resolve hostname git.code.sf.net: Name or service not k
Hi folks
Does anyone know the status of our package repository, I still don't
have access to it
mega@leafbuilder:~/leaf/devel/packages$ git pull --rebase
ssh: Could not resolve hostname git.code.sf.net: Name or service not known
fatal: Could not read from remote repository.
Looks like the hos
On Fri, 2003-02-28 at 10:38, Mike Noyes wrote:
> On Fri, 2003-02-28 at 09:34, K.-P. Kirchdörfer wrote:
> > Ok, I see you really don't like the original uClibc version scheme :)
>
> K.-P.,
> Yes. I didn't think things through when I created the
> bin/packages/uclibc directory in our cvs repository.
On Fri, 2003-02-28 at 09:34, K.-P. Kirchdörfer wrote:
> Ok, I see you really don't like the original uClibc version scheme :)
K.-P.,
Yes. I didn't think things through when I created the
bin/packages/uclibc directory in our cvs repository. :-(
When uClibc reaches 1.0 we'll want a new directory. A
Ok, I see you really don't like the original uClibc version scheme :)
Am Freitag, 28. Februar 2003 17:39 schrieb Mike Noyes:
> On Fri, 2003-02-28 at 08:31, Mike Noyes wrote:
> > On Fri, 2003-02-28 at 07:49, K.-P. Kirchdörfer wrote:
> > > We need uclibc-0.9.15 like the glibc dirs...
> >
> > K.-P.,
On Fri, 2003-02-28 at 08:31, Mike Noyes wrote:
> On Fri, 2003-02-28 at 07:49, K.-P. Kirchdörfer wrote:
> > We need uclibc-0.9.15 like the glibc dirs...
>
> K.-P.,
> Would this restructuring be acceptable to the Bering-uClibc team?
>
> D) Move bin/packages/uclibc/linux-2.4.20.upx to bin/bering
On Fri, 2003-02-28 at 07:49, K.-P. Kirchdörfer wrote:
> We need uclibc-0.9.15 like the glibc dirs...
K.-P.,
Would this restructuring be acceptable to the Bering-uClibc team?
D) Move bin/packages/uclibc/linux-2.4.20.upx to bin/bering-uclibc/ .
Rename bin/packages/uclibc to bin/packages/ucl
Am Freitag, 28. Februar 2003 16:02 schrieb Mike Noyes:
> Everyone,
> I made a mistake when I originally created the 'uclibc' directory
> without major.minor numbers. I believe the name should have been
> 'uclibc-0.9'. I updated our bin/packages README with information that
> should avoid this probl
On Fri, 2003-02-28 at 07:02, Mike Noyes wrote:
> Proposed Solutions:
>
> A) Move all packages (.lrp) in bin/packages/uclibc and
> bin/pakcages/uclibc/0_9_15 to bin/packages/uclibc-0.9. Move all
> other files to bin/bering-uclibc.
Bering-uClibc team,
Here is a slight correction for cla
Everyone,
I made a mistake when I originally created the 'uclibc' directory
without major.minor numbers. I believe the name should have been
'uclibc-0.9'. I updated our bin/packages README with information that
should avoid this problem in the future. Please let me know if the
README is understanda
On Wed, 2003-02-26 at 00:22, Alex Rhomberg wrote:
> I'm starting to dream of a huge webpage containing information about all the
> packages in the repository; a short description and a status and download
> link for each applicable distribution, e.g.
Alex,
I've been working toward this goal for a
> I apologize for the long delay (8+ months) in completing initial
> population of our packages repository. Project members may commit to the
> following directories:
>
> bin/packages/glibc-2.1
> bin/packages/glibc-2.2
> bin/packages/uclibc
Mike, thanks a lot for your work.
I'm starti
Everyone,
I apologize for the long delay (8+ months) in completing initial
population of our packages repository. Project members may commit to the
following directories:
bin/packages/glibc-2.1
bin/packages/glibc-2.2
bin/packages/uclibc
Commits are acceptable for packages beginning wi
Chad Carr wrote:
Very neat. Very complete. Do you have any test data (other than that
in the comments) to fill this table? Especially GMPackageVariables and
GMPackageVariableValues. This would be very helpful in what I am doing
now to attempt to define a hierarchical config-db for the leaf
On Wednesday 12 February 2003 02:24 am, Greg Morgan wrote:
> I just checked in what I have been working on. Gasp. My first use of
> CVS and I had unintended consequences. The ideas I have been thinking
> of have matured dramatically after putting them to text. I think what I
> did at
> http://c
Greg,
The proper resource to use for auto-building is the SF Compile farm.
CVS -> CF -> shell
CVS -> CF -> FRS
# E3. Guide to the SourceForge.net Compile Farm
https://sourceforge.net/docman/display_doc.php?docid=762&group_id=1
Note: we are currently using 1.1G of SF shell space. We are allocated
On Wed, 2003-02-12 at 00:24, Greg Morgan wrote:
> Lynn Avants wrote:
>
> >
> > I had a similar thought about a year ago and ran into
> > one snag that I never could figure out. We could use to=20
> > some degree the SF SQL server. When an image/package=20
> > is 'selected', how do we generate it
Lynn Avants wrote:
I had a similar thought about a year ago and ran into
one snag that I never could figure out. We could use to=20
some degree the SF SQL server. When an image/package=20
is 'selected', how do we generate it w/o an external server?
I just checked in what I have been working on
On Sun, 09 Feb 2003 11:12:41 -0800
Matt Schalit <[EMAIL PROTECTED]> wrote:
> *Global Package Repository*
I agree with you...
> If a package works on more than 1 LEAF version, please,
> O' Magnificent Ones, let it be stored in a single global
> package repository.
>
> Somebody is really going to
I had a similar thought about a year ago and ran into
one snag that I never could figure out. We could use to
some degree the SF SQL server. When an image/package
is 'selected', how do we generate it w/o an external server?
Say it generates a text 'config' file, unless it specifically matches
wh
On Mon, 2003-02-10 at 00:00, Greg Morgan wrote:
> I started to layout tables in my head while walking to lunch "...oh yeah
> and Greg you got to get back to Mike Noyes about help on php web
> site...". Then it hit me, SF provides the project with a mysqldatabase.
> If I add a few more attribu
Matt Schalit wrote:
> Charles Steinkuehler wrote:
>
> > Also, I see room for multiple versions of similar packages, and even
> > different versions of the same package.
>
>
> Hi, I split this off into a new thread just to quickly talk
> about something that's been on my mind for a bit.
>
> *Globa
On Sun, 2003-02-09 at 11:59, Lynn Avants wrote:
> In any respect, a link to the package-list/links on the php menu would
> prove most useful for many people. I often have a hard time finding the
> location of the list myself.
Lynn,
Added to my to-do list. I thought I already placed a link to it o
On Sunday 09 February 2003 01:29 pm, Mike Noyes wrote:
> Matt,
> This is being worked on. I need to finish my initial import of the
> glibc-2.0 tree. I can then add the package tree export to our daily.sh
> cron. Indexing will be part of this script.
In any respect, a link to the package-list/lin
On Sun, 2003-02-09 at 11:12, Matt Schalit wrote:
> Charles Steinkuehler wrote:
>
> > Also, I see room for multiple versions of similar packages, and even
> > different versions of the same package.
>
>
> Hi, I split this off into a new thread just to quickly talk
> about something that's been
Charles Steinkuehler wrote:
> Also, I see room for multiple versions of similar packages, and even
> different versions of the same package.
Hi, I split this off into a new thread just to quickly talk
about something that's been on my mind for a bit.
*Global Package Repository*
I'll be reall
On Thu, 2002-06-13 at 09:00, Charles Steinkuehler wrote:
> > I reviewed the previous thread about packages that aren't dependent on a
> > specific glibc. It looks like most people would like us to use "nolibc"
> > for the tree name. Is this the consensus?
>
> Works for me.
Anyone with a dissenti
> I reviewed the previous thread about packages that aren't dependent on a
> specific glibc. It looks like most people would like us to use "nolibc"
> for the tree name. Is this the consensus?
Works for me.
Welcome back. I hope the new monitors work out well (and wish I had a
couple myself :)
Everyone,
I ran into a couple of problems recently. I should start work on our
packages repository again tomorrow. I apologize for the delay.
I reviewed the previous thread about packages that aren't dependent on a
specific glibc. It looks like most people would like us to use "nolibc"
for the tr
On Wed, 2002-04-17 at 22:55, David Douthitt wrote:
> On 4/17/02 at 2:10 PM, Mike Noyes <[EMAIL PROTECTED]>
> wrote:
>
> > The following packages were not added to our cvs repository.
>
> Most of those appear to be mine. apkg.lrp needs to be updated, and
> brick.lrp probably should be anywhere b
On 4/17/02 at 2:10 PM, Mike Noyes <[EMAIL PROTECTED]>
wrote:
> The following packages were not added to our cvs repository.
Most of those appear to be mine. apkg.lrp needs to be updated, and
brick.lrp probably should be anywhere but "development". I stopped
working on brick pretty much.
--
Dav
Everyone,
I've completed adding all of a-b. It looks like this task will take
approximately one week to complete (I'm averaging a letter every two
hours.).
I thank Kim Oppalfens for generating descriptions and URLs for all of
our packages through m.
Current glibc-2.0 tree:
http://cvs.sourceforge
33 matches
Mail list logo
