| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
the PackageCmd and PatchCmd classes are now cached on their
first request.
note that this is incomplete, as the PackageCmd is also currently
used to print non-static information as well (when a package name
doesn't find an exact match and it does a query).
|
|
|
|
a new option (-i) to ./gen-patch-info.py allows for generating a global
"index" file with any and all information that the PTS might want from
this system. The format is:
{
"index-version": N
"packages":
{
"<pkg1>":
{
"url": url-for-all-versions
"versions":
{
"<vers1>":
{
<various attributes>
}
}
}
}
}
index-version is a monotonically increasing version number. when the
"schema" changes, this version is incremented. if we care enough, we
can do a major-minor versioning scheme where BC breaks are differentiated
from "new attribute" type changes by incrementing the major or minor
versions, respectively.
|
|
reprepro now seems to default to passching the lists files uncompressed
to the hook, so we deal with that gracefully either way.
python-debian seems to have slightly changed how it handles some multiline
fields due to starting to use the built-in apt_pkg module, see the comments
in Conf.py which should point to the bug.
|
|
this should never happen in production as the database contains
only a cache of what's on disk, but during testing on a system with
the database and no archive, or in unexpected circumstances, it
might be helpful to give a more informative error page.
|
|
i hear it's the new black. code change requirements weren't
very big at all, and apparently this will work better/stabler
on lenny systems, so...
|
|
previously this system was a cgi-based execution. however, this prevented
us from doing a number of useful things, like throwing a 404/5xx error
when an invalid page was requested. so, no we use mod_python instead...
|
|
|
|
|
|
This reverts commit 26a4f31bc27b021dbb332c536e7d14c65fdf54c0.
This reverts commit 5578d0fad24d68ecbd12a735c444910754db50ca.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
otherwise its gets pruned every page visit, whoops.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
no reason to, assuming i make a better way to track progress.
|
|
|
|
stop the voodoo with home-rolled "auto increment" type stuff.
also, use sqlite "extensions" for conflict resolution (in schema for
all but the source package table, which has it in saveSourcePackage),
so that we don't need to check for pre-existing records. the "OR REPLACE"
was doing this previously, but had wierd effects with modifying the
primary key, which would cause db inconsistency and *really* wierd effects
when combined with the triggers).
|
|
|
|
going to /packages/pkg now gives a table of contents with
the available versions for the package, or the results of
a widers search in the case of no exact matches
also removed a bunch of dead code from DB mostly
|
|
|
|
|
|
|
|
...instead of a source package, which should remove an
extra query and also allow changing the behaviour for
findSourcePackage later on as well
|
|
|
|
the suite isn't readily available, and doesn't make
much sense anyway since a single package/version can
be shared in multiple suites.
|
|
i.e. changes made directly to files (not using any
patching system and not underneath ./debian)
also introduce new Diffstat class for mangling
diff stats in various ways.
|
|
|
|
|
|
|
|
also introduce a singleton-like ArchiveDiffer class. the idea
is to eventually minimize the number of db queries and speed up
the archive<->database sync.
|
|
i know it's bad form to lump this all together. oh well :p
gen-patch-info now does very little besides processing packages
and updating the relevant database entries. pretty much everything
else is dynamically generated from pagehandler.py now.
|
|
|
|
|
|
complete with many ugly hacks to workaround the lack
of an underlying database. hopefully it's all marked
with XXX for later fixing :)
does not cover all patch cases, in fact currently it only
covers series patch viewing and downloading.
|
|
|
|
|
|
|
