We do a lookup by DepName in the package details view, but I made the
silly mistake of forgetting this index addition in the upgrade steps.
Lukas: Fix numbering in "UPGRADING".
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We discussed this on aur-dev. Everything that depends on tupkgs should
be removed. Those who still want to be notified should move on to the
RSS feed.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
* Transform into valid Python 3.x code using 2to3.
* Change shebang from "/usr/bin/python2" to "/usr/bin/python3".
* Invoke with "python3" instead of "python2" in "reloadtestdb.sh".
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Package dependencies are no longer stored as references to the
"Packages" table but kept directly in "PackageDepends", so the dummy
data generation script should be fixed to create package names instead
of references, also. Regression introduced in commit
7c91c59245.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
use the logging module instead of writing directly to stderr
this makes the code cleaner as it removes the numerous tests for the value
of DBUG, yet allows devs to control the level of output verbosity.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
- remove need to use mysql for escaping the sql -- removing single quote
should be enough
- instead of using sql to fetch categories from a live database, simply
consider categories an integer range, specified to the size of that in the
aur-schema.
Lukas: Add "CATEGORIES_COUNT" initialization. Fix random number range
used in genCategory() (AUTO_INCREMENT columns are 1-based by default,
not 0-based).
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Instead, we just store dependencies directly in the PackageDepends
table. Since we don't use this info anywhere besides the package details
page, there is little value in precalculating what is in the AUR vs.
what is not.
An upgrade path is provided via several SQL statements in the UPGRADING
document. There should be no user-visible change from this, but the DB
schema gets a bit more sane and we no longer have loads of junk packages
in our tables that are never shown to the end user. This should also
help the MySQL query planner in several cases as we no longer have to be
careful to exclude dummy packages on every query.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
This change is necessary to prevent this:
mysql> delete from Users where ID = 112;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`aur`.`Packages`, CONSTRAINT `Packages_ibfk_2` FOREIGN KEY (`SubmitterUID`) REFERENCES `Users` (`ID`) ON DELETE NO ACTION)
As a bonus, due to foreign keys, orphaning of packages will be
automatic.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Stop hardcoding everything everywhere for those of us that don't use the
localhost/aur/aur/AUR setup. Also allow for the dummy data to be created
in the reload script if it does not exist. Finally, remove two
assumptions that the AUR database already exists.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
This is immensely faster when using InnoDB since we don't need to sync
after each and every INSERT statement.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Database is being dropped and recreated in the schema, so there's no
need to do this in "reloadtestdb.sh" as well.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
The dummy data generation script used to create wrong package IDs for
both "PackageVotes" and "PackageDepends" tables which led to errors when
reloading the test data (constraints failed). This is fixed by no longer
creating entries with zero ("0") package IDs.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Can be used to blacklist package names for normal users. TUs and
developers are not affected. This is especially useful if used together
with a cron job that updates the blacklist periodically, e.g. to reject
packages which are available in the binary repos (FS#12902).
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
Drop fulltext indexes, which prevent the use of InnoDB, from "Packages"
table. All search routines use "LIKE" patterns, so fulltext search has
actually never been used.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We don't even touch source tarballs anymore - except for extracting the
PKGBUILD, so this is no longer needed.
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
We don't need this anymore since all packages managed here are
well...managed here. Rip out all of the places we were using this field,
many of which depended on the magic value '2' anyway.
On the display side of things, we had a column that was always showing
'unsupported' that is now gone, and you can no longer sort by this column.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
This works by adding a new field to the 'Users' table called 'ResetKey',
which is a 32 characters long, random string. When the user requests a
password reset, a new 'reset key' is generated and sent to the user's
e-mail address in the form of a link in the following format:
http://aur.archlinux.org/passreset.php?resetkey=<reset key>
When the above link is followed, the user is presented with a form to
verify his/her e-mail address and specify the new desired password. If
the e-mail address matches the reset key in the database, the new
password is assigned to the account. If there is an error, a relevant
message is displayed and the user is prompted to re-enter the required
information. Upon successful completion of this procedure, the ResetKey
field in the database is blanked and the specific key cannot be reused.
One SQL query is needed to add the ResetKey field to the 'Users' table:
ALTER TABLE `Users` ADD `ResetKey` CHAR(32) NOT NULL DEFAULT '';
Signed-off-by: Loui Chang <louipc.ist@gmail.com>
To put a long story short, when we do joins on these tables in our
pkg_search_page() function, we always join on both the user ID and package
ID columns. By creating multicolumn indices, we can always get the exact row
we are looking for in the table.
The benefits of adding a unique index should also speak for themselves, as
we previously did not have this on either of these tables.
This is part one of a two-part series to address the fact that this query
was often showing up in our slow query logs.
Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Loui Chang <louipc.ist@gmail.com>
In run-tupkgupdate:
Set HOME for correct CVS auth.
Properly filter out unneeded messages from
CVS output, and prune empty directories on update.
Signed-off-by: Loui Chang <louipc.ist@gmail.com>
Add some variables to make it more configurable.
Do some general clean up on the script.
Signed-off-by: Loui Chang <louipc.ist@gmail.com>
Signed-off-by: Callan Barrett <wizzomafizzo@gmail.com>
This (should) get rid of anything to do with the unused column AURMaintainerUID
in the scripts and schema files
Signed-off-by: Callan Barrett <wizzomafizzo@gmail.com>
Signed-off-by: Simo Leone <simo@archlinux.org>
This fixes a bug where TUs and devs couldn't upload packages because
the query would have an extra column in it to mark the pkgbuild safe
automatically, guessing it got missed when the safe flags were
removed. Also fixes a screw up I made with the schema file when I
added the tables for the voting app.
Signed-off-by: Callan Barrett <wizzomafizzo@gmail.com>
Simo's original commit text:
The idea of safe flagging is unclear, poorly named, misunderstood,
and not even used. At the time this patch was created, less than
a third of the packages in unsupported were flagged safe, and less
than a tenth of users knew how to interpret it.
The safe flag has been replaced by a disclaimer on the main page.
