| Summary: | sys-apps/portage - handle PermissionError from lockfile() portage.package.ebuild.fetch.fetch()? | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | emdee_is <emdee_is> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Perplexing traceback from media-libs/virglrenderer-0.10.1
context diff for non-python programmers |
||
Created attachment 839201 [details, diff]
context diff for non-python programmers
I guess we don't really expect to get a PermissionError when creating a lock file. If that happens, something has probably gone horribly wrong. The traceback doesn't seem too "perplexing" to me, and would actually be quite useful in debugging an error that should really never happen. |
Created attachment 839195 [details] Perplexing traceback from media-libs/virglrenderer-0.10.1 If the file lock at L1267 of portage/package/ebuild/fetch.py ``` file_lock = lockfile(myfile_path, wantnewlockfile=1, **lock_kwargs) ``` fails the user ends up with a perplexing double traceback (attached). There should be an Exception clause added to the try: that signals useful information back to the user: ``` except Exception as e: writemsg_level( _( "!!! Unable to lock file " "%s \n" "!!! %s\n" ) % (str(e), myfile,), level=logging.ERROR, noiselevel=-1, ) return 0 ```