Bugzilla Bug 219968

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 an attachment (id=152859) [edit]
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 :)