mirror of
git://git.yoctoproject.org/layerindex-web.git
synced 2025-07-19 12:49:01 +02:00

If a file is modified and renamed it will show up in both iter_change_type('M') and iter_change_type('R'), however naturally the file that will exist will be the b path and not the a one, so we should be looking at the b path or we will get errors. FYI you can reproduce this with OE-Core (in a scratch database) using the following procedure: 1) (in the OE-Core layer directory): git checkout 59285b324f6d9ed270b0bef209ef5da22a620a83 2) update.py -l openembedded-core -b master -x --nofetch -r --fullreload 3) (in the OE-Core layer directory): git checkout 086308aa2a5e332de6f00ed397c4a55d132f158f 4) update.py -l openembedded-core -b master -x --nofetch Without this change you'll see the following error: ERROR: Unable to read /opt/layerindex/layers/git___git_openembedded_org_openembedded-core/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb: Traceback (most recent call last): File "/opt/layerindex/layers/bitbake/lib/bb/command.py", line 84, in runCommand result = command_method(self, commandline) File "/opt/layerindex/layers/bitbake/lib/bb/command.py", line 568, in parseRecipeFile envdata = bb.cache.parse_recipe(config_data, fn, appendfiles)[''] File "/opt/layerindex/layers/bitbake/lib/bb/cache.py", line 315, in parse_recipe bb_data = bb.parse.handle(bbfile, bb_data) File "/opt/layerindex/layers/bitbake/lib/bb/parse/__init__.py", line 117, in handle return h['handle'](fn, data, include) File "/opt/layerindex/layers/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 132, in handle abs_fn = resolve_file(fn, d) File "/opt/layerindex/layers/bitbake/lib/bb/parse/__init__.py", line 141, in resolve_file raise IOError(errno.ENOENT, "file %s not found" % fn) FileNotFoundError: [Errno 2] file /opt/layerindex/layers/git___git_openembedded_org_openembedded-core/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb not found Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
3.0 KiB
3.0 KiB
TODO:
- Auto-detect dead layers and visually mark
- Formal deprecation process?
- Email people when status will change?
- Show other branches when looking at layer - maybe change the focus to show all layers rather than layers at a selected branch?
- Allow users to make a comment sent to admins/maintainers?
- Marking for recipes with ptest enabled
- Make it easy to update people's email addresses
Bugs
- Duplication of first maintainer when editing to add a second?
Other
- Full-text search on layer contents
- Handle layers that have branch (e.g. master) that is empty
- Add log in again link to logout page.
- Collect interesting news (layer add/delete, recipe add/delete/upgrade) and provide RSS feed
- "Split layer" tool for when a layer is split out of another? (Saves time adding records everywhere)
- All-branch search/results so you can see version availability of recipes in all branches at once?
- Show OE-Classic search results in OE-Core search? (with appropriate disclaimers)
- Display no-results found message when search does not return any results in layer search
- Way to notify in search results when user searches for something that has been renamed / replaced / deprecated?
- Show an alert on recipe page when recipe is outside of layer's BBFILES
- Document macros for URL fields
- Show layer type in layer detail?
- Usage links in list page?
- Subdirs in list page?
- Query backend service i.e. special URL to query information for external apps/scripts
- Add comparison to duplicates page
- Create simple script to check for unlisted layer subdirectories in all repos
- Auto-detect more values from github pages?
- Ability for submitters to get email notification about publication?
- Update script could send warnings when parsing layers to maintainers? (optional)
- Click on OE-Classic graph element to go to query?
- Use bar instead of pie graphs for OE-Classic statistics
- Ability for reviewers to comment before publishing a layer?
- Show a note at the top of the layer edit form if there's a validation error
RRS:
- Ability for maintainers to create their own maintenance plans
- Use gitpython instead of shelling out to git to get commits?
- "Last updated" date doesn't show without upstream status data ?
- Try to replace raw SQL?
- Why are we scanning through recipe files? For some scripts, surely just gather Recipe records for the layer?
- Collecting/storing data for every maintainer for every change to the maintainers.inc file is wasteful
- Clean up rrs/tools/common.py
- Handle MAINTAINERS file?
- Need to handle eventual move of RECIPE_MAINTAINER to recipes?
- Change layer update structure so that RRS stuff can plug into it rather than having separate scripts
- We only list recipes that have upgrade info (an earlier design decision) - should we list all?
- Replace "All" with "(all)" and "No maintainer" with "(no maintainer)"?
- Link to upstream changelogs? (will require per-recipe variable)
- Link to other distro comparisons?
- Link to other distro package info pages?