er for any single
subarchitecture -- 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
"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]
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]
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.
>
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 the
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 "u
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 UNSUBS
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 a
-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 qu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
GOTO Masanori wrote:
| At Tue, 30 Mar 2004 10:46:25 +0200,
| Martin Schulze wrote:
|
|>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. We'
Allowing 'long long' in asm/types.h even with __STRICT_ANSI__ may
not be ideal, but it would work.
I ask because this is the last RC bug against l-k-h.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
>
> T
>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.
Mathieu Roy wrote:
>>> > 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 package.
>
> The false sentence quoted above should be removed from stdlib.h.
Actually, in the context of the mess with initscripts, it would probably be
better if the documented behavior was implemented. In the meantime, stdlib.h
should say:
TO DO: Allow the last file name component to not exist, o
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
is helps explain 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 P
Kernel 2.4.24 is *not* present in woody.
It is in woody-proposed-updates.
Please, someone, remember to convince Martin Schulze to accept it. :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-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 constru
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 upg
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 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 ab
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 ;-)
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 UNSU
ld/buildd/linux-kernel-headers-2.5.999-test7-bk/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&#x
ld/buildd/linux-kernel-headers-2.5.999-test7-bk/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&#x
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
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 sto
appears to have broken the 'dmapi' build too.
appears to have broken the 'dmapi' build too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
This is breaking the kdebase build as well, in essentially the same way.
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
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
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
http://home.twcny.rr.com/nerode/neroden/fdl.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
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.
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]
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 incl
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 incl
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/ hea
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/ he
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]
So, in the new glibc in 'experimental', there's a separate glibc (non-stock)
kernel-headers package. Has this bug been fixed in that version of glibc?
Could someone please test, as this is important to kde?
Thanks.
--Nathanael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
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
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?
R
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.
--Nath
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.
--Nat
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 t
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 t
>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]
they're preexisting, they probably shouldn't block new 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.
l remain 100% free software", under which Debian can contain an
arbitrary amount of non-free non-software.) But to err on the side of
caution, I'm not even including them in the majorities I mentioned
above. If I did, it would be 'near unanimity' of opinion.
You don&#
er as well, though. :-P
No reason for Debian to claim to support a version of POSIX which
removes standard usages, 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
http://home.twcny.rr.com/nerode
they're preexisting, they probably shouldn't block new 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
http://home.twcny.rr.com/nerode/neroden/fdl.html
Status report on this bug, perhaps? It's well after March.
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]
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?
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 PROT
61 matches
Mail list logo
