We're currently creating a "PackageBases" when the "restore" command is executed.
This is problematic for pkgbases that never existed before.
In those cases it will create the record but fail in the update.py script.
Thus it leaves an orphan "PackageBases" record in the DB
(which does not have any related "Packages" record(s))
Navigating to such a packages /pkgbase/... URL will result in a crash
since it is not foreseen to have "orphan" pkgbase records.
We can safely remove the early creation of that record because
it'll be taken care of in the update.py script that is being called
We'll also fix some tests. Before it was executing a dummy script
instead of "update.py" which might be a bit misleading
since it did not check the real outcome of our "restore" action.
Signed-off-by: moson-mo <mo-son@mailbox.org>
Prevent some files/dirs to end up in the repo / docker image:
* directories typically used for python virtualenvs
* files that are being generated by running tests
Signed-off-by: moson-mo <mo-son@mailbox.org>
When using docker (compose), we don't create a venv and just install
python packages system-wide.
With python 3.11 (PEP 668) we need to explicitly tell pip to allow this.
Signed-off-by: moson-mo <mo-son@mailbox.org>
This allows migration of git history for packages dropped from a repo to AUR
in case they contain PGP key material
Signed-off-by: moson-mo <mo-son@mailbox.org>
Use "contains" filtering instead of an exact match
when a package name filter is given.
This makes it easier to find requests for a "group" of packages.
Signed-off-by: moson-mo <mo-son@mailbox.org>
this is similar to the message that gitlab produces:
$ ssh -T aur.archlinux.org
Welcome to AUR, gromit! Interactive shell is disabled.
Try `ssh ssh://aur@aur.archlinux.org help` for a list of commands.
$ ssh -T gitlab.archlinux.org
Welcome to GitLab, @gromit!
Signed-off-by: Christian Heusel <christian@heusel.eu>
This is done in order to relax the constraints so that dropping packages
from the official repos can be done with preserving their history.
Its sufficient to also have this present in the latest commit of a push.
Signed-off-by: Christian Heusel <christian@heusel.eu>
This should match more closely the expectation of a user.
A session cookie should vanish on browser close
and you thus they need to authenticate again.
There is no need to bump the expiration of AURSID either,
so we can remove that part.
Signed-off-by: moson-mo <mo-son@mailbox.org>
If it's a session cookie it poses issues for users
whose browsers wipe session cookies after close.
They'd be logged out early even if they chose
the "remember me" option when they log in.
Signed-off-by: moson-mo <mo-son@mailbox.org>
We add a new config option for cookies with a 400 day lifetime.
AURLANG should survive longer for unauthenticated users.
Today they have to set this again after each browser restart.
(for users whose browsers wipe session cookies on close)
authenticated users don't need this cookie
since the setting is saved to the DB
Signed-off-by: moson-mo <mo-son@mailbox.org>
We don't need to set these cookies when logging in.
These settings are saved to the DB anyways.
(and they are picked up from there as well for any web requests,
when no cookies are given)
Signed-off-by: moson-mo <mo-son@mailbox.org>
We don't need to set these cookies when an account is edited.
These settings are saved to the DB anyways.
(and they are picked up from there as well for any web requests,
when no cookies are given)
Setting these cookies can even be counter-productive:
Imagine a TU/Dev editing another users account.
They would overwrite their own cookies with the other users TZ/LANG settings.
Signed-off-by: moson-mo <mo-son@mailbox.org>
Whenever the AURREMEMBER cookie was defined, regardless of its value,
"remember_me" is always set to True
The get method of a dict returns a string,
converting a value of str "False" into a bool -> True
We have to check AURREMEMBERs value instead.
Signed-off-by: moson-mo <mo-son@mailbox.org>
- Add package name textbox for filtering requests (with auto-suggest)
- Make "x pending requests" a link for TU/Dev on the package details page
Signed-off-by: moson-mo <mo-son@mailbox.org>
community is merged into extra
testing -> core-testing & extra-testing
Announcement: https://archlinux.org/news/git-migration-announcement/
We list "testing" repos first:
See d0b0e4d88b
Co-authored-by: artafinde <artafinde@archlinux.org>
Signed-off-by: moson-mo <mo-son@mailbox.org>
Currently, the "Repo" column in "OfficialProviders" is not updated
when a package is moved from one repository to another.
Note that we only save a package/provides combination once,
hence if a package is available in core and testing at the same time,
it would only put just one record into the OfficialProviders table.
We iterate through the repos one by one and the last value
is kept for mapping a (package/provides) combination to a repo.
Due to that, the repos listed in the "sync-db" config setting
should be ordered such that the "testing" repos are listed first.
Signed-off-by: moson-mo <mo-son@mailbox.org>
Previously pinned urllib3 to v1.x. This is not needed though.
The incompatibility of v2.x is with poetry itself, but not aurweb.
Signed-off-by: moson-mo <mo-son@mailbox.org>
we copy static files used by PHP and Python versions into /static
preparation work for the removal of the PHP version
Signed-off-by: moson-mo <mo-son@mailbox.org>
The "install" module (v0.6.0) which is being used by poetry 1.4.0
has problems installing certain packages.
Disable the modern installer for now, until things are fixed.
https://github.com/python-poetry/poetry/issues/7572
Signed-off-by: moson-mo <mo-son@mailbox.org>
TUs and Devs can delete and merge packages directly.
Currently the comments they enter, don't end up in the ML notification.
Include the comment in the notifications for direct deletion / merge
Signed-off-by: moson-mo <mo-son@mailbox.org>
middleware must be added before startup:
fixes: "RuntimeError: Cannot add middleware after an application has started"
https://fastapi.tiangolo.com/release-notes/#0910
Signed-off-by: moson-mo <mo-son@mailbox.org>