On 03/19/2014 07:16 AM, Scott Talbert wrote: > On Wed, 19 Mar 2014, Scott Talbert wrote: > >>>>>>>>> Crap, that wasn't the most recent version. This adds a minor code >>>>>>>>> cleanup and >>>>>>>>> a lot more comments. >>>>>>>> >>>>>>>> This seems fine too, although I don't know how many people have >>>>>>>> previously >>>>>>>> dumped firmware lying around that they want to load, so who knows how >>>>>>>> long >>>>>>>> that has been broken, if it ever worked. :) I can't say I have ever >>>>>>>> tried that. >>>>>>> >>>>>>> It can't have been broken long, it's something I try to test on every >>>>>>> release. >>>>>>> >>>>>>> Merging. Thanks. >>>>>>> >>>>>>> Final tests? >>>>>> >>>>>> Ooops. concordance doesn't compile due to the API change to >>>>>> read_and_parse_file(). >>>>> >>>>> Sigh. This API change is causing yet more pain. It's going to force an >>>>> otherwise unnecessary lockstep update to congruity. In my opinion, it's >>>>> not >>>>> worth it for a "cleanup" type fix, so I'd suggest rolling it back. >>>> >>>> Next problem: your firmware file detection change has broken MH config >>>> updates - it thinks they are firmware: >>>> >>>> DEBUG (FindRemote): Testing: 046D, C124 >>>> DEBUG (FindRemote): Found a Harmony! >>>> DEBUG (ReadAndParseOpFile): In RAPOF >>>> DEBUG (ReadZipFile): Internal file is Description.xml >>>> DEBUG (ReadZipFile): Size is 345 >>>> DEBUG (ReadZipFile): xml is 0xa71080, and xmlsize is 345 >>>> DEBUG (ReadZipFile): data_size is 21249 >>>> DEBUG (ReadAndParseOpFile): Is zip >>>> DEBUG (ReadAndParseOpFile): Has binary! >>>> DEBUG (ReadAndParseOpFile): determining type... >>>> DEBUG (ReadAndParseOpFile): start/end pointers populated >>>> DEBUG (ReadAndParseOpFile): not a connectivity test file >>>> DEBUG (ReadAndParseOpFile): Looking for TYPE tag... >>>> >>>> DEBUG (ReadAndParseOpFile): Looking for PATH tag... >>>> >>>> DEBUG (ReadAndParseOpFile): Looking for DATA tag... >>>> >>>> DEBUG (ReadAndParseOpFile): Looks like a firmware file we made >>>> >>>> Do we really need to support reading the legacy firmware dumps? I'd vote >>>> for just pulling that out too. >>> >>> I'll go ahead and revert the fact we don't require INFORMATION tags, but in >>> this case, I'm pretty sure that won't help.... the addition of accepting a >>> DATA tag will likely trigger this. >> >> Yep, MH configs have DATA tags. This is what the MH XML looks like: >> >> <DATA><FILES><FILE NAME="Result.EzHex" SIZE="21249" PATH="/cfg/usercfg" >> VERSION="1" FW_VERSION="9.5" OPERATIONTYPE="userconfiguration"><CHECKSUM >> SEED="0x4321" OFFSET="0x0" LENGTH="0x52fb" EXPECTEDVALUE="0xa902" >> TYPE="XOR"/></FILE></FILES><INTENDED><SKIN>78</SKIN></INTENDED><ORDER><ORDER_ELEMENT >> >> NAME="Result.EzHex" RESET="true"/></ORDER></DATA> > > Why not add a <TYPE>Firmware_Main</TYPE> to the concordance dumped > firmware to just make it clear that it is a firmware file?
Hm. Yeah, we can do that. I didn't think of that because only some FW files have that in them, others have URLs we match on, and it feels weird to create something with tags the original file would never have, but I guess that's still cleaner. I'll whip up that change tonight, add it to the patch, test it and post it. -- Phil Dibowitz p...@ipom.com Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
