On Fri, 2002-04-19 at 06:53, Mike Noyes wrote:
> David,
> I hate to be blunt, but the discussion below is pointless. We need to
> move our files to cvs. This is not an option. OK.
>
> ** SourceForge doesn't provide FTP service for hosted projects. **
David,
I apologize for the text above. I was
David,
I hate to be blunt, but the discussion below is pointless. We need to
move our files to cvs. This is not an option. OK.
** SourceForge doesn't provide FTP service for hosted projects. **
On Fri, 2002-04-19 at 00:15, David Douthitt wrote:
> On 4/18/02 at 7:35 AM, Mike Noyes <[EMAIL PROTEC
On 4/18/02 at 7:35 AM, Mike Noyes <[EMAIL PROTECTED]>
wrote:
> The bin/ tree in cvs serves the following purposes:
>
> * Tracking of updates (change-log, notes, notification of new
> files, etc.) (Note: a ftp repository wont give us any of this.)
It can. See ftp.kernel.org
> * Fac
On Wed, 2002-04-17 at 22:45, David Douthitt wrote:
> On 4/17/02 at 8:08 AM, Charles Steinkuehler <[EMAIL PROTECTED]>
> wrote:
> > That doesn't change the fact, however, that I think Mike's
> > trying to migrate binary LRP files into CVS to cut space
> > requirements on the SF site. I think the di
On 4/17/02 at 8:08 AM, Charles Steinkuehler <[EMAIL PROTECTED]>
wrote:
> I agree whole-heartedly that a bsd /usr/ports (or gentoo
> ebuild) type source tree is most appropriate. I don't
> think source should go into any of the CVS directories
> mentioned to date.
>
> That doesn't change the fac
On 4/16/02 at 3:46 PM, Charles Steinkuehler <[EMAIL PROTECTED]>
wrote:
> I guess so, but I sort of got the idea (perhaps incorrect)
> that there were packages that *did not* require a C
> library.
I'm sure there are...
> If that's the case, the above is misleading (to
> me it implies the packag
> > Charles,
> > Would this be acceptable?
> >
> > bin/packages + /glibc-2.0
> > |
> > + /glibc-2.1
> > |
> > + /glibc-any
>
> I guess so, but I sort of got the idea (perhaps incorrect)
> that there were
> packages that *did not* require a C li
> Charles,
> Would this be acceptable?
>
> bin/packages + /glibc-2.0
> |
> + /glibc-2.1
> |
> + /glibc-any
I guess so, but I sort of got the idea (perhaps incorrect) that there were
packages that *did not* require a C library. If that's the cas
On 16 Apr 2002, Mike Noyes wrote:
[...]
> Everyone,
> Apparently it's a non-trivial task to determine the minor version of
> libc used for package creation. Tomorrow I'm going to start committing
> our packages to cvs with the following tree structure:
>
> bin/packages + /glibc2.0
>
On Tue, 2002-04-16 at 08:37, Charles Steinkuehler wrote:
> > I'll place all of the packages that require libc.so.6 in the glibc2.0
> > directory. The few packages that don't depend on any libc will be placed
> > in the bin/packages directory.
>
> How about using bin/packages/nolibc (or similar) i
> Everyone,
> Apparently it's a non-trivial task to determine the minor version of
> libc used for package creation. Tomorrow I'm going to start committing
> our packages to cvs with the following tree structure:
>
> bin/packages + /glibc2.0
> |
> + /glibc2.1
>
> Shoul
On Mon, 2002-04-15 at 22:52, Jeff Newmiller wrote:
> On 15 Apr 2002, Mike Noyes wrote:
>
> > Everyone,
> > I'm still unable to decipher the libc minor version from output
> > generated by ldd. All of our packages that I have looked at so far use
> > libc major version 6. The output below is from
On 15 Apr 2002, Mike Noyes wrote:
> Everyone,
> I'm still unable to decipher the libc minor version from output
> generated by ldd. All of our packages that I have looked at so far use
> libc major version 6. The output below is from KP's squid-2 package. He
> states that it was compiled with gli
Everyone,
I'm still unable to decipher the libc minor version from output
generated by ldd. All of our packages that I have looked at so far use
libc major version 6. The output below is from KP's squid-2 package. He
states that it was compiled with glibc 2.1.3. How can I verify this from
the outp
14 matches
Mail list logo
