On Fri, Sep 12, 2008 at 7:44 PM, Dusty Phillips <[EMAIL PROTECTED]> wrote: > 2008/9/12 Aaron Griffin <[EMAIL PROTECTED]>: >> They're stored in /tmp/archweb_update.log and emailed to me once a >> day. This is all done in the cron script located at >> /etc/cron.hourly/update_web_db.sh > > What about debug level messages?
I'm fairly certain those *don't* go to the syslog, and they're all output to the same script. Maybe the level can be adjusted (at the top it looks like it sets something to WARNING). >> 2008-09-12 18:02:38 -> INFO: Finished repo parsing >> 2008-09-12 18:02:38 -> INFO: Starting database updates. >> 2008-09-12 18:02:38 -> INFO: Updating Arch: x86_64 >> 2008-09-12 18:02:47 -> INFO: Finished updating Arch: x86_64 >> 2008-09-12 18:02:47 -> INFO: Updating Arch: i686 >> 2008-09-12 18:02:47 -> INFO: Removing package kde-l10n-ca from database >> 2008-09-12 18:02:47 -> INFO: Removing package xalan-java from database >> 2008-09-12 18:02:47 -> INFO: Removing package fcgi from database >> 2008-09-12 18:02:47 -> INFO: Removing package enblend-enfuse from database >> 2008-09-12 18:02:47 -> INFO: Removing package netcdf from database >> 2008-09-12 18:02:47 -> INFO: Removing package mirage from database >> 2008-09-12 18:02:47 -> INFO: Removing package glhack from database >> ..... lots and lots of "Removing package" lines .... >> I wonder a) why those were removed and b) if that is related to the >> x86_64 orphaning > > b) is almost certainly yes. The packages get removed and then > presumably get added again later with orphan status. This must be > thoroughly fucking up the web interface new package notification. > > a) is WTF. I just checked the current state of the db.tar.gz and they > seem to contain packages that reporead claims were removed. So it > doesn't look like anything is breaking the db.tar.gz. It seems more > like reporead is not reading the whole file. But its still possible > the db.tar.gz has been fixed since the error occurred. > > I have added some logging info to say how many packages are currently > in the web db and how many are in the new sync db. If these are > disparate the problem is in the code that loads the repo.db.tar.gz. > Otherwise its in the code that adds/removes packages. > > I also implemented a check to warn or exception if these numbers are > 75% or 50%, as Paul suggested. > > I don't have time to look for anything else right now, hopefully it > will keep happening so I can track it down. > > Does somebody want to give me a quck rundown or wiki article of how > the database tools move packages from svn to release in > repo.db.tar.gz? I'm thinking if reporead wants to be this anal, maybe > we should add some hooks to whatever script says 'I just released a > package, please update the database' and sync up the web database at > the time things get updated. That's actually what we tried to get away from by doing this. The old DB scripts were so tightly coupled to gerolde, it was near impossible to test them. We actually had binaries that did mysql work. I don't want to go back to that way of doing things. This should all be as decoupled as possible.... > Sorry I don't know what's causing this folks. I'm just praying its a > long standing bug and can blame it on cactus instead of having to come > back to y'all and say "well here's the thing, I introduced this really > really stupid bug into reporead.py....." ;-) I plan on looking into this on my saturday sprint too. I can do some testing and maybe some improvements of reporead.py too. Should be straightforward - setup a DB, grab the django code, wget the extra DB file, and bam.... Anyone else willing to work with me on testing this one?
