Please test and rekeyword app-portage/porthole-0.6.0_rc2 if applicable. In my intial testing, this worked fine on x86 hardware, but failed with a segmentation fault on AMD64 hardware. Because of this I dropped the keywords for the other architectures that I could not test. Reproducible: Always Steps to Reproduce:
Adding relevant architectures.
on fbsd: ./pocompile.sh: 10: Syntax error: Bad substitution please make it #!/bin/bash if it uses bash substitutions as this will probably also fail with /bin/sh symlinked to e.g. dash I also get this: Traceback (most recent call last): File "/usr/bin/porthole", line 98, in <module> main() File "/usr/lib/python2.5/site-packages/porthole/startup.py", line 208, in main myapp = MainWindow() #config.Prefs, config.Config) File "/usr/lib/python2.5/site-packages/porthole/mainwindow.py", line 222, in __init__ self.init_data() File "/usr/lib/python2.5/site-packages/porthole/mainwindow.py", line 313, in init_data self.get_sync_time() File "/usr/lib/python2.5/site-packages/porthole/mainwindow.py", line 399, in get_sync_time self.last_sync = get_sync_info() File "/usr/lib/python2.5/site-packages/porthole/backends/utilities.py", line 81, in get_sync_info f = open(portage_lib.portdir + "/metadata/timestamp") IOError: [Errno 2] No such file or directory: '/mnt/portage_cvs/metadata/timestamp' Exception in thread Thread-1 (most likely raised during interpreter shutdown): PORTDIR is a nfs read only mounted cvs checkout, so I dont have metadata nor timestamp. Perhaps this should be handled more nicely ;) I'm wondering if your segfault isnt related to bug #209531
(In reply to comment #2) > ./pocompile.sh: 10: Syntax error: Bad substitution btw, imho it should die on such errors what it currently does not
I just committed the fixes for the pocompile.sh problems that you experienced. I need to follow up with upstream on the traceback.
Thank you for the testing and fixes needed to the pocompile script. I am certainly not a shell/bash programmer. I have my hands full with python/pygtk/wife/kids/pets... It was created by another porthole dev a few years ago. All I did was modify the one line slightly due to directory/code layout changes. I'll incorporate those changes for the final release. Thank you. I'll also change the timestamp code to fail nicely :) The timestamp is used as part of the tooltip for the sync toolbutton. Looking at bug# 209531, I tend to agree. Your segfault looked the same as one of the backtraces posted.
I just committed the fix for the timestamp error. revision 952 in portholes svn. It turned out the code was watching for the wrong exception. my bad :(
I just thought of something else I may need to change. Not having a timestamp, will render the auto-update of the descriptions db it creates dead. You could end up with a stale description db and get bad search results. Since this is not something that will come up very often for most users. What do you propose I do. If no timestamp found, then disable automatic description db updates? Then force a description db load when a description search is requested?
Adding ~sparc keyword because it appears to work. However, because this package seems to be changing, I'm leaving CC sparc intentionally --- please do not remove it. If the package changes w/o any version bumps, we want to retest to make sure it keeps on working on ~sparc.
(In reply to comment #2) I've done more testing with a renamed metadata dir to replicate your cvs checkout. Porthole becomes nearly useless without /usr/portage/metadata. portage calls to sandbox and ebuild.sh for data become slow but useable for basic one at a time package browsing but for anything more extensive use it seems to be like watching paint dry. Trying to load all the package descriptions, it got to only 8% of the packages after about 25 min. (I canceled it at that point). Scanning for upgradeable packages was nearly as bad. I monitored it's progress for a few minutes, opened a browser to this bug and filled in more than half of this message (I am a very slow at composing/typing) My guesstimate is about 7 minutes total for the upgradeable scan. Normally on my system that scan is between 5sec. to 45 seconds depending on how many it finds, competition for cpu cycles. So any testing should be done on a regular use machine with a normal portage tree that has metadata/cache.
Note that this can depend heavily on your portage configuration, as there several ways to change the cache configuration (e.g. the one in metadata/ might not be the only/authorative one).
I have just released the final release candidate before -0.6.0 final. It incorporates all bugfixes and changes needed/suggested. It now has 2 plug-in modules included that auto-detect their target commands and disable themselves if they are not found. Thank you for the testing and feedback. Brian
so far its been good on bsd, except one little thing, still with the pocompile script: it uses mkdir foo -p but bsd's mkdir doesnt like having the options at the end; I'll attach a patch shortly. Its slow with no metadata but still useable ;) (at least not much slower than emerge ^^)
Created attachment 152859 [details, diff] the patch
Thank you, I've added that fix to the _rc3.tar.bz2 since there had only been 2 downloads since I posted it a few hours ago. The updated ebuild for _rc3 is attached to the _rc2 bug that I've re-opened. bug #219902
~ppc'd
porthole-0.6.0_rc3 has been added and fixes the mkdir -p error on x86-fbsd
bsd done, thanks a lot Brian for the quick fixes ! I notice Ferris ~sparc'ed it but sparc is still in CC, dunno if there is a reason.
(In reply to comment #17) > I notice Ferris ~sparc'ed it but sparc is still in CC, dunno if there is a > reason. sparc was still in CC so we could re-test the package in case there were any changes(without version bump). I just did that and it's still fine, therefore I'm removing sparc and closing this bug...we are done here :)