I have just released porthole-0.4.1_rc1 with all the changes from bugs #67198, 67610, 67537. If there are no reported problems with the new install location,method & ebuild I will bump it to full -0.4.1 status. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 42470 [details] porthole-0.4.1_rc1.ebuild
I notice the .desktop file runs porthole with sudo, which will cause nothing to happen often because the user will have no way to give sudo their password this way. gksudo would seem to be a better option for this.
The .desktop file also is set it to run in terminal, which on my system opens first asking for the password there. If it fails to get the password it closes again. That is something that is easily changed if it will be a problem for some systems. I thought it might be easier for some noobs set up this way. I also added some einfo statements to the ebuild about it. As for gksu that would add a dependancy to porthole. I do however want to add gksu's newly splitout libs (gtk widget) for getting and running things as a different user. That way porthole can start and run as a user and only run processes such as emerge as root. But it currently does not have a python interface.
why is porthole not bumped in portage and why is it still masked in portage? also - is it not possible to use with porthole some method of getting root password like gnome-system-tools do?
It has been very stable. The only problem reported was with the .desktop file for KDE users. I have changed it for the next release. I have fixed a few more bugs and have gotten a little more done integrating getttext support. I can hopefully get enough time this weekend to package up a full -0.4.1 release. As for getting root password. The gtk widgets for doing that do not yet have a python interface. I am going to work on that for the next release. I also hope to have fam support included as well.
I have now released porthole-0.4.1 stable. As I said earlier the only problem reported was due the changes I made in the .desktop file which I have changed back. The new ebuild for it includes the gnome flag check code for pygtk. I reseached it some more and saw that if the person did not have gnome installed then libglade may not be included for porthole to run. I hope you are able to include this release in the portage tree soon. Thanks... Brian
Created attachment 43616 [details] porthole-0.4.1 ebuild
Can porthole-0.4.1 be put in the portage tree. I am getting bug reports from people because they have upgraded to portage-2.0.51 and porthole-0.3.1 is still the only version in the tree. Porthole-0.3.1 should also be removed from the tree because of portage-2.0.51 as well as other porthole bugs.
Porthole is really nice, but something that annoys me is the way it treats installed packages. While portage through emerge treats differently user-chosen installed packages (the world file) from dependency packages, Porthole shows all of them in the same category/level. This causes different 'problems': packages that would/should not get updated because they are only needed in a specific version as dependencies will get updated by Porthole (but not by emerge -Duav world). Another annoying thing is that all upgraded packages through Porthole get added to the world file - which completely ruins the way portage sees packages and dependencies. Maybe instead of upgradable packages in Porthole, using the more portage way of emerge -Du world should be considered for use in Porthole. IMO a portage frontend should use the backend exactly how the user would. A user does not tend to check each package individually to see if there's a newer version and install it seperately. I believe Porthole is missing something of portage here.....
I somewhat agree that porthole's upgrade listing should be improved. I was not initially involved with that portion of portholes coding, but I do know that portion of the coding has not been worked on much because we were (at that time) under the impression that portage would have had an official API by about now which would change how porthole used portage. I know that Jason is working hard at creating an API that is light weight enough and compatible with portage's existing coding to be properly useful. As it is now porthole lists all upgradeable packages, BUT only pre-selects packages that are in your world file. If you select a dependancy then it calls emerge to upgrade it. I could look into adding code to prevent a dependacy from being added to the world file. I aslo want to work on getting a tree listing of upgradeable packages with it's dependancies that need upgrading as well. That is something I could have more time to work on now that porthole is quite stable and dependable. The question I have about that decision is wether or not that effort would be depricated by the time I get it all worked out if Jason is able to integrate some of the API into portage that could already due that. Porthole has a long way to go yet before I would consider it to be complete. Brian
In CVS now, sorry for the delay.
*** Bug 67198 has been marked as a duplicate of this bug. ***
This is an excellent app. and it makes using portage a pleasure instead of the nightmare it has been (for me anyway) with having to figure out which of 3 or more tools I should use and which flags each needs to get the information I want. Gad Kadosh was right to wonder why it was masked - I only found out about it because of the advert in GWN and then to get a working copy I had to stick it in my overlay tree but I'm very glad I did. The point about it not behaving as portage does wrt dependencies is interesting too: I prefer to have my world file app's using the latest versions of libraries etc. and because I was forced to install the Gentoo system ~x86 a while back, I've been unable to use emerge -Du (this was before the /etc/portage/package.* change which I know provides a way round the problem but I haven't gotten around to it yet). Anyway, I hadn't noticed how many dependency upgrades I'd missed until I installed Porthole and it has been a great help. It would be very useful if it could also list the installed packages depended on by the available upgrades because even without my particular problem, I expect I would still like to be able to frequently re-emerge various critical app's to use updated dependencies. There are also many individual app's that I specifically watch for new versions and Porthole is a great help for making sure their dependencies are up to date even when they're supposedly still unstable - just now for example I was browsing my installed packages with Porthole (something that was previously utterly impractical) and noticed Lyx's dependency on Aiksaurus... well - see for yourself. Anyway - thanks for a really useful tool Brian (et al?): it's not often a GUI based app. does so much to remedy the failings of it's CLI equivalent(s)
