summaryrefslogtreecommitdiff
path: root/devel/management/commands
AgeCommit message (Collapse)Author
2010-10-04reporead: ignore nicknames in name matching codeDan McGee
2010-09-12reporead: revamp database parsing codeDan McGee
This needed a little sprucing up as it has grown quite organically over the life of this script. Make things a bit more pythonic through the use of iterators rather than collection indexing, and try to generalize the special cases of things a bit. Also catch encoding problems early and fail gracefully rather than blow up the entire package parser. A failed decode of a file should cause us to just skip it rather than stop the entire parser. Worst case, this leaves that package out of the web interface. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-09-10reporead: allow traceback on USR1 signal as wellDan McGee
When I have caught reporead behaving badly on the production box, I haven't been able to successfully get a traceback without killing the process. Hopefully using a different signal will allow me to actually capture some data. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-09-10Remove SomethingFishyExceptionDan McGee
Just use a plain Exception instead since we don't get any added value by subclassing. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-08-28PyLint suggested cleanupsDan McGee
We had a bunch of extra imports, non-conventional variable names, spacing issues, etc. that were relatively low-hanging fruit to clean up. Fix them and make the code a bit cleaner in the process. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-08-04reporead: Add ability to generate traceback via signalrelease_2010-08-08Dan McGee
Every once in a while we see this command hanging on the main server but it isn't making any system calls, so it is hard to tell where it is getting stuck. Add a signal handler on SIGQUIT that will listen and print a traceback when signaled. This is the easiest thing to implement; future additions may need to be able to hook up to a remote debugger (e.g. pdb) if this doesn't work. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-08-01Fix stupid mistake in user parsingDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-07-28Clean up find_user() code a bitrelease_2010-07-28Dan McGee
With suggestions from Jason Chu, make the code a bit less repetitive with regards to exception handling and fallthrough to the next method of finding the user. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-07-28Add missing group delete in reporeadDan McGee
Otherwise we get duplicate groups each time we update the package, and any group removals would never actually happen. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-07-28Add packager support to reporeadDan McGee
This is a bit more work than just a simple field addition. We attempt to map packager specs (e.g. "A. U. Thor <author@example.com>") to actual Django users in a relatively robust way- first try matching on User.email, then fall back to UserProfile.public_email, then finally try a name-based match. For those packages we can't generate a mapping, the raw string is still stored so it can be displayed. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-07-25Add package groups model and display to packagesDan McGee
They show up but aren't hotlinked to anything...just yet. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-07-06Update code to use new flag_date columnDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-05-26Have reporead populate filename columnDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-05-24reporead: use the DB package we already haverelease_2010-05-24Dan McGee
Rather than go to the database for every single package on something like a files update, use the one we already have. Duh. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-05-24Fix null field issues exposed by Django 1.1.2Dan McGee
Apparently Django 1.1.1 let null fields pass right through but this now causes reporead to blow up in 1.1.2. Fix the issue and get things working again by allowing nulls where it probably makes sense and including a migration to fix the issue, which for the real database will be a no-op. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-04-16reporead: allow removal of last package in an archDan McGee
We had a situation where the last 'any' architecture package was present in the [testing] repo and never got removed because we never did the db_update() call on that architecture. Instead of looping all possible architectures and only calling if len() > 0, always call db_update() for both the primary architecture and the 'any' architecture. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-03-27Make reporead always populate pkgbaseDan McGee
And also add a data migration to add the value retroactively for anything already in our database. We simply fall back to pkgname if pkgbase isn't available. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-03-10Fix one missed testing repo checkDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-03-01Merge branch 'package-files'Dan McGee
2010-02-27Make reporead.py not executableDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-27reporead: add --filesonly optionDan McGee
This will allow files to be imported for all existing packages in the database while not worrying about the files database being a touch out of date. It utilizes the new files_last_update column to perform the insertion and updating of file lists intelligently. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-27reporead: support reading files entries againDan McGee
This depends on some changes I made to our script that generates the file list databases, but it allows us to treat the files databases in an almost identical manner to a regular database. The only difference is the fact that it contains 'files' entries. One catch that will be addressed in a separate patch: if the files DB lags behind the regular DB, running an update from it could cause packages in the web interface to be downgraded. A 'no-add/remove' option could be helpful for this case. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-27reporead: whitespace cleanupsDan McGee
Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-27reporead: only reset needsupdate when setting last_updateDan McGee
Otherwise a --force will clear out all our flagged packages. :/ Whoops. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-26reporead: build date data is crazyrelease_2010-02-26Dan McGee
Just ignore it if it is completely screwed up. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-26reporead: accommodate old-school build dateDan McGee
I can't believe we still have some of these around, but they are relatively straightforward to handle. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-26reporead: allow a force updateDan McGee
This allows re-running repoadd on all packages in case of adding data or fixing a bug without rendering the last_update values in the database useless. For packages that aren't geting their version bumped, don't touch last_update on a force import but do touch the rest of the fields. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-26Add some additional fields to package importDan McGee
We can capture the build date, compressed size, and installed size when reporead runs. Even if we don't show all of it, we should pull it in. FS#14270 is requesting that the package size be shown on the website. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-16reporead: use different timestamp for each packagerelease_2010-02-17Dan McGee
Since these timestamps will differ across repos and arches anyway (for a total of 10 distinct timestamps currently per hour), it isn't really necessary to only use one timestamp. Allow each package to get a unique creation time. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-10reporead: small touchups, mostly in argument validationDan McGee
Check the arch, check the filename for existence, etc. Signed-off-by: Dan McGee <dan@archlinux.org>
2010-02-10reporead: turn into a django-admin commandDan McGee
Rather than struggle with getting the environment set up, let's make this a custom Django admin command and use the flexibility that gives us. This is the initial rough cut of making it happen; further commits should clean up some of the rough edges. Signed-off-by: Dan McGee <dan@archlinux.org>