Fixes the bitbakepath variable not being defined with -x/--nofetch
specified.
(Regression introduced in c91372587bbddd4c595d7202e51a8740b787a06e.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This was added when we brought over a patch from the Clear Linux
Dissector, but here we're not using diff2html here so we shouldn't have
this either.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an extra tool that lets you view all of the recipe dependencies in
a layer. There is also a mode that shows only cross-layer dependencies,
which can be useful to find dependencies on recipes in other layers
that aren't declared in the layer's dependencies (or conversely where a
layer dependency is no longer necessary).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
You'd think this is very unlikely to happen, but back in
meta-openembedded commit 415e213ad75ec9a93171c963395a1c4b92c6233b and
the commits preceding it, a recipe was added to the root of the
repository and then moved into place, and os.path.relpath() does not
like to be called with a blank path and thus raises an exception. To
avoid the exception, get the relative path to the filename and then chop
that off instead of the other way around.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add the ability to compare available recipes and their versions between
two branches for a selection of layers (default is just OE-Core). This
was mainly intended to help us with the Yocto Project release notes
preparation (hence the "Plain text" button at the bottom of the page)
but is also useful in its own right.
Note: for readability, SRCREVs are only shown when PV has not changed.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
For the purposes of the branch comparison function I'm about to add it
would be useful to track the value of SRCREV, so we can see if it has
changed even if PV hasn't.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Just because git.yoctoproject.org is in the URL, doesn't mean we can or
should force the vcs_web_url to be a specific value. If it starts with
git://git.yoctoproject.org then we can do this. git.openembedded.org
already did this.
This also changes github, gitlab and bitbucket references.
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add a new BITBAKE_PATH to the settings file to specify the path within the
BITBAKE_REPO_URL where bitbake lives. This is useful when using a combined
repository, such as poky, that contains bitbake, openembedded-core and other
layers.
This change also changes the default path, in the fetch directory, for the
bitbake checkout. It no longer uses the path 'bitbake', but instead uses the
same URL processing as the layer fetching.
There is a side effect that, when using a shared fetch, the branch of the
layer will be used instead of the specified bitbake branch. Generally this
is a reasonable compromise, since in a combined repository bitbake and
openembedded-core component should already match.
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Without this change the system will fail parsing various URL components
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This change is to record PE (epoch) and PR (release) values for recipes.
These values will be reflected in the REST API but will not be exposed
in the UI. The aim of this change is to enrich metadata availability to
consumers of the feed.
Signed-off-by: Pranay Mankad <pranaymankad@gmail.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
On some systems it seems the order of fields in a values() query aren't
guaranteed, so in order to avoid the contents dancing around too much,
explicitly write out the fields in the order we expect them to be in.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Unfortunately the "updated" date gets changed every time the repo is
fetched (i.e. vcs_last_fetch changes), but that doesn't mean the
layerbranch or anything under it has actually changed. Use vcs_last_rev
instead although unfortunately that won't catch manual edits to the
layerbranch alone.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Provide a way to export and import other distro recipe coverage in
update_classic_status.py.
(Based on the Clear Linux Dissector commit
ff38e9582093453e13b90e06af125374ca4b0a16).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I'm about to add a few command line options to this script, so switch
over to argparse before that which is more modern and a bit more
flexible.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
I forgot the lesson of f5922091b4 which
was that djangorestframework has a very silly default of registering
the model name as the key for finding the ViewSet, with the result that
the recently created RecipesExtendedViewSet was also being used for the
recipes URL which we expect to point to RecipeViewSet; this broke the
bitbake-layers layerindex-* commands.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The new viewset has a different URL and uses pagination, so we need to
take that into account.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Adding these extra child items to the standard "recipes" viewset (which
we did recently in 684a06a383) means that
some current usage is impractical due to the size of the returned list
of items. Instead, create a recipesExtended viewset, move the new child
items to that and add pagination to avoid result size issues.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If a LayerBranch is on a branch that is in the remote layer index (and
that branch is in any branch list specified with -b/--branch) and the
layer for the LayerBranch is not found in the remote layerindex then it
should be deleted, otherwise we could end up with stale data.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an option to import only certain layers - mostly for debugging
(can make testing a lot quicker).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We only work with branches that exist in both the local database and the
remote index, but allow the user to restrict the list further if
desired.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
This is not a comprehensive test, but does provide a way to easily
compare that what was originally fetched for a recipe from the API is
the same once it's been imported into a new instance using
import_layers.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Import recipe data from the REST API, including sub-recipe objects
(sources, patches, PACKAGE_CONFIGs, dependencies etc.) now that they are
available from the API. Also, with the data being more or less complete,
it's also reasonable to also set the vcs_* fields so that we can tell
how up-to-date it is.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Don't assume we need to create these objects - check the updated field
value against what the API reports and update the existing object if the
latter is newer.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
For LayerDependency, LayerMaintainer and LayerNote objects, properly
sync the objects in the database with the objects fetched from the API.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
These are a little less useful than the other items but if we want to be
able to create a clone of a layer index then we need them.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We're tracking these items for each recipe, so they should be
accessible via the API as well.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The try-specfile subcommand is for testing, so it's entirely possible
the spec file we are testing with will be in the current directory;
os.path.dirname() returns '' in this case, which os.path.relpath() then
chokes on. Avoid this in the easiest way possible by just prepending ./
to the path in this case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's not common, but if someone saves a spec file with a non-UTF8
encoding then the surrogate characters were preventing the data from
being saved to the database (at least with MariaDB). Instead of assuming
UTF8, try a few common encodings on the first 100 lines.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add a SECURITY_QUESTIONS_REQUIRED setting that defaults to True, but if
set to False then a user who has not set security questions will still
be allowed to reset their password. This is convenient for the OE Layer
index because there are a number of existing accounts, none of which
will have security questions set.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If you clicked on logout in the admin site then clicked on the "Login"
button and logged in, you were redirected to the logout page because we
weren't detecting that the redirection should not be applied.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Tweak message when one or more (but not all) security question answers
have been changed so that it's clear that all are required
* Ensure success message gets shown upon saving
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Require all three answers to be correct (previously only two had to
be)
* Give the user three attempts instead of just two
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We use django-axes to lock out IP addresses after a set number of
attempts at logging in, and separately we use django-reversion to
record change history. As part of the history tracking, the default
behaviour of django-reversion is to wrap all POST requests in
"with transaction.atomic()", with the result that if an exception is
raised any changes get rolled back; unfortunately when authentication
fails for the final time, axes updates the database and then raises
PermissionDenied - with the result that the database changes are rolled
back, and the user's IP is not locked out, in fact it can never be
locked out. To work around this, disable the atomic mode on
ReversionMiddleware using a subclass. (I don't like having to do this,
but this is the quickest solution for now.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Simplify things a bit. We lose the digg-style pagination but the new
behaviour is good enough and improves maintainability.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
When running a task (e.g. importing other distribution data), the web
frontend polls to get task output every second. In the view handling
this request we check to see if the underlying Celery task is finished
by getting the AsyncResult and then calling result.ready().
Unfortunately that latter call seems to be failing some of the time in
the development Docker setup that I am using, throwing a
ConnectionResetError. Because the polling is regular it doesn't really
matter if this fails as there'll be another chance on the next poll, so
just allow the call to fail silently. (It pains me to put in workarounds
like this but at the moment I can't determine the real cause of the
issue, and this stops the stream of ultimately useless error report
emails that I'm getting as an admin of the development instance).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Calling communicate() blocks the process; but since we're writing the
output directly to a file and not sending any input we don't actually
need to call communicate(), just poll() (so that we can check
the returncode attribute). Subjectively this does appear to improve
performance although it has not fixed the ConnectionResetError issues.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If an update task's output contains a single quote for example (') then
this will be escaped to an HTML entity before it gets sent as a
response. However, that means that the length of the data in the response
will be greater than the length of the original data, resulting in
characters getting missed out when we read the next chunk - so we
can't use the escaped length to set the next position to read from. The
easiest thing to do is have the Django view send us the actual position
we're at and then we don't have to try to calculate it on the JS side.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
There's no particular reason these fields should be read-only (unlike
the fields picked up from Recipe, they aren't derived from the recipe
itself.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
