jon at rejon.org
Sat Jul 30 13:41:04 PDT 2005
Whoa, this is a lot to read. Did you get enough feedback on the files
with hash problems? How is this problem? I feel like I have lost track
On Thu, 2005-07-21 at 13:12 -0400, Nathan Eady wrote:
> > > There are still a lot of images with HASH in them,
> > Ok, I checked through them and found that 3174 are effected.
> Sounds about right.
> > That is a lot of affected files!!!
> > We need to develop a strategy for dealing with this. Ok,
> > Jonadab, could you advise us all as to the best way to conquer
> > and divide this task.
> My plan, such as it is, runs roughly as follows:
> 1. I have one script (not sure if it's in CVS or not; I can
> put it in tonight if it's not) that is designed to look
> through all the .svg files in the current directory, find
> ones that contain "HASH" in them, and for each one look
> through upload.log and extract all the apparently-relevant
> input log entries and write them to a file that's named
> the same as the .svg file but with .log appended to the name.
> Thus, if there's a broken file foo.svg, this script creates
> foo.svg.log and writes in it all the relevant entries it can
> find in the upload log. I *think* this script works, at
> least for the majority of cases, but there will be a few
> cases where for some reason it cannot find the relevant
> upload log entries, e.g. if the title and filename are
> HASHsomething so that it doesn't know what original title
> to look for in the log. Those few can be left for now
> until the majority are done, and then figured out by hand
> subsequently; there won't be many, I think.
> 2. I have another script (not sure if this is in CVS either,
> but again, if not, it can be) that is *mostly* done, that
> is designed to read the .log files and trace the process
> that upload_svg.cgi would have done with that input and
> basically reproduce it, creating a repaired file, which
> will have -repaired.svg appended to its name, to avoid
> overwriting the original. Thus, if there was foo.svg,
> which was broken, and the first script created foo.svg.log,
> this one creates foo.svg-repaired.svg or somesuch.
> 3. Someone will need to look over the repaired files created
> by the second script and verify that they seem okay.
> 4. Then the original, b0rkened files can be replaced with
> the new repaired ones.
> For files submitted anytime after 0.12 (i.e., any files submitted
> for 0.13, 0.14, 0.15, or 0.16 before I repaired the upload script),
> my plan is to re-process the incoming files, running the above
> steps over them before processing, so that we will re-do what was
> done for those releases, only correctly. Thus, release 0.16 will
> be, like the last two releases, based on 0.12 but with new images
> added from all of the releases in the interim. I hope that 0.16
> is the last release I have to do that way, as otherwise it's going
> to get cumbersome reprocessing all those files every time :-)
> Any images that were already corrupted with HASH keywords in
> the 0.12 release are another matter. They may have to be
> re-keyworded by someone. However, the good news is, *only*
> keywords seemed to be impacted by the hash bug until more
> recently, so I don't think any of those are missing author
> or title information.
> > Also, are you sure that the "hash bug" is squished?
> Yes, assuming everyone uses the version of Metadata.pm that is
> in CVS, that particular bug is gone. There may be other bugs,
> but that one is toast.
> > Hopefully, we can fix these images once and then that will
> > be that...
> Yes, and then we can get on to worrying about the character set
> issues again...
> This message was sent using 3wmail.
> Your fast free POP3 mail client at www.3wmail.com
> clipart mailing list
> clipart at lists.freedesktop.org
San Francisco, CA
USA PH 510.499.0894
jon at rejon.org
MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon at gristle.org
IRC: rejon at irc.freenode.net
Open Clip Art Library (www.openclipart.org)
More information about the clipart