In the "Maintenance Plan" drop-down the maintenance plans point to the
"default" release and milestone, but it was picking the most recently
added record in the database rather than the latest one by date. Use an
order_by() to ensure we get the most recent release/milestone by date
rather than just the most recently added in case they have been added
out-of-order.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We were picking up lib/bblayers/example.bb in OE-Core, and it's possible
we might add similar templates in future. There shouldn't ever be files
we're interested in under lib/, and in the absence of the ability to
follow BBFILES, just exclude the directory explicitly.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
We need to capture the re-addition properly or the recipe simply won't
show up in the recipe list. Examples from meta-oe:
* psqlodbc removed in ec9e5ed06256ad92c818474cdb490dc0d3a0d0a3 and
added back in 16a6fee6c0455863ed5df15afc49efe8cc617d9c
* libgxim removed in 5dd01c5175f518658d8ee5627ede4f593111b872 and
added back in af602920594a9cc2e9b397fe311fda7f531be7f3
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>
In bitbake commit 5796ed550d127853808f38257f8dcc8c1cf59342, line
numbering functionality was improved with the starting line number for
python functions being stored in a "lineno" varflag; however, mapped
functions (using EXPORT_FUNCTIONS) did not have a line number set, which
caused parse failures. This bug was not fixed until
547128731e62b36d2271c4390b3fee2b16c535dc so we should be avoiding any
bitbake commit inside that range.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
In meta-oe there are two commits (d91f92cf04 and 57492d40b5) which have
the same commit date and thus don't deterministically order; the result
was that the mercurial-native recipe might or might not show up. Add id
to the order_by to make it deterministic.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
In OE-Core commit 309a02931779f32d1139cc1169a039cbe4638706, a reference
to BBINCLUDED was added to HOSTTOOLS in conf/bitbake.conf, however when
we use tinfoil to parse this BBINCLUDED is not set (probably too early)
and the result is an immediate parsing failure. The issue was eventually
fixed in 40a904bf8bc1279c3da0893c003f740f1d2066c2 however there are some
commits in this range that we care about, so within this range we hack
bitbake.conf to have a default for BBINCLUDED since it's an easy
workaround.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Sometimes in the past it has been desirable to create a shared .inc
file from a recipe, e.g. d5a95dc8985a42bb7e50bc4e7dc6b012d711ff08 in
OE-Core for tzdata. Git detects this type of change as a rename of the
.bb to a .inc with some changes, and an addition of a new .bb with new
content; however we want to treat it as a change to the .bb file and
ignore the .inc, otherwise it can look like the recipe was renamed and
the history becomes broken (it wasn't, the recipe name stayed the same).
Detect this situation and handle it properly.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add an option to stop at a particular commit (so we can then repeat a
specific commit afterwards easily for debugging purposes).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Record the previous version in RecipeUpgrades, and use it to more
accurately record upgrades where there are multiple versions present at
a given time (common with e.g. kernel recipes).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Make it possible to re-collect all the history for a given path.
(Typically this would only be used for debugging, as it saves time if
you are trying to correct an issue with upgrade data collection for a
single recipe.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we ever want to analyse the upgrade chain later on then we need to
avoid overwriting the paths when we identify a moved recipe - instead,
store a "move" upgrade record (not shown in the UI) that we can later
pick up when we are going through and deleting.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Silently catching all exceptions like this is evil. Use .first() and
check the return instead.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Version downgrades (or what appear to be downgrades) do occasionally
happen, and if they did then the RRS was previously simply ignoring
them, resulting in the latest version being reported incorrectly.
Allow downgrades to be recorded as an upgrade with a new 'Downgrade'
type option set, and display a label on such records in the UI.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
There are a range of commits in OE-Core which cause parsing problems;
map them to the one that fixes it in order to avoid the problem. (This
will only be done if we're dealing with OE-Core as a dependency, rather
than the actual layer we're parsing).
(The second set are some commits during the python 3 conversion time.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Now that we're using RecipeSymbols we have the complete list of recipes
that ever existed in a layer. We only want to see the ones that are
valid for the selected milestone, so when a recipe gets deleted (or
renamed or moved outside of the layer subdirectory, if any) we need to
record that - do so using a RecipeUpgrade record with a new field
upgrade_type set to 'R'. Additionally we need to store the file path so
that deletion events (where we don't parse the contents of the recipe,
thus we don't have PN) are easy to match up with RecipeUpgrade records;
naturally we need to keep the paths "up-to-date" when we notice recipe
files being moved around.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Recipes come and go over time, so when a recipe gets deleted the history
for it goes away, which means that if you look back in time you do not
see an accurate picture - you only see the subset of recipes that are
currently present. Introduce an indirection between recipes and history
that allows for old recipes to persist (mostly in name only).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Update Pillow version to incorporate a fix for a denial-of-service
vulnerability (which should not affect this application however, as it
does not use Pillow to process external images):
https://nvd.nist.gov/vuln/detail/CVE-2019-16865
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Typo, there has to be a ? in front of the id or otherwise we don't get
linked to the right commit. This would have affected recently added layers
with a cgit web frontend.
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>
Where we use glyphicons to mark items in a list, ensure there is a space
between the item and the icon to make things look a bit neater.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* Bump a few versions where we can
* Drop anyjson - this used to be a dependency of kombu but not anymore,
and nothing else needs it.
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>
* Drop some explicit outdated version numbers
* You do actually have to create the database with MariaDB etc. so add
instructions as to how for convenience
* Add pointer to virtualenv in python requirements item
* Add libssl-dev package to install command
* Use python3-venv instead of virtualenv package in install command
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>
If you enable the --letsencrypt option when you run dockersetup.py, the
script will modify the volume mount for the certificates to point to
/etc/letsencrypt instead of /opt/cert. If you then run dockersetup.py
again (with -r/--reinstall) without --letsencrypt, we want the path to
be set back to /opt/cert, so ensure that it does. Additionally, the code
wasn't actually setting the path for the layerscertbot service since
editing that section was done separately. (Admittedly, the letsencrypt
functionality has not been well-tested.)
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>
Don't confuse proxy options being defaulted through from the environment
and the user explicitly specifying them. Also look at no_proxy option.
Fixes https://github.com/intel/clear-linux-dissector-web/issues/13
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Add the ability to uninstall the application for the user's convenience.
(Note that this does not undo the changes to the configuration, it only
removes the Docker containers and volumes.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
* We need a SOCKS proxy to support fetching from git:// or ssh:// URLs
within the container, so add an option to specify it
* It's possible for the http and https proxy settings to be the same, so
set one from the other if only one of them is set.
* If we want to be able to fetch from internal servers inside the proxy
then we also need a "no-proxy" list, so add support for that.
* It's not unlikely that machines within networks requiring use of a
proxy for external network access will have all of the proxy settings
set in the environment, so we can try to pick up the defaults from
there.
* Ensure that we can switch from proxy to no proxy (when reinstalling)
which means we always need to edit the config files and ensure the
proxy options get commented out if we don't want them set.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
It's easy to get the proxy settings wrong and not realise until you've
got quite a long way into the process of setting things up. Thus, add a
check where we actually try to fetch various things within the container
environment and fail reasonably early if things aren't working.
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>
