Porthole is a gtk-based portage browser and the version 0.5.0_pre2 were relesed. So new porthole is required Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 72726 [details] Ebuild
localhost scott # emerge -av porthole These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] app-portage/porthole-0.5.0_pre2 -debug +nls 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage Do you want me to merge these packages? [Yes/No] yes >>> emerge (1 of 1) app-portage/porthole-0.5.0_pre2 to / >>> Downloading http://distfiles.gentoo.org/distfiles/porthole-0.5.0_pre2.tar.bz2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 305 100 305 0 0 1003 0 --:--:-- --:--:-- --:--:-- 0 >>> md5 files ;-) porthole-0.5.0_pre2.ebuild >>> md5 files ;-) files/digest-porthole-0.5.0_pre2 >>> md5 src_uri ;-) porthole-0.5.0_pre2.tar.bz2 >>> Unpacking source... >>> Unpacking porthole-0.5.0_pre2.tar.bz2 to /var/tmp/portage/porthole-0.5.0_pre2/work bzip2: /usr/portage/distfiles/porthole-0.5.0_pre2.tar.bz2 is not a bzip2 file. !!! ERROR: app-portage/porthole-0.5.0_pre2 failed. !!! Function unpack, Line 389, Exitcode 2 0 !!! failure unpacking porthole-0.5.0_pre2.tar.bz2 !!! If you need support, post the topmost build error, NOT this status message. #It seems that the source file is corrupt. Note the one at http://sourceforge is correct.
I would not worry about releasing this one. It is out of date already and I have -0.5.0 final ready except for the ebuild.
*** Bug 113986 has been marked as a duplicate of this bug. ***
OK, I'll restate the problem here. The ebuild we had reday for -0.5.0 no longer works (modified from our _pre2.ebuild). Portage spues out that it failed and that has_version cannot be used in global scope. The problem: pyxml DEPEND version is dependant on the python version installed. Porthole will work with either version, but -0.8.3 does not work with python-2.4. If >=python-2.4 then >=pyxml-0.8.4 else >=pyxml-0.8.3 Actual output: big_squirt porthole-cvs # ebuild /usr/local/portage/app-portage/porthole/porthole-0.5.0.ebuild digest !!! ERROR: app-portage/porthole-0.5.0 failed. !!! Function has_version, Line 194, Exitcode 0 !!! portageq calls (has_version calls portageq) are not allowed in the global scope !!! If you need support, post the topmost build error, NOT this status message. /output. Offending portion of the ebuild: if has_version ">=dev-lang/python-2.4"; then DEPEND="${DEPEND} >=dev-python/pyxml-0.8.4" else DEPEND="${DEPEND} >=dev-python/pyxml-0.8.3" fi
Urgh, such conditionals cannot be used for any metadata settings (and yes, pyxml is an evil package). DEPEND and co have to be exactly the same on *every* box.
So, then just up pyxml to -0.8.4 for everyone and the problem should be solved. I see that -0.8.4 is stable now anyway. That would help eliminate the odd problem when someone finaly upgrades python and discovers that it doesn't work anymore. But shouldn't python-updater catch the dependency change for pyxml and force the upgrade? I have to fix the tarball... had a bad translation file. I'll upload and release it as soon as it tests good, probably later tonight.
Created attachment 73943 [details] Updated ebuild I have released porthole-0.5.0 and the files are available on our sourceforge site. This release I've added the sparc keyword. I have had feedback from a sparc user that reported no problem running porthole on sparc. The only trouble was during the install, pyxml failed, but was successful on the second try. This release is significantly more stable and should be considered for unmasking. Thank you... Brian
~amd64 here 1) hitting buttons causes seg faults except for "Adv Emerge" 2) runing as user GUI su comes up with only Cancel button, valid passwd fails 3) runing as user browsing portage sometimes goes cashing for ever what causes to kill portage 4) runing as root would be good idea following URL bring up browser as normal user not root
Created attachment 75263 [details] porthole-0.5.0.ebuild
Porthole 0.5 stable has been released. The ebuild (from http://porthole.sourceforge.net/) is included in the attachment. Thanks a lot and sorry my poor english
Comment on attachment 75263 [details] porthole-0.5.0.ebuild # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ inherit distutils DESCRIPTION="A GTK+-based frontend to Portage" HOMEPAGE="http://porthole.sourceforge.net" SRC_URI="mirror://sourceforge/porthole/${P}.tar.bz2" LICENSE="GPL-2" SLOT="0" KEYWORDS="~x86 ~amd64 ~ppc ~sparc" IUSE="debug nls" DEPEND=">=dev-lang/python-2.3 >=sys-apps/portage-2.0.51-r3 >=dev-python/pygtk-2.4.0 >=dev-python/pyxml-0.8.4 >=gnome-base/libglade-2.5.0 nls? ( >=sys-devel/gettext-0.14 )" RDEPEND="${DEPEND} debug? ( >=dev-python/pycrash-0.4_pre3 )" src_install() { distutils_src_install chmod -R a+rX ${D}/usr/share/porthole dodoc TODO README NEWS AUTHORS COPYING MANIFEST keepdir /var/log/porthole fperms g+w /var/log/porthole # Compile localizations if necessary if use nls; then cd ${D}/usr/share/porthole ./pocompile.sh fi } pkg_preinst() { chgrp portage ${IMAGE}/var/log/porthole }
Created attachment 75264 [details] porthole-0.5.0.ebuild
I have started testing this and overall it looks good. However, I have had it crash on me. I will go ahead and add it to the tree but because of the crashes it will be package masked while I do more testing. sparc team: according to the bug report, they have had a request for keywording by a sparc user. Do you have any objections to the addition of the ~sparc keyword?
Thank you, I have no problem with it remaining masked, at least fo now. I have had it crash on me recently as well. From what I could determine I believe it was a dependency bug that caused it. Porthole has been running extremely stable for four months now. Since the first pre-release there have been very few reported problems/bugs. All reproduceable bugs have been fixed. See the forum threads in Unsupported Software for mre details. The best way to run porthole is with the -d flag from a terminal to enable debug printing so we can get an idea of what porthole was doing as well as some details of what it was working on. If pycrash is found on startup it enables it as well. Pycrash will produce an html page of all porthole's goings on if it is a python code crash. Segfaults are of course beyond its capabilities. I have been very busy lately (full time day job & a small retail business with extended christmas shopping hours) Sorry for the delay in responding to comment #9: ~amd64 here 1) hitting buttons causes seg faults except for "Adv Emerge" This sounds like a faulty gtk+ or pygtk install. This is the first time anything this severe has been reported. Are any other gtk programs giving this type of trouble? 2) runing as user GUI su comes up with only Cancel button, valid passwd fails This problem is related to the GUI su program not being able to grab keyboard/mouse focus from what Tommy has been able to determine. It is not directly porthole's responsability as porthole merely spawns a new shell process and waits for it's completion. If you cancel and repeat it usually works, but I have not had this happen in a long while (I was using gksu). 3) runing as user browsing portage sometimes goes cashing for ever what causes to kill portage That is usually due to some buggy ebuilds causing problems with portage. Portage should usually print some QA notice or similar in the terminal you launched porthole from. Does this continue after a new emerge sync? Again I have not seen any of these in quite awhile (x86) 4) runing as root would be good idea following URL bring up browser as normal user not root We have been waiting for the libgksu python bindings to go stable before introducing an internal su/user change ability to porthole. They are new and part of GnomePythonExtras. This release added limited sudo ability to porthole-terminal and a spawned process calls to modiy /etc/portage/package.* files using a user specified gui su program.
Looks sane enough for a ~sparc keyword, just don't stable without the sparc team consent.
porthole-0.5.0 is now in the tree.
Duplicated the crash with 'porthole -d' and opened case 1389660 on sourceforge. There was no output from pycrash. Overall, I like what I am seeing, but would prefer to determine what is causing the segmentation faults before unmasking.
Why is it marked as Hard Masked? Thanks a lot for the information
It is hard masked, because the package is still in testing and I have had segmentation faults occur during my testing. Once the segmentation fault issue is worked out and resolved, I will remove the entry in package.mask
I've narrowed the problem down to the sorting of the treeview. It will segfault if the Dependencies expander is expanded. It seems that if the view is re-sorted by clicking on the column headers it does not segfault. I have not yet determined if it is our coding mistake or a bug in gtk/pygtk.
when will this be stable in X86, i think a 3 months is enough... Does the other arch teams are having problems? Lets try to at least take out the package.mask...
I've eliminated the sorting entirely and the problem persists. It turns out to be a more recent gtk bug in the treeview widget. Short of re-writing that entire section of code to use only one treeview model, I've not been able to prevent the segfault. I do have one more idea to try as a workaround. I'll let you know. Oddly enough, this is the most stable version we have had. Untill you came across this segfault (which only started with recent gtk versions) we had solved all other segfault problems. The version that is not currently hard masked has several areas of code that can produce a segfault with no work around.
The upstream GtkTreeView bug with backtraces are at http://bugzilla.gnome.org/show_bug.cgi?id=343213 .
With http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtktreeview.c?r1=1.556&r2=1.557 porthole no more segfaults when switching views. (Upstream bug http://bugzilla.gnome.org/327164 ) Filed gentoo bug 138703 . Please change this bug so it depends on Bug 138703 .
0.5.0 is in the tree, this could be closed.
(In reply to comment #26) > 0.5.0 is in the tree, this could be closed. It's still open because it's still hardmasked, and it's still hardmasked because of bug #138703 (as mentioned in comment #25). (In reply to comment #25) > Filed gentoo bug 138703 . > Please change this bug so it depends on Bug 138703 . If I'm not mistaken (which is very well possible), you should be able to do that yourself by marking this bug as a blocker for your newer bug report. Anyway, done.
Hmmmm... I never had any problems with porthole-0.5.0...
(In reply to comment #28) > Hmmmm... I never had any problems with porthole-0.5.0... > emerge --info Gentoo Base System version 1.12.5 Portage 2.1.1 (default-linux/x86/2006.1, gcc-3.4.6, glibc-2.4-r3, 2.6.16.29 i686) ================================================================= System uname: 2.6.16.29 i686 AMD Athlon(tm) XP 2600+ Last Sync: Wed, 27 Sep 2006 17:30:08 +0000 distcc[23834] (dcc_trace_version) distcc 2.18.3 i686-pc-linux-gnu; built Sep 26 2006 09:34:59 [disabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.mirror.solnet.ch http://mirror.switch.ch/ftp/mirror/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/myportage/public_html" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext 3ds X a52 aac acpi ada alsa aoss bash-completion berkdb bitmap-fonts bzip2 ccache cjk cli crypt cups dbus dedicated divx4linux dlloader dri dts dv dvd dvdr dvdread edl elibc_glibc encode expat f2c ffmpeg flac fortran gcj gdbm gif gmp gnutls gphoto2 gpm gtk2 haskell imagemagick imblib imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux kqemu ldap libg++ linguas_de linguas_en lirc lirc_devices_igorplugusb live logrotate lzo mad matroska mmx mmxext mng mono motif mozsvg mp3 mp4 mpeg music musicbrainz ncurses network nls nptl nptlonly ogg opengl pam pascal pcre pdf perl png povray ppds pppd python qt qt3 readline reflection rtc scanner sdl session shorten slp sndfile speex spl sqlite sse sse2 ssl svg tcltk tcpd tetex theora threads tidy tiff timidity truetype truetype-fonts type1-fonts udev unicode usb userland_GNU userlocales v4l v4l2 vcd vhosts video_cards_nvidia vorbis wifi win32codecs wxwindows x264 xanim xine xml2 xorg xosd xprint xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
package.mask entry removed. I was unable to get porthole to segfault with the latest stable version of gtk+
