> > gcc -D__KERNEL__ -I/src/linux-2.1.108/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -pipe  -march=pentium -DCPU=586   -DEXPORT_SYMTAB -c fbcon.c
> > fbcon.c: In function `fbcon_setup':
> > fbcon.c:505: too few arguments to function `set_palette'
> > fbcon.c: In function `fbcon_scroll':
> > fbcon.c:1016: `SM_LEFT' undeclared (first use in this function)
> > fbcon.c:1016: (Each undeclared identifier is reported only once
> > fbcon.c:1016: for each function it appears in.)
> > fbcon.c:1021: `SM_RIGHT' undeclared (first use in this function)
> > make[3]: *** [fbcon.o] Error 1

> This is broken since 2.1.122 through 123pre1-3 and ac2. But this is not the
> end of the whole story, when you're through this, the kernel won't link
> because of missing external variable initmem_freed ... A patch
> (initmem_freed stuff is done for i386 only) follows...

>Please don't waste your time on creating these patches. These things are
>functional in the vger tree (ftp://vger.rutgers.edu/pub/linux/README.CVS).

> gcc -D__KERNEL__ -I/src/linux-2.1.108/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -pipe  -march=pentium -DCPU=586   -DEXPORT_SYMTAB -c fbcon.c
> fbcon.c: In function `fbcon_setup':
> fbcon.c:505: too few arguments to function `set_palette'
> fbcon.c: In function `fbcon_scroll':
> fbcon.c:1016: `SM_LEFT' undeclared (first use in this function)
> fbcon.c:1016: (Each undeclared identifier is reported only once
> fbcon.c:1016: for each function it appears in.)
> fbcon.c:1021: `SM_RIGHT' undeclared (first use in this function)
> make[3]: *** [fbcon.o] Error 1

> > > gcc -D__KERNEL__ -I/src/linux-2.1.108/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -pipe  -march=pentium -DCPU=586   -DEXPORT_SYMTAB -c fbcon.c
> > > fbcon.c: In function `fbcon_setup':
> > > fbcon.c:505: too few arguments to function `set_palette'
> > > fbcon.c: In function `fbcon_scroll':
> > > fbcon.c:1016: `SM_LEFT' undeclared (first use in this function)
> > > fbcon.c:1016: (Each undeclared identifier is reported only once
> > > fbcon.c:1016: for each function it appears in.)
> > > fbcon.c:1021: `SM_RIGHT' undeclared (first use in this function)
> > > make[3]: *** [fbcon.o] Error 1

> > This is broken since 2.1.122 through 123pre1-3 and ac2. But this is not the
> > end of the whole story, when you're through this, the kernel won't link
> > because of missing external variable initmem_freed ... A patch
> > (initmem_freed stuff is done for i386 only) follows...

> Please don't waste your time on creating these patches. These things are
> functional in the vger tree (ftp://vger.rutgers.edu/pub/linux/README.CVS).

> >Please don't waste your time on creating these patches. These things are
> >functional in the vger tree (ftp://vger.rutgers.edu/pub/linux/README.CVS).

> He's not wasting time.

> I have stopped synching up to vger a _long_ time ago.  Anybody who still
> thinks vger has _any_ relevance to the standard kernel is very much
> misguided.

>            Linus

>gcc -D__KERNEL__ -I/src/linux-2.1.108/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -pipe  -march=pentium -DCPU=586   -DEXPORT_SYMTAB -c fbcon.c
>fbcon.c: In function `fbcon_setup':
>fbcon.c:505: too few arguments to function `set_palette'
>fbcon.c: In function `fbcon_scroll':
>fbcon.c:1016: `SM_LEFT' undeclared (first use in this function)
>fbcon.c:1016: (Each undeclared identifier is reported only once
>fbcon.c:1016: for each function it appears in.)
>fbcon.c:1021: `SM_RIGHT' undeclared (first use in this function)
>make[3]: *** [fbcon.o] Error 1

>--

> We're painfully aware of this.  We do sync up with you though, so the vger
> tree does have what he needs along with your changes.

> }I have stopped synching up to vger a _long_ time ago.  Anybody who still
> }thinks vger has _any_ relevance to the standard kernel is very much
> }misguided.

> >Please don't waste your time on creating these patches. These things are
> >functional in the vger tree (ftp://vger.rutgers.edu/pub/linux/README.CVS).

> He's not wasting time.

> > We're painfully aware of this.  We do sync up with you though, so the vger
> > tree does have what he needs along with your changes.

> > }I have stopped synching up to vger a _long_ time ago.  Anybody who still
> > }thinks vger has _any_ relevance to the standard kernel is very much
> > }misguided.

> Note that saying "it's in vger, so you're wasting your time" is still
> completely and utterly stupid. The fact that it is in vger has absolutely
> no bearing, especially as there's a _lot_ of stuff in vger that will
> probably never make it into 2.2.

>            Linus

> On 28 Sep 1998 09:41:38 -500   Michael Harnois wrote:
> >Am I the only one for whom 2.1.123 fbcon.c doesn't compile?

> Same problem here with 123
> Len

> >gcc -D__KERNEL__ -I/src/linux-2.1.108/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -pipe  -march=pentium -DCPU=586   -DEXPORT_SYMTAB -c fbcon.c
> >fbcon.c: In function `fbcon_setup':
> >fbcon.c:505: too few arguments to function `set_palette'
> >fbcon.c: In function `fbcon_scroll':
> >fbcon.c:1016: `SM_LEFT' undeclared (first use in this function)
> >fbcon.c:1016: (Each undeclared identifier is reported only once
> >fbcon.c:1016: for each function it appears in.)
> >fbcon.c:1021: `SM_RIGHT' undeclared (first use in this function)
> >make[3]: *** [fbcon.o] Error 1

> >--

> -----== Sent via Deja News, The Discussion Network ==-----
> http://www.dejanews.com/  Easy access to 50,000+ discussion forums

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

> > I have stopped synching up to vger a _long_ time ago.  Anybody who still
> > thinks vger has _any_ relevance to the standard kernel is very much
> > misguided.

> In that case, please disable CONFIG_FB completely on the Intel platform, so I
> won't see any complaints about it anymore. And be sure 2.2 will support less
> platforms than 2.0. Other platforms rely on an up-to-date drivers/video.

> Don't take this the wrong way, but can we expect framebuffer support to
> work from now on?

> How about allowing the fixes in?  Broken kernels, or, more
> correctly, kernels with broken console code, suk.

>            Linus

> > How about allowing the fixes in?  Broken kernels, or, more
> > correctly, kernels with broken console code, suk.

> Yes. I applied the small patch already. It may be broken, but at least
> somebody tried to make a minimal patch which was more than other people
> have done so far.

>            Linus

> And you think it's a good idea to have the linux community divide into to
> parts: The Linus party and the VGER party?

> Screw it, maybe I'll just hack a shell acct somewhere and CVS
> from somewhere else.

> -Shawn

> > On Mon, 28 Sep 1998, Cort Dougan wrote:

> > > We're painfully aware of this.  We do sync up with you though, so the vger
> > > tree does have what he needs along with your changes.

> > > }I have stopped synching up to vger a _long_ time ago.  Anybody who still
> > > }thinks vger has _any_ relevance to the standard kernel is very much
> > > }misguided.

> > Note that saying "it's in vger, so you're wasting your time" is still
> > completely and utterly stupid. The fact that it is in vger has absolutely
> > no bearing, especially as there's a _lot_ of stuff in vger that will
> > probably never make it into 2.2.

> >               Linus

> How about allowing the fixes in?  Broken kernels, or, more
> correctly, kernels with broken console code, suk.

> > On Mon, 28 Sep 1998, Linus Torvalds wrote:

> > > On Mon, 28 Sep 1998, Cort Dougan wrote:

> > > > We're painfully aware of this.  We do sync up with you though, so the vger
> > > > tree does have what he needs along with your changes.

> > > > }I have stopped synching up to vger a _long_ time ago.  Anybody who still
> > > > }thinks vger has _any_ relevance to the standard kernel is very much
> > > > }misguided.

> > > Note that saying "it's in vger, so you're wasting your time" is still
> > > completely and utterly stupid. The fact that it is in vger has absolutely
> > > no bearing, especially as there's a _lot_ of stuff in vger that will
> > > probably never make it into 2.2.

> > >          Linus

> > How about allowing the fixes in?  Broken kernels, or, more
> > correctly, kernels with broken console code, suk.

>    If the patch works and is appropriate, who cares if the diff is
> generated from someone's own tree or from "cvs diff" on the vger tree??

> Jon

> ---
> 'Cloning and the reprogramming of DNA is the first serious step in
> becoming one with God.'
>    - Scientist G. Richard Seed

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

> Wow!  How does one manage to generate a hundred megabyte patch?  I don't have
> the latest kernels, but "find . -type f | xargs cat | wc" tells me I've only
> only got 40 megabytes of kernel source, so even if they completely rewrote
> every file, they should only be sending you 80 megabytes or so! :-)  What
> in heavens name are they doing?

> The problem is that there's a ton of patches on vger, and some people do
> not understand the issue of "Code Freeze". They think that just because
> they had access to the CVS tree, they got under the code freeze somehow. I
> won't bother educating them any more.