lkml.org 
[lkml]   [2005]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tvtime audio vs pcHDTV-3000 card and pvHDTV-1.6 software
Heavens, no need to clean the tree at all.  Just add "-X <file> to your diff.  I 
have attached what I use for <file>. It is likely over kill, but should do...

-g

Gene Heskett wrote:
> Greetings;
>
> I've spent a goodly part of the last 3 hours rebooting, to find out
> where this audio control function died, and I think now I can point
> an accusatory finger at the 2.6.11.2 patch with some degree of
> certainty.
>
> The scenario goes like this:
>
> reboot to 2.6.11-rc5, everything works flawlessly except the 1394
> stuff, that kernel didn't have it built in yet.
>
> reboot to 2.6.11+bk-ieee1394.patch everything works flawlessly
>
> reboot to 2.6.11.1+bk-ieee1394.patch everything works flawlessly
>
> reboot to 2.6.11.2+bk-ieee1394.patch tvtime has no volume control, and
> the sound gets very very tinny about 1 second after it starts
>
> This scenario continues up to and includeing 2.6.11.4.
>
> So now my next question is, how to I clean up those src trees so that
> a diff actually outputs only the src code differences, thereby
> allowing a simple diff -urN (or whatever is the recommended command
> line to do a recursive diff on the whole maryann) to disclose the
> real diffs. In other words, is a simple 'make clean' sufficient?
>
> I got the impression from a comment that was made, that quite a body
> of work was actually done, in the i2c area, that somehow does not
> show in the changelog, nor in that simple little 10 line patch that
> was 2.6.11.2. And how that little patch could be responsible for
> breaking this boggles what tiny little miniscule piece of a mind I
> have left at this point.
>
> If thats the case, then how did it get into my src code tree since the
> exact same 2.6.11.tar.gz was used as the base for applying each of
> the incrementals to each of the src trees I now have sitting
> in /usr/src? Good question that...
>
> Unforch, the 2.6.11 plain tree has not, in this case been built yet as
> it got accidently nuked by a missfire of my 'buildit26' script, which
> normally moves a base version tree out of the way before it unpacks a
> fresh copy, and then renames that tree to be the current version and
> then restores the base tree to its original name.
>
> Thats not the one I want to use as the 'gold standard' anyway.
> 2.6.11.1 works, and 2.6.11.2 doesn't. So at this point, 2.6.11.1 is
> the 'gold standard'.
>
> But, both the 2.6.11.1 and the 2.6.11.2 trees are as built, and the
> diff I got was far larger than forgetting to apply the
> bk-ieee1394.patch to one of them would account for. Many tens of
> kilobytes in fact.
>
> Please throw me a bone here folks.
>

--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
*.o
*.i
.*
*.*~
*~
*.rej
*.orig
*.orig.*
#*
*#
*.ver
ETAGS
TAGS
tags
*.map
*.s
*.a
*X
*Y

*.*X
*.*Y
SCCS
CVS
*.*,*
dwarf2-defs.h
kconfig
configs.c
defconfig
mkdep
split-include
tkparse
vmlinux
consolemap_deftbl.c
tkparse.c
classlist.h
crc32table.h
devlist.h
config
autoconf.h
compile.h
version.h
kconfig.tk
soundmodem
defkeymap.c
patest
asm
boot
conmakehash
gen-devlist
modversions.h
elfconfig.h
asm_offsets.h
*.old
cscope.*
*.so
gen_crc32table
docproc
fixdep
kallsyms
mk_elfconfig
modpost
pnmtologo
initramfs_data.*
gen_init_cpio

\
 
 \ /
  Last update: 2005-03-22 14:11    [W:0.037 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site