Gentoo Forums

transcode with 11 flags? Even mozilla has more than that. mplayer is leading my personal list with 40. Good idea to keep those numbers in mind.

My two cents:

This project looks like it has a lot of potential. The only suggestion I'd make at this time is to have more abstract names for categories and sub-categories in the list. That is, "Applications" rather than "app", "Internet" rather than "net", etc...

A few more abstractions and it could be like a "Click'nCompile'nRun" system (except free )

Patrick

patrickbores wrote:This project looks like it has a lot of potential. The only suggestion I'd make at this time is to have more abstract names for categories and sub-categories in the list. That is, "Applications" rather than "app", "Internet" rather than "net", etc...

but they are using the names in the portage tree. why would they want to change them? they are the same as what you see when you emerge things in CLI.

patrickbores wrote:My two cents:

This project looks like it has a lot of potential. The only suggestion I'd make at this time is to have more abstract names for categories and sub-categories in the list. That is, "Applications" rather than "app", "Internet" rather than "net", etc...

A few more abstractions and it could be like a "Click'nCompile'nRun" system (except free )

Patrick

I have to agree Hayl, that is what the titles are in portage - you do realsie this is using portage right? How could you possibly change the name of the caetgories after an emerge sync?

I emerged porthole and everything installed sucessfully. When I run porthole as a user the application runs fine, but I can't update because I'm not root. When I try to run it as root, I get the following error:
Does anyone have any thoughts?

but they are using the names in the portage tree. why would they want to change them? they are the same as what you see when you emerge things in CLI.

Uh, because what good is a GUI tool if it's not high-level enough to offer something beyond what you get from the CLI?

I'm just saying that a high-level enough Porthole, coupled with Portage, could be the best software installation tool for Linux, and would appeal to non-geeks. But, if that's not the target audience, I guess it's fine.

patrickbores wrote:The only suggestion I'd make at this time is to have more abstract names for categories and sub-categories in the list. That is, "Applications" rather than "app", "Internet" rather than "net", etc...

We have discussed this. While it is certainly feasible, my personal feeling is that it would be a distraction for people who mainly use Porthole for browsing and searching the portage tree.

calhoun wrote:When I try to run it as root, I get the following error:

Code: Select all

Xlib: connection to ":0.0" refused by server

Can you run other X apps as root?

Can you run other X apps as root?

No I can't. But portage needs to be run as root. Is there a way to run porthole like super user filemanager?[/quote]

calhoun wrote:

Can you run other X apps as root?

No I can't. But portage needs to be run as root. Is there a way to run porthole like super user filemanager?

No. We experimented with using sudo, but it didn't work out.

So how is this application usable? Am I missing something in the setup?

far wrote:

patrickbores wrote:The only suggestion I'd make at this time is to have more abstract names for categories and sub-categories in the list. That is, "Applications" rather than "app", "Internet" rather than "net", etc...

We have discussed this. While it is certainly feasible, my personal feeling is that it would be a distraction for people who mainly use Porthole for browsing and searching the portage tree.

I reckon that if more metadata was added to the portage tree, this would be very feasible, and perhaps even recommended. But, for now, there's little point. And of course, if such a thing is implemented, you'd have to allow people to switch between the two styles.

calhoun wrote:So how is this application usable? Am I missing something in the setup?

You are supposed to be able to run X apps as root. I don't know how you have managed to make it not work.

Personnaly, in order to run X apps as root, I need to run before su'ing to root. This line can also be run automatically by puting it in ~/.bash_profile or something like that.

After that, porthole works just fine as root!

Having heard that Porthole was no longer masked in the tree, I emerged it. The compile went fine, except when afterwards I ran it, it died:

** (porthole:7230): WARNING **: `GtkTextSearchFlags' is not an enum type
Traceback (most recent call last):
File "/usr/bin/porthole", line 42, in ?
from mainwindow import MainWindow
File "/usr/lib/porthole/mainwindow.py", line 26, in ?
import gtk, gtk.glade, gobject, pango
ImportError: No module named glade


Any ideas?

I think you have to emerge pygtk with the gnome USE flag set.

Edit: or to be precise: libglade has to be emerged before pygtk

We just got a bug report that says the segfaults are occuring when porthole does not have focus when emerge completes and the main porthole window gets the callback signal to reload the databases.

If you are having any problems with segfaults. Can you confirm this, and if need be make sure that porthole is selected as the active window to prevent the segfaults.

This may be the clue we needed to figure out why they happened.

I may postpone the impending release of porthole-0.3.1 if we can eliminate this bug.

Thanks,

I have just tried syncing and emergeing several apps without having a segfault (porthole was in the background). This of course is the most recent cvs copy. I have fixed a number of bugs relating to the display, perhaps I have fixed the segfault source as well without knowing it. I would like to know from users if indeed that is the circumstances that cause the segfaults.

For those that want to get the newest cvs to test. It should have nearly all updates. The anonymous cvs is about 12 hours behind. I have one sorting bugfix in tonight, but I would appreciate knowing if the cvs version is still segfaulting before releasing -0.3.1.

Thanks

dol-sen wrote:We just got a bug report that says the segfaults are occuring when porthole does not have focus when emerge completes and the main porthole window gets the callback signal to reload the databases.

If you are having any problems with segfaults. Can you confirm this, and if need be make sure that porthole is selected as the active window to prevent the segfaults.

This may be the clue we needed to figure out why they happened.

I may postpone the impending release of porthole-0.3.1 if we can eliminate this bug.

Thanks,

Well thought out! Now that you point it out, it has only seg faulted and disappeared when on a desktop I have not been using - Yep, just done it again when finished a compile on a desk3 while I was on desk2. Let me know if you need any more info. HTH

ugly_orc wrote:Personnaly, in order to run X apps as root, I need to run

Code: Select all

xhost +local:

before su'ing to root. This line can also be run automatically by puting it in ~/.bash_profile or something like that.

After that, porthole works just fine as root!

Thanks alot ugly_orc, that worked perfectly.

far wrote:

calhoun wrote:So how is this application usable? Am I missing something in the setup?

You are supposed to be able to run X apps as root. I don't know how you have managed to make it not work.

Far, personally I prefer not to run applications as root unless they really need it, like emerge or porthole in this case. Its probably not even an application i will run because I prefer to run "emerge sync", "emerge system" and "emerge world"..... I'm still fairly new to Gentoo as of November (new but not that new) so I'm playing with anything that interests me.

I'm not sure if your on the development team or not, but since this app has the requirement to be run as root, maybe during the emerge process a check could be put in to verify that applications can be run as root. Or maybe that the above "xhost +local:" blurb is in the bash profile. Having not programmed in about 15 years, I'm not sure what the clean way is to check this.

calhoun wrote:Far, personally I prefer not to run applications as root unless they really need it, like emerge or porthole in this case. Its probably not even an application i will run because I prefer to run "emerge sync", "emerge system" and "emerge world".....

I understand perfectly and I do the same myself.

calhoun wrote:I'm not sure if your on the development team or not, but since this app has the requirement to be run as root, maybe during the emerge process a check could be put in to verify that applications can be run as root. Or maybe that the above "xhost +local:" blurb is in the bash profile. Having not programmed in about 15 years, I'm not sure what the clean way is to check this.

Yes I am a maintainer, but I don't think Porthole should meddle with the X setup. I don't know how to check if root is allowed to connect to the X server either.

I have tried every way that seems to segfault porthole without a single crash. So lets hope I fixed it somehow.

For those that were experiencing the crash. I have posted a new porthole-0.3.1.ebuild & package tarballs. You will find it in the Files section on portholes SourceForge website. After a little testing to make sure the ebuild & tarballs are working fine. We will make the announcement and send it to bugs.gentoo.org for inclusion.

I am a little anxious to know whether or not the segfault bug still shows itself with this new release.

Be sure to read the NEWS file in the package to find out about the bugfixes as well as a couple new features.

seems there's a problem with the digest for the 0.3.1 ebuild. kept crapping out. I deleted the digest, then re-ran ebuild porthole-0.3.1.ebuild digest, and it worked just fine.

I've found one fairly annoying design flaw:

the list of upgraded packages refreshes after every new package is installed. if you have a queue of 30-40 packages that you're upgrading, it's extremely annoying not being able to queue up more packages while a small one (say, mirrorselect) has just installed, and it refreshes every 30-45 seconds.

perhaps a better way would be to simply refresh after the queue of "to be emerged" packages is finished? it'd certainly make things less annoying.

Yes, there are plans to move the refresh into the background and only update the screen if needed without setting it back to the beginning.

I am still trying to figure out why the digest didn't match. I must have switched tarballs without realizing. I'll have to get back to it a little later tonight..