First of all, apologies for posting here. Use of BTS would lead to
too many bug reassignments in that case ;-/
Summary: there is a bug in 2.2 kernels that leads to breakage of
glibc 2.3.2 on 2.2 boxen, to breakage of coreutils and to FTBFS of m4 on
alpha. Additionally, there's a
On Sun, Sep 28, 2003 at 01:10:27PM +1000, Herbert Xu wrote:
> I do not believe that this patch has caused excessive grief for the
> benefits that it brings. In fact, conflicts between the Debian kernel
> source and random kernel patches floating around are a fact of life.
>
> For example, the grs
On Mon, Nov 03, 2003 at 02:22:00PM -0800, Erik Steffl wrote:
> Oh, not this crap again. Or perhaps you're contending that what is
> usefull for you is usefull for everybody.
>
> Hint: there's more to "useful" than old version of software in early
> stages of development. Lot of desktop orien
On Tue, Nov 04, 2003 at 01:48:25PM +1100, Martin Michlmayr wrote:
> * [EMAIL PROTECTED] [2003-11-03 22:52]:
> > but I wouldn't touch Herbert's kernels with a ten-feet pole.
>
> Can you elaborate why?
a) I can do better
b) I don't do huge monolitic patches
c) I don't like
On Tue, Nov 04, 2003 at 07:51:52PM +0100, Josselin Mouette wrote:
> Le mar 04/11/2003 à 16:56, [EMAIL PROTECTED] a écrit :
> > Also, I think both you and Ingo will be interested to see the results of
> > a bugfixed version of paxtest. Are you so certain that Exec-shield
> > stops execution in sh
On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
> Then how do you suggest maintaining a kernel 2.4.20 for one
> architecture and a 2.4.22 for another architecture, when you can't even
> test on either of them? And how do you expect to ever upgrade the
> result without duplicat
On Fri, Nov 07, 2003 at 10:59:51PM +0100, Frank Gevaerts wrote:
> On Fri, Nov 07, 2003 at 10:48:06PM +0100, Robert Millan wrote:
> > > Then how do you suggest maintaining a kernel 2.4.20 for one
> > > architecture and a 2.4.22 for another architecture, when you can't even
> > > test on either of th
On Mon, Nov 10, 2003 at 05:11:45PM +0100, Eduard Bloch wrote:
> initrd-on-cramfs fix ,
You mean the kludge that craps in fs/block_dev.c? If so, feel free to
can it - the proper fix is to switch cramfs_read() to use of pagecache
and it's going upstream.
> /* map the file and load an extra page in case the new line expands the
> file across the page boundary; adding 2 allows for the truncating
> effect of integer division. Forcing an extra page ensures
> that we can identify the end of the buffer by finding a NUL */
No, it does n
On Thu, Dec 18, 2003 at 05:03:55AM +, Henning Makholm wrote:
> Scripsit Kevin Kreamer <[EMAIL PROTECTED]>
>
> > In the case of a NetBSD libc, you could use
>
> > Debian NBSD/NBSD
>
> > basically having the first half signify which libc is used.
>
> Wouldn't that be a major retcon? AFAIU the
On Thu, Dec 18, 2003 at 10:41:46AM +0100, Mathieu Roy wrote:
> You are currently saying that the GNU in GNU/Linux is justified by the
> glibc and not by any other GNU software, because these GNU software
> are common on other unixes.
>
> Why? If you are right that others unixes uses widely GNU sof
On Thu, Dec 18, 2003 at 12:15:37PM +0100, Mathieu Roy wrote:
> > Why not?
>
> You said what I expected from you: you revealed that you disbelieve
> that the system should be called GNU/Linux. Good to know in this kind
> of discussion.
I'm not a True Believer, if that's what you mean.
> Why not
On Thu, Dec 18, 2003 at 12:56:15PM +0100, Julian Mehnle wrote:
> [EMAIL PROTECTED] wrote:
> > If we ever get a replacement libc that would really work as
> > replacement... on such system GNU claims would become much weaker. Not
> > that there was a serious chance of that happening - drop-in repla
On Thu, Dec 18, 2003 at 02:26:27PM +0200, Momchil Velikov wrote:
> > "Mathieu" == Mathieu Roy <[EMAIL PROTECTED]> writes:
>
> Mathieu> If we follow your theory, it means that if someday another
> Mathieu> system use the glibc, we should remove the GNU from the
> Mathieu> GNU/Linux name.
Arr
On Thu, Aug 25, 2005 at 01:09:14AM +0200, Marco d'Itri wrote:
> When I asked the udev maintainer about this, he replied that he does not
> believe that it will be an issue in the future.
> We are not even at the step of requiring udev for everything, only for
> less than ten packages which require
15 matches
Mail list logo
