-- and that's not nearly as bad as holding up
every package on every single arch.
Is there a problem which is not listed in the RC bugs?
--
Nathanael Nerode [EMAIL PROTECTED]
[Insert famous quote here]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
It doesn't seem to serve a useful purpose to leave it hanging around.
Unless it's reproducible in which case it should lose the tag.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PPC libc6 should be built with TLS and NPTL
We have new enough GCC now, and new glibc. Is this fixed in the current
glibc version in unstable?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ian Wienand wrote:
On Wed, Aug 03, 2005 at 09:58:32PM -0400, Nathanael Nerode wrote:
If glibc in unstable doesn't require significant fixes to build with gcc-4.0,
it really would be a good idea to backport the fix for this bug and the
rpc/xdr.h one.
I started to try this but gave up quite
FYI, this bug breaks the apt build. It is going to stall at least
77 packages.
--
A thousand reasons. http://www.thousandreasons.org/
Lies, theft, war, kidnapping, torture, rape, murder...
Get me out of this fascist nightmare!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
So, 496 more packages in the C++ transition waiting on glibc.
If glibc in unstable doesn't require significant fixes to build with gcc-4.0,
it really would be a good idea to backport the fix for this bug and the
rpc/xdr.h one.
If it does require significant fixes, perhaps you could suggest to
IIRC, the C3 v1 is the infamous 686 without CMOV (reporting as a 686 from
the dynamic detection code, but not supporting most 686 libraries). Is it
possible that this has anything to do with the problem, considering that
things appear to work everywhere else?... Just a guess.
--
To
GOTO Masanori wrote:
At Mon, 29 Mar 2004 04:23:37 -0500,
Nathanael Nerode wrote:
as a German native speaker with some interest on typography but
virtually no knowledge on UTF-8 some comments:
The common quotes in German today are
double open quotes (low position) U201E
together
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
GOTO Masanori wrote:
| At Mon, 29 Mar 2004 04:23:37 -0500,
| Nathanael Nerode wrote:
|
|as a German native speaker with some interest on typography but
|virtually no knowledge on UTF-8 some comments:
|
|The common quotes in German today are
| double
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
GOTO Masanori wrote:
| At Tue, 30 Mar 2004 10:46:25 +0200,
| Martin Schulze wrote:
|
snip
|I have another solution to propose: Provide an upgrade-for-real-i386
|directory, including a README and kernel packages to install before
|upgrading to sarge.
Adrian Bunk wrote:
Hi,
as a German native speaker with some interest on typography but
virtually no knowledge on UTF-8 some comments:
The common quotes in German today are
double open quotes (low position) U201E
together with
double closed quote (high position) U201C
The current
Nathanael Nerode, you wrote How about the change I suggest
above?. I'm afraid but I missed it, and I am unable to find a
previous post from you at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239555 (Am I
getting blind?).
No previous post. It was above in the same post, and looking at it I
posted mailed
Mathieu Roy wrote:
snip
WARNING: Some commercial programs may not work well with these
s/commercial programs/third-party binaries/
libraries. Most notably, IBM's JDK. If you experience problems
with such applications, you will need to remove this
Jeff Bailey wrote:
I'd like to put forward the idea of moving the repo to svn (and
svn.debian.org). Talking with pere online, he wants to clean up the
locales mess in our patches directory, some of which involves renames.
renames have bitten us a few times, and it would be nice to Stop The
the problem, why it's 'critical', and why it has
something to do with woody.
- --Nathanael Nerode
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAXfZ/RGZ0aC4lkIIRAqKDAJ4oCi5OgYuCMBec6EzEEFG9HT0IlQCfZ9dN
djzO04onZMcHY9PcxSClXn4=
=FXPU
-END PGP SIGNATURE-
--
To UNSUBSCRIBE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hood wrote:
| Your patch shows the trouble you have to go to if you choose not
| to Depend on the new initscripts. Is there some reason why the
| new libc6 should _not_ Depend on the new initscripts?
Indeed, after going to the trouble of
This means that the plan to deal with the old devpts.sh
should be modified to take this into account. I suggest:
* Depends: sysvinit (= 2.85-10)
* No longer ship either devpts.sh or mountkernfs.
That means that both of these conffiles are abandoned.
Because dpkg does not dispose of abandoned
The correct line is
Depends: initscripts (= 2.85.10)
since that's the binary package which supplies /etc/initd/mountvirtfs
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This is an experimental patch (against CVS) which attempts to handle
upgrading from any libc version whether or not initscripts has been updated.
It's a little hackish, and it's probably not quite the right thing,
and I'm not really up to testing it, but I hope it helps. :-) It does
depend on
GOTO Masanori wrote:
At Tue, 9 Mar 2004 05:30:34 -0500,
Nathanael Nerode wrote:
What progress has been made and what still needs to be done?
Apparently current glibc now has the checking code in glibc to prevent it from
being upgraded until *after* the kernel is upgraded (to 2.4.24 or 2.6.0
What progress has been made and what still needs to be done?
Apparently current glibc now has the checking code in glibc to prevent it from
being upgraded until *after* the kernel is upgraded (to 2.4.24 or 2.6.0).
However, as Karolina Lindqvist wrote:
You can't install 2.4.24 on a i386 system,
Before assigning this to l-k-h, you probably should have tried my suggestion
of switching to the userland header in e2fslibs-dev, and if it failed,
documented that. The l-k-h people are most likely going to bite your head
off for using a linux/ header directly in userspace ;-)
--
To
Before assigning this to l-k-h, you probably should have tried my suggestion
of switching to the userland header in e2fslibs-dev, and if it failed,
documented that. The l-k-h people are most likely going to bite your head
off for using a linux/ header directly in userspace ;-)
/debian/linux-kernel-headers/usr/include/asm/atomic.h:144:
warning: implicit declaration of function `local_irq_restore'
make[1]: *** [fs.o] Error 1
make[1]: Leaving directory
`/build/buildd/linux-kernel-headers-2.5.999-test7-bk/testsuite'
make: *** [lkh-test] Error 2
--
Nathanael Nerode neroden
/debian/linux-kernel-headers/usr/include/asm/atomic.h:144:
warning: implicit declaration of function `local_irq_restore'
make[1]: *** [fs.o] Error 1
make[1]: Leaving directory
`/build/buildd/linux-kernel-headers-2.5.999-test7-bk/testsuite'
make: *** [lkh-test] Error 2
--
Nathanael Nerode neroden
appears to have broken the 'dmapi' build too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Apparently a
/etc/hosts.equiv containing the single line
[EMAIL PROTECTED]
used to work fine and is now completely ignored.
According to some old SunOS man pages ;-), this is supposed to allow
rlogin/rsh/rcp/rcmd password-free access for all users from any hosts in
the 'netgroup' list stored
appears to have broken the 'dmapi' build too.
Apparently a
/etc/hosts.equiv containing the single line
[EMAIL PROTECTED]
used to work fine and is now completely ignored.
According to some old SunOS man pages ;-), this is supposed to allow
rlogin/rsh/rcp/rcmd password-free access for all users from any hosts in
the 'netgroup' list stored in
If it's setting the stack *limit* and glibc is complaining because the
stack *size* isn't a multiple of the page size...
Why doesn't glibc round all stack limit settings to the next lower
multiple of the page size? Sounds straightforward and safe enough to
me. Sort of kludgy, in some ways, I
This is breaking the kdebase build as well, in essentially the same way.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
If it's setting the stack *limit* and glibc is complaining because the
stack *size* isn't a multiple of the page size...
Why doesn't glibc round all stack limit settings to the next lower
multiple of the page size? Sounds straightforward and safe enough to
me. Sort of kludgy, in some ways, I
Looks to me like the buildds are back, so that excuse is gone. Can we
expect a new linux-kernel-headers tomorrow, and if not, why not?
--
Nathanael Nerode neroden at gcc.gnu.org
http://home.twcny.rr.com/nerode/neroden/fdl.html
Looks to me like the buildds are back, so that excuse is gone. Can we
expect a new linux-kernel-headers tomorrow, and if not, why not?
--
Nathanael Nerode neroden at gcc.gnu.org
http://home.twcny.rr.com/nerode/neroden/fdl.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Proposed patch for this issue, to go into debian/patches.
Simpler approach than Goswin's: in all known cases, videodev2.h has been the
problem. It appears to only need 'struct timeval'. 'struct timeval' is the
same size and shape in linux/time.h and in time.h. So I just made
videodev2.h
Don't ask me how that spurious 'f' got into the copy of my patch which I sent.
It should be #else, not #elsef, of course.
Proposed patch for this issue, to go into debian/patches.
Simpler approach than Goswin's: in all known cases, videodev2.h has been the
problem. It appears to only need 'struct timeval'. 'struct timeval' is the
same size and shape in linux/time.h and in time.h. So I just made
videodev2.h
Don't ask me how that spurious 'f' got into the copy of my patch which I sent.
It should be #else, not #elsef, of course.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
guenter geiger wrote:
(I wrote:)
Hmm. OK, this is the way it is.
Linux kernel developers don't like most linux headers to be included
directly from userspace. They want them to be sanitized first if used
at all; the glibc sys/ headers often include carefully sanitized
versions of the linux/
guenter geiger wrote:
(I wrote:)
Hmm. OK, this is the way it is.
Linux kernel developers don't like most linux headers to be included
directly from userspace. They want them to be sanitized first if used
at all; the glibc sys/ headers often include carefully sanitized
versions of the linux/
No, the dependency is correct, and is in fact the vehicle to fix a lot
of long-standing bugs.
Don't include kernel headers from userspace. Also, read the FAQ.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Andreas Barth wrote:
I do make this destinction. But the discussed question is not: Are we
going to release sarge now, but without Sun RPC?
And precisely why isn't that the discussed question?
RPC is an old, tired protocol which should not generally be used. So
release without it already.
Francesco P. Lovergine wrote:
On Wed, Oct 22, 2003 at 02:10:01AM -0400, Nathanael Nerode wrote:
Andreas Barth wrote:
I do make this destinction. But the discussed question is not: Are we
going to release sarge now, but without Sun RPC?
And precisely why isn't that the discussed question?
RPC
Andreas Barth wrote:
I do make this destinction. But the discussed question is not: Are we
going to release sarge now, but without Sun RPC?
And precisely why isn't that the discussed question?
RPC is an old, tired protocol which should not generally be used. So
release without it already.
Francesco P. Lovergine wrote:
On Wed, Oct 22, 2003 at 02:10:01AM -0400, Nathanael Nerode wrote:
Andreas Barth wrote:
I do make this destinction. But the discussed question is not: Are we
going to release sarge now, but without Sun RPC?
And precisely why isn't that the discussed question?
RPC
Martin-Eric Racine wrote:
I still think that skiping a supported architecture, as well as the
ground rule
about syncing everything before allowing a package to slide down to
testing, is
a REALLY bad idea, especialy for something so fundamental as glibc.
I don't think so. However, I think that
Martin-Eric Racine wrote:
I still think that skiping a supported architecture, as well as the
ground rule
about syncing everything before allowing a package to slide down to
testing, is
a REALLY bad idea, especialy for something so fundamental as glibc.
I don't think so. However, I think that
From the discussion, it sounds like the release-critical aspects of this bug
are fixed, and the remaining aspects of the bug are not release-critical.
Downgrade anyone? :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
, and I suppose it's more honest to not claim to
be compliant when you not only aren't, but don't want to be. :-P
--
Nathanael Nerode neroden at gcc.gnu.org
http://home.twcny.rr.com/nerode/neroden/fdl.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble
versions
of glibc from going into testing, however. If you can convince the
release manager to mark them 'sarge-ignore', that's probably the best
thing to do. (That's what he did with the GFDL bugs against GCC.)
--
Nathanael Nerode neroden at gcc.gnu.org
http://home.twcny.rr.com/nerode
Status report on this bug, perhaps? It's well after March.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status report on this bug, perhaps? It's well after March.
I'm a little confused.
packages.qa.debian.org claims that 2.3.2-1 was accepted on 2003-07-18.
And that it's out of date on sparc because it needs to be version
2.3.1-17. (?!)
What's the status of glibc and what's the expected status in the near
future?
--
To UNSUBSCRIBE, email to [EMAIL
53 matches
Mail list logo
