Summary: | app-portage/gpytage-0.3.0_rc1: fails to start | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | dolsen, tools-portage |
Priority: | High | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Deadline: | 2020-09-21 |
Description
Pacho Ramos
2010-05-26 16:51:14 UTC
I think I see whats wrong with it. Are you running that via a user that can't read the portage files by chance? My user is in portage group :-/ Maybe the issue is caused by /etc/portage/package.keywords/e17 being a dead symlink, but I haven't tried it yet Yeah a dead symlink would do it. I forgot to handle an IOError other than printing that "Warning: Critical file blah not found". Not sure if it should really block stabilization. It'll be fixed in the next release in any case, thanks for catching it. No problem is dropping the blocker, it's a bit uncommon setup ;-) Getting latest snapshot from upstream should fix this This would also need a port to new python eclasses (if we want to keep this in the tree still) :/ Yes, I will along with adding a few more files to it's edit list I'll try to get it done this weekend any news on this? thanks Sorry, I haven't had much time. I'll try to get this one done by the weekend. The current release has been updated to eapi 6. I'll get his new github based code into a release when I can do more testing to make sure it is stable enough. He did a number of changes and improvements I think people will like. removed. |