Hello
wouldn't it be helpful if applied patches are logged when VDR starts?
So no patch could be forgotten to be mentioned in a bug report!
nvram-wakeup displays msi:~# nvram-wakeup -D nvram-wakeup: Printing debug messages enbled. nvram-wakeup: $Id: nvram-wakeup.h,v 1.38 2005/03/16 22:43:39 bistr-o-math Exp $ nvram-wakeup: $Id: nvram-wakeup.c,v 1.78 2005/03/16 23:41:35 bistr-o-math Exp $ nvram-wakeup: $Id: nvram-wakeup-mb.c,v 1.279 2005/05/11 11:51:17 bistr-o-math Exp $ nvram-wakeup: $Id: bios.c,v 1.6 2004/01/23 12:00:04 bistr-o-math Exp $ nvram-wakeup: $Id: gmt-test.c,v 1.17 2004/07/21 12:19:57 bistr-o-math Exp $ nvram-wakeup: $Id: byteops.c,v 1.6 2003/03/18 13:44:03 bistr-o-math Exp $ nvram-wakeup: $Id: nvramops.c,v 1.3 2004/05/03 22:40:13 bistr-o-math Exp $ nvram-wakeup: $Id: guess.c,v 1.24 2005/03/16 22:43:39 bistr-o-math Exp $
I think that was a nice idea.
can't patches modify/add a string to a "Versionstring table" too, which VDR logs in syslog and (maybe) displays in the command window?
Rainer
Rainer Zocholl wrote:
can't patches modify/add a string to a "Versionstring table" too, which VDR logs in syslog and (maybe) displays in the command window?
Problem is: How to avoid collisions of different patches if they want to write to the same 'installed patches' list?
Only idea I have would be an installed-patches sub folder where every patch can place an unique-named file with an ID string. Then you just need a clever makefile that merges all these together into one include-able file.
Can make depend a file on every file in a sub folder? eg. does something like this work:
installed-patches.inc: installed-patches/* @cat installed-patches/* > installed-patches.inc
Cheers,
Udo
udo_richter@gmx.de(Udo Richter) 01.06.05 19:48
Rainer Zocholl wrote:
can't patches modify/add a string to a "Versionstring table" too, which VDR logs in syslog and (maybe) displays in the command window?
Problem is: How to avoid collisions of different patches if they want to write to the same 'installed patches' list?
Only idea I have would be an installed-patches sub folder where every patch can place an unique-named file with an ID string. Then you just need a clever makefile that merges all these together into one include-able file.
Can make depend a file on every file in a sub folder? eg. does something like this work:
installed-patches.inc: installed-patches/* @cat installed-patches/* > installed-patches.inc
assuming the degree of garbage in teh VDR folder is ninimal, such a simple script could be used: (Of course it would be more elegant if "depend" generates an exactfittung list)
#!/bin/sh
# very frist script FILE=cvs_revs.h FILETMP=$FILE.tmp mv $FILE $FILE.old
rm -f $FILETMP echo "/* Automatically generated by $0 */" > $FILETMP echo "static char* CVS_ALL[] = {" >> $FILETMP grep "^* $Id: .*$$" *.c *.h | sort | awk '{ print "/* Filename",$1" */","\n" """$2,$3,$4,$5,$6,$7,$8,$9,$10""," }' >> $FILETMP echo "NULL };" >> $FILETMP
diff $FILE.old $FILETMP if [ $? -eq 0 ] ; then echo no change mv $FILE.old $FILE rm $FILETMP else echo change mv $FILETMP $FILE rm $FILE.old fi
run in the VDR directory generates the file cvs_revs.h:
static char* CVS_ALL[] = { /* Filename audio.c: */ "* $Id: audio.c 1.3 2005/02/12 12:40:51 kls Exp $", /* Filename audio.h: */ "* $Id: audio.h 1.3 2005/02/12 12:20:19 kls Exp $", /* Filename channels.c: */ "* $Id: channels.c 1.42 2005/05/29 10:32:38 kls Exp $", ... etc.. NULL };
This file may be include into "vdr.h" or "vdr.c" The "redundant" "/* Filename audio.h: */" is to give "patch" some fix points for "fuzzy" logic, as this file might have many changes. At least i hope it may help...
VDR may run a loop like:
{ #include "cvs_revs.h" /* for CVS_ALL */ int i; for(i=0; CVS_ALL[i]!=NULL; i++) nvprintf(LOG_DEBUG, "%s\n", CVS_ALL[i]); nvprintf(LOG_DEBUG, "Built at: " __DATE__ " " __TIME__ "\n"); }
writing into syslog when it starts togehter with it's own version number.
There are two ways a patch can indicate it self it was applied:
If a patch is applied it could add it's own "Id$: patch" to the modified source file. Or it changes the CVS $Id. At least that would be fair to do...
The "make" calls the above script and generate the new include.
instead of "grep ...*c *.h" a "find" may be more usefull, as it can go recursive thru the directories.
Too the files date might be included if the "patch" forgat to change or add an Id.
The code was taken from Sergeis Haller "nvram-wakeup"
Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
Rainer Zocholl wrote:
The "redundant" "/* Filename audio.h: */" is to give "patch" some fix points for "fuzzy" logic, as this file might have many changes.
A diff -u needs at least three common lines before and after each change to pass through with 'fuzz'. And because this is a generated file, no patch should change it. In fact, it will be a common mistake to include this file in patches.
If a patch is applied it could add it's own "Id$: patch" to the modified source file. Or it changes the CVS $Id.
Again, if two patches try to modify the same source file, they MUST collide, because both want to change the $Id line. Then we'll be in patching hell, because patches will require proper ordering and depend on each other. (... patch X for plain vanilla VDR, patch X.1 for users of patch Y, patch X.2 for users of patch Z, patch X.3 for users of patch Y AND Z, ...)
The only way that wont introduce unnecessary conflicts is to add NEW files, like installed-patches/MyPatchName.info, and then collect all these info files somehow.
However, first, this requires such a method to be implemented in VDR, so you need Klaus to do it, and second, all patches must be adapted to support this. You really think this will work?
Cheers,
Udo
udo_richter@gmx.de(Udo Richter) 02.06.05 21:24
Rainer Zocholl wrote:
The "redundant" "/* Filename audio.h: */" is to give "patch" some fix points for "fuzzy" logic, as this file might have many changes.
A diff -u needs at least three common lines before and after each change to pass through with 'fuzz'. And because this is a generated file, no patch should change it.
Or take as "base" and add new lines. But then it can't be generated anymore.
In fact, it will be a common mistake to include this file in patches.
Yes.
If a patch is applied it could add it's own "Id$: patch" to the modified source file. Or it changes the CVS $Id.
Again, if two patches try to modify the same source file, they MUST collide, because both want to change the $Id line.
So there would be only to "add" a new "ID"
Then we'll be in patching hell, because patches will require proper ordering and depend on each other. (... patch X for plain vanilla VDR, patch X.1 for users of patch Y, patch X.2 for users of patch Z, patch X.3 for users of patch Y AND Z, ...)
Don't we have that already?
Does current patches do not change the ID or add a new?
The only way that wont introduce unnecessary conflicts is to add NEW files,
True.
like installed-patches/MyPatchName.info, and then collect all these info files somehow.
However, first, this requires such a method to be implemented in VDR, so you need Klaus to do it,
or make a patch for it? ;-)
and second, all patches must be adapted to support this.
"Should"... I assume the patcheers will do it on their own interresst, because they too would like see if the patch worsk with others or not.
An other way would be simply note the source file date and size (or md5 ;-)) to see which files were changed compared to the tar.
You really think this will work?
As the number of patches are still growing it will become harder and harde to reproduce errors. Do you always know exactly which patches were manually applied, say 3 weeks later...i wouldn't. Maybe VDR needs someday something like a mini-apt (iapt)? ;-)
Anyway: Does it really help debugging or to make VDR more stable to have more transparency?
Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
Rainer Zocholl wrote:
Then we'll be in patching hell, because patches will require proper ordering and depend on each other.
Don't we have that already? Does current patches do not change the ID or add a new?
I currently use 5 patches regularly, with no collisions and no patch ordering dependencies. 3 of the 5 patch menu.c without collisions. None of them adds any kind of ID string.
Do you always know exactly which patches were manually applied, say 3 weeks later...i wouldn't.
Actually... My VDR + plugin sources are built from the tars by a prepare script so I can always reproduce the current code base, and I can easily upgrade to newer versions without loosing anything. I can reconstruct every major version I've used since end of January.
Cheers,
Udo
udo_richter@gmx.de(Udo Richter) 03.06.05 02:52
Rainer Zocholl wrote:
Then we'll be in patching hell, because patches will require proper ordering and depend on each other.
Don't we have that already? Does current patches do not change the ID or add a new?
I currently use 5 patches regularly, with no collisions and no patch ordering dependencies. 3 of the 5 patch menu.c without collisions.
That may not fit for every one.
None of them adds any kind of ID string.
Not so nice, IMHO. But avoids collisions...
Do you always know exactly which patches were manually applied, say 3 weeks later...i wouldn't.
Actually... My VDR + plugin sources are built from the tars by a prepare script so I can always reproduce the current code base, and I can easily upgrade to newer versions without loosing anything.
Somewhere to download the script?
I can reconstruct every major version I've used since end of January.
Actually i thought more in the direction someone else "outside" should be able to reproduce the version (at least be able to see: "Was patched with xxxx but the user forgot to mention!") and that it should "be documented", not that actually yourself might have the problem... Too i don't think that everybody first makes a script before trying a new patch. But i do think that someone is likely to forget the patch he did manually.
Rainer
Rainer Zocholl wrote:
Actually... My VDR + plugin sources are built from the tars by a prepare script
Somewhere to download the script?
Its a quite hacked script, not really meant for publishing. Some tools for format independent archive extraction and patching, and code snippets for each package and each patch. It defaults to extract my full working version, but can be used to extract certain parts only.
I always thought of a more general script concept that would allow VDR source preparation 'a la carte' based on scripts, patches and config files etc, combined with dependencies and basic version checks (use file x for version <x.x and file y for version >=x.x), but never got to it. So many ideas, so little time. ;)
Cheers,
Udo