On Oct 26, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> Maybe hurd and m68k porters can maintain a glibc package using an old
> version (2.3.6 ??) together? Well that's for after Etch.
What for? Modern threaded software will require TLS more and more.
--
ciao,
Marco
signature.asc
Description: D
Thomas Schwinge a écrit :
> Hello!
>
> On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
>> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
>>> For m68k and hurd, I have sent a mail to the porters a few months ago, I
>>> haven't received any answer.
>
> That is untrue
- Original Message -
From: "Michael Banck" <[EMAIL PROTECTED]>
To:
Cc:
Sent: Thursday, October 26, 2006 11:45 AM
Subject: Re: libc6 2.5 and Etch
On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
We plan to upload [glibc-2.5] right after the releas
Hello!
On Thu, Oct 26, 2006 at 05:45:24PM +0200, Michael Banck wrote:
> On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> > For m68k and hurd, I have sent a mail to the porters a few months ago, I
> > haven't received any answer.
That is untrue. I replied for the Hurd people.
>
On Wed, Oct 25, 2006 at 01:27:07PM +0200, Aurelien Jarno wrote:
> We plan to upload [glibc-2.5] right after the release of etch.
>
> This version works on all architectures, but m68k, hurd and hppa which
> don't have TLS support.
>
> For hppa the work is almost done, I am currently building the p
TED]> -
X-Envelope-Sender: [EMAIL PROTECTED]
To: debian-powerpc@lists.debian.org
Cc: debian-devel@lists.debian.org
Subject: what is libc6 2.2.4-6.0.1 in ppc?
From: Atsuhito Kohda <[EMAIL PROTECTED]>
X-Dispatcher: imput version 991025(IM133)
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-
Hi,
I put dummy packages on alpha.gnu.org:
libc6-dev 9:999
sysvinit 9:999
the ridiculous high version number should make sure dpkg and friends are
happy. libc6-dev depends on libc0.2-dev to make sure it is installed.
If there are more useful dummy packages you know of, let me know and I will
Marcus Brinkmann wrote:
> The broader problem is that dpkg doesn't cope with versioned dependencies on
> provided packages.
Indeed.
In this particular case, however, I wonder what is the point of making
libstdc++2.10-dev to depend on a specific version of libc6-dev at all,
since
On Mon, Feb 19, 2001 at 09:35:30PM +0100, Santiago Vila wrote:
> In GNU/Hurd the names are "libc0.2" and "libc0.2-dev". Therefore
> libstdc++2.10-dev should be modified so that its hurd-i386 version
> depends on "libc0.2-dev", not libc6-dev.
Well, it coul
Vadim Chekan wrote:
> I can't install g++ on my Hurd based on D1 dist.
> apt-get install g++
> g++: depends: libstdc++2.10-dev (>=1:2.95.2-10) but it not going to be
> installed
>
> apt-get install libstdc++2.10-dev
> libstdc++2.10-dev : Depends: libc6-dev (>=2
Hello all!
I can't install g++ on my Hurd based on D1 dist.
apt-get install g++
g++: depends: libstdc++2.10-dev (>=1:2.95.2-10) but it not going to be
installed
apt-get install libstdc++2.10-dev
libstdc++2.10-dev : Depends: libc6-dev (>=2.1.95)
apt-get install libc6-dev
Note
On Sat, Jun 05, 1999 at 02:45:30PM +0300, Kalle Olavi Niemitalo wrote:
> Most *-dev packages depend on libc6-dev, which libc0.2-dev
> provides. Is it supposed to be like this, or should each package
> be changed to depend on libc-dev instead?
>
> In the case of aalib1-dev, th
Most *-dev packages depend on libc6-dev, which libc0.2-dev
provides. Is it supposed to be like this, or should each package
be changed to depend on libc-dev instead?
In the case of aalib1-dev, the dependency is explicitly in
debian/control.
> Okay, understood. At a later step, we may want to add code for all
> suboptimal programs. For now, let me ask a further question: What about
> MAXHOSTNAMELEN? If there is no fixed value for this, how can I determine the
> value at run time?
This (PATH_MAX) is a case where there is no generic run
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Okay, understood. At a later step, we may want to add code for all
> suboptimal programs. For now, let me ask a further question: What about
> MAXHOSTNAMELEN? If there is no fixed value for this, how can I determine the
> value at run time?
You don't
On Sun, Dec 27, 1998 at 04:22:05PM -0500, Roland McGrath wrote:
>
> > Notice that neither PATH_MAX nor OPEN_MAX are defined in Hurd, too.
> >
> > Why?
>
> Because there are no limits. Aside from runtime memory availability, there
> is no limit whatsoever on the length of a file name imposed by
> > No program that uses them unconditionally complies to 1003.1-1996.
>
> Granted (i don't have the standard here, but I believe you).
>
> The question is, what to do with those programs? Is there a standard way to
> rewrite the parts that are "broken"?
Yes, there is. In some cases it simply m
On Sun, Dec 27, 1998 at 04:22:05PM -0500, Roland McGrath wrote:
>
> The current hurd does define NBBY, NGROUPS, MAXSYMLINKS,
> CANBSIZ, and NCARGS. The NCARGS and NGROUPS definitions are fictitious,
> since there are no actual limits on those things.
Silly me, I quoted to much. Sorry.
> > Esp
>
> Hi,
>
> I stumbled across the following definitions in , which are
> defined in Linux, but not in Hurd:
>
> /* BSD names for some values. */
>
> #define NBBYCHAR_BIT
> #ifndef NGROUPS
> #define NGROUPS NGROUPS_MAX
> #endif
> #define MAXSYMLINKS 5
> #define CANBSIZ
Hi,
I stumbled across the following definitions in , which are
defined in Linux, but not in Hurd:
/* BSD names for some values. */
#define NBBYCHAR_BIT
#ifndef NGROUPS
#define NGROUPS NGROUPS_MAX
#endif
#define MAXSYMLINKS 5
#define CANBSIZ MAX_CANON
#define NC
20 matches
Mail list logo
