| Age | Commit message (Collapse) | Author |
|---|
|
With Python 2.x going out of support, we shouldn't have any references
to it and unfortunately that includes the ability to parse older
releases; however that's a sacrifice we'll have to make. The data
structures are still there, but we'll remove those later.
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
|
|
With Python 2.x going out of support [1], remove remaining references to
it.
[1] https://www.python.org/dev/peps/pep-0373/
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
|
|
I believe this script was accidentally committed (a long time ago). It
has bitrotted and doesn't work anymore, and only printed out recipe
descriptions anyway so let's just drop it.
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
|
|
These scripts have not been used or maintained for some time; I only
really kept them around in case it was useful as an example of how to
poke data into the database, but we have plenty of those in other
scripts.
Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
|
|
In OE-Core commit 8c9ef587fe499c612a878a1ab42092eb79b334ef an
AVAILABLE_LICENSES variable was added in license.bbclass where its value
is assigned with immediate expansion ( := ) with the result that it
looks in LICENSE_PATH for licenses; in turn LICENSE_PATH refers to
COREBASE. You might assume that COREBASE is always set, and normally it
is (since it's set OE-Core's layer.conf) - but in the layer index
context we do not parse layer.conf until a bit later, so it immediately
fails. The quick way to fix this is just to set our own (correct) value
for COREBASE and then AVAILABLE_LICENSES can be expanded successfully.
You might ask why we don't instead just set BBLAYERS such that we *do*
parse OE-Core's layer.conf - the answer is that that can have other
effects such as BBFILE_COLLECTIONS being set, and at least at the moment
the rest of the code isn't expecting that.
Fixes [YOCTO #13723].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Fixes a vulnerability in the password reset process due to
insufficiently stringent validation of unicode email addresses.
https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-19844
(The existing version specification would have selected the fixed
version of Django already for new installs, but bumping the minimum
ensures that it will be installed for upgrades with
./dockersetup.py -u as well.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Reloading an existing update task page was taking an extremely long time
to fetch down the task log and then pegging the client CPU such that the
browser gave a warning. Digging into it, logs from a Clear Linux update
task can be of the order of 500MB in size (with all of the line
refreshing using CRs that happens during downloads), causing (a) the
transfer to take a long time and (b) the JS code that updates the log
text box to be extremely busy. If we're loading the entire log from
scratch (as we are when we refresh the page) rather than just getting an
update since the last poll, we don't need any of those line refreshes -
so squash them out before returning the data.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If a recipe dependency (either static or dynamic) is removed from the
recipe when it is parsed, then we should ensure it gets removed from the
database as well.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Quite a few bugs fixed, as far as I know none that we observed, but good
to have. Details can be found here:
https://github.com/chartjs/Chart.js/releases
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Minor bugfix releases, but we should have them anyway:
https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/
https://blog.jquery.com/2019/05/01/jquery-3-4-1-triggering-focus-events-in-ie-and-finding-root-elements-in-ios-10/
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
https://blog.getbootstrap.com/2019/02/13/bootstrap-4-3-1-and-3-4-1/
https://blog.getbootstrap.com/2018/12/13/bootstrap-3-4-0/
These include a couple of CVE fixes, but this application already
sanitises data when rendering so it is unlikely to have been vulnerable.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
For debugging email functionality, python's SMTP test server is useful,
so add brief instructions on how to use it for convenience.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
There's a bit of advanced functionality by now in recipe searching, so
add a link that shows a popup with information on how it works.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
When using the layer: advanced query term, if you want to match on
OE-Core, its actual layer name is "openembedded-core", but people will
naturally assume that "oe-core" should work, so make it so (case
insensitive).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Allow filtering only on recipe name - i.e., searching for "git" finds
any recipe with "git" in the name or description. Now, you can search
for "pn:git" which will return only recipes with the name "git".
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Use shlex.split() to split the query string so that quotes can be used
to delimit strings containing spaces to be matched as a whole. This
worked with the previous code, but it did not support single quotes -
these caused an error in Django's filter code and thus an internal
server error (as did querying for ""). Add some additional checks for
single quotes as it is still possible to get them past shlex.split()
e.g. with something like "'hello'" (with quotes).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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>
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
The regex we were using here explicitly only matched numeric characters
in version numbers - presumably the assumption was that any non-numeric
characters were not significant. However, for upstream projects such as
OpenSSL and BIND for example, alphabetic characters are an explicit part
of the version number, so if we ignore them then we miss detecting most
of the upgrades. Fix the regex so that that doesn't happen.
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>
|
|
We have at least one instance where two versions of a recipe were added
at the same time and then later one was deleted - sed. We didn't detect
more than one recipe being added and thus the delete was seen as
removing the recipe entirely, causing the recipe to vanish. Fix the
filter so that we see the other addition and adjust the debug printing
so that we can see what type of deletions are occurring.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Going back in OE-Core recipe upgrade history, we kept GPLv2 and GPLv3
versions of a number of recipes around, so this is the source of quite a
few situations where we had multiple versions of recipes with the same
recipe name around. Add means of grouping upgrades by license so that we
can keep these versions separate in the upgrade history instead of
detecting lots of apparent upgrades and downgrades if they are
intermingled.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
By dumping the recipe upgrade data using the mostly same code as the web
application but in plain text format, this tool gives us an easy way to
compare recipe upgrade history data from multiple runs.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Aligning with recent changes in the layer index proper, handle where PV
is not changing but SRCREV is - typically this happens when PV does not
contain ${SRCPV} - ncurses in OE-Core is one example.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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 PN changes we need to mark the old recipe as deleted (since it is
effectively gone.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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>
|
|
Make it easier to see where each session starts when looking back
through the log.
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>
|
|
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 pytz and beautifulsoup4.
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>
|
Paul Eggleton
Paul Eggleton