Revelation is a password manager for the GNOME 2 desktop. It organizes accounts in a tree-structure, and stores them as AES-encrypted XML files. I suggest gnome-apps/
Created attachment 24125 [details] Ebuild for revelation 0.1.0 The ebuild itself
ebuild needs proper headers, other then that it looks good.
Created attachment 24224 [details] Revised ebuild Added ebuild headers
Created attachment 24225 [details] Revised ebuild (again) Ahem, fixed the copyright period
very early in development, low priority the ebuild probably should use the gnome2 and/or some python eclass
Created attachment 24367 [details] Ebuild w/ python, gnome2 eclasses Here's an ebuild that inherits python and gnome2 eclasses. Operation is solid; suggest consideration for tree as softmasked ("~x86") unstable package.
read the policy, there is no such thing as 'soft masked' unstable.
Created attachment 24543 [details] Ebuild for Revelation 0.1.1 Updated to latest application release.
Created attachment 26070 [details] Ebuild for Revelation 0.2.0 Updated to latest release
Compiled and run fine (for now) on amd64 architecture. Propose keyword ~amd64 to be added.
Created attachment 28789 [details] Ebuild for version 0.3.0 Updated to latest version
Created attachment 28910 [details] revised ebuild for revelation 0.3.0 the old ebuild tried to write revelation.schemas directly to /etc/gconf/schemas/ (sandbox violation) this ebuild uses python setup.py install --root="${D}" instead of python setup.py install --prefix="${D}/usr" and removes the gconf schema install from setup.py (gnome.eclass should take care of it)
btw if you use "inherit distutils", it does the compiling and installing itself...
Created attachment 37207 [details] revelation-0.3.2.ebuild Cultivating Danny Milosavljevic's suggestion, I made an ebuild for the newly released revelation-0.3.2 by inheriting distutils.eclass. Revelation compiles and runs in my system. :) BTW, I still can't figure out how multiple-inheritance works in (yikes) my own ebuild in such a way that the GConf schemas was installed at "the right time" (i.e. doesn't breach the sandbox).
I suggest putting Revelation in the app-admin/ branch of the Portage tree, along with fpm, kedpm, etc.
Created attachment 37208 [details] revelation-0.3.2.ebuild, new urls and amd64 Thanks, updated URLs to new hostname and added ~amd64 keyword. Since it's written in Python it should run on pretty much anything that Python and GNOME runs on.
Just a few comments, o) RDEPEND="${DEPEND}" is not required, portage will set this for you automatically. o) It looks like this needs libxml2 compiled with USE="python" otherwise the python bindings won't be built during emerge libxml2. Have a look at the gramps ebuild (app-misc/gramps-0.99.ebuild) for a quick pkg_setup to check for the libxml2 python module. o) Lastly, we can't assume it will run on all platforms that gnome and python do, and we can't maintain it on all the platforms without testing and support from the arch teams, so we'll keyword it with more archs later on. Aside from that, the ebuild looks good, is pfeifer going to maintain this?
Created attachment 38084 [details] revelation-0.3.2.ebuild, updated with libxml2 check I modified the ebuild to make sure we have libxml2 that was emerged with `USE='python' emerge libxml2`. I used python_mod_exists(), inherited from python.eclass, instead of the algorithm from the gramps ebuild. I used the comments from the gramps ebuild, though... :p I tested the libxml2 check, by: USE='-python' emerge --verbose --ask libxml2 #which re-merged libxml2, and removed libxml2.py et al from /usr/lib/python${PV}/site-packages emerge revelation-0.3.2.ebuild #fails the check and stopped merging emerge libxml2 revelation-0.3.2.ebuild #works, because I have "python" in make.conf.${USE} Thanks to Mike Gardiner for the suggestion. -Eddy Mulyono
Created attachment 38513 [details] revelation-0.3.3.ebuild Updated to latest application release, and removed $RDEPEND="${DEPEND}"
Created attachment 40566 [details] revelation-0.3.4.ebuild Updated to latest application release
I don't understand why revelation did not make it into portage... I used it for months now (on amd64!!) Even if it's hard masked, now 10 months after original ebuild, may be it could be added ? any reason why not ?
Revelation has been having a few issues (crashes, functional bugs, release mishaps etc) for some time, mostly due to the instability of the code base. Some of the upcoming features I have planned are also likely to introduce new bugs, as they will require large changes to the core code. I would not recommend adding Revelation to portage until the 0.5.x series, when most of the planned features are implemented, and the code base gets a chance to stabilize. Hard-masking it might be an option, though.
*** Bug 70912 has been marked as a duplicate of this bug. ***
Created attachment 50754 [details] ebuild for revelation-0.4.0 Ebuild for latest version - may need some improvement, but it seems to work for me.
for me revelation 0.4.0 gives this on startup: ----- Missing data files Some of Revelations system files could not be found, please reinstall Revelation. ------ nothing changes if I reinstall it.
Hm, you're right. The problem seems to be that portage modifies the ${prefix} variable so that it points to the sandbox root, and not the filesystem root, on install. This is a problem, because the ${prefix} variable is used in a few revelation script files (/usr/bin/revelation and /usr/lib/python2.3/site-packages/config.py). When you start revelation, and it searches for its data files under /var/tmp/portage/revelation-0.4.0/image//usr, things obviously don't work too well. The trick is to get portage to use "make DESTDIR=<virtual-root> install" instead of changing ${prefix}, so that the paths in the script files are correct. But I'm not very familiar with ebuilds, eclasses and that stuff, and I'm way too tired to start figuring it out now, so it'll have to wait a couple of days. (unless, of course, someone else would like to step up :))
Using FEAUTURES="maketest" leads to the following errror: [...] make[3]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/src/lib' make[2]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/src/lib' make[2]: Entering directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/src' sed \ -e "s|\@pythondir\@|/usr/local/lib/python2.3/site-packages|" \ revelation.in > revelation make[2]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/src' make[1]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/src' Making check in test make[1]: Entering directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/test' python config.py -v Traceback (most recent call last): File "config.py", line 28, in ? from revelation import config ImportError: No module named revelation make[1]: *** [check] Error 1 make[1]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/test' make: *** [check-recursive] Error 1 !!! ERROR: gnome-extra/revelation-0.4.0 failed. !!! Function src_test, Line 566, Exitcode 0 !!! Make check failed. See above for details. !!! If you need support, post the topmost build error, NOT this status message. $ emerge info Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-as3 i686) ================================================================= System uname: 2.6.10-as3 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 8 2005, 01:30:18)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.4, 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -fstack-protector -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -fstack-protector -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect distlocks maketest sandbox sfperms test userpriv usersandbox" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ http://mirror.switch.ch/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LANG="de_DE.utf-8" LC_ALL="de_DE.utf-8" MAKEOPTS="-j2 -s" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib acl acpi alsa apache2 bash-completion bitmap-fonts bzlib caca calendar cdr cpdflib crypt cups dvd eds encode esd evo exif fam flac ftp gd gd-external gif gimpprint gnome gstreamer gtk2 gtkhtml hal hbci howl iconv imlib2 ipv6 ithreads jpeg mad mmx mng mono moznocompose moznoirc moznomail mozsvg mpeg mpeg4 mysql ncurses nls nptl nptlonly oggvorbis opengl openssh pam pcre pic png python samba session simplexml sockets spell sqlite sse sse2 ssl svg threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales wmf xmlrpc xv zlib linguas_GER" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
Yeah - I've implemented unit testing of the library in 0.4.0, which is run through "make test". However, the unit tests need to work with an already-installed Revelation library, as I haven't found a sane way to have it work on the just-built libraries instead. It should be fixed sometime during 0.4.x, but I didn't want to delay 0.4.0 any further because of it.
Then it should be disabled in Gentoo, because we can't depend on ourself ;-) so RESTRICT="maketest" would be a good idea
Created attachment 50842 [details] ebuild for revelation-0.4.0, this one actually works This should install correctly. I added RESTRICT="maketest" as well, but it still seems to try to run the unit tests when I use FEATURES="maketest" on the command-line. Have no idea why.
Sorry, but this ebuild is completely crap. It doesn't install *any* binary. Go away with it!
Uhm, yes it does: maas root # qpkg -l revelation | grep bin /usr/bin /usr/bin/revelation maas root # qpkg -f -v /usr/bin/revelation app-crypt/revelation-0.4.0 *
the new ebuild submitted today works for me
Oh, was my fault. I'm really sorry for the flame post. I'm going to shut up now.
I wrote my own ebuild before I found this bug. I used: G2CONF="${G2CONF} --datadir=${D}/usr/share" instead of the src_compile stuff. This way, you get the mime database stuff, and the things we were disabling till now. I don't know if this is the best way to handle it. Thoughts?
This is what currently happens: the source is compiled normally, but generation of the MIME database is disabled - this is because the database rebuild tries to update the system database under /usr/share (outside the build-root). The gnome2 eclass will automatically update the system mime database after the files have been installed, so everything will work as expected anyways. Your suggestion will generate the MIME database under the build-root. This is unnecessary, since the generated MIME database won't be useful - it will only contain info about the Revelation MIME type, and if installed it will replace all existing MIME info. That's why the gnome2.eclass removes any generated mime database, and then rebuilds the system database with the installed files. So to recap: the existing method doesn't build the mime database, it gets generated automatically by the gnome2 eclass. Your suggestion will build the mime-database, which will then be removed by the gnome2 eclass, and then be regenerated. The end result is the same, I just don't see the point in doing an unnecessary step. However, I don't know if your suggestion have any other side-benefits (or if the existing method has any drawbacks), I don't really know too much about ebuilds. Anyone?
I just tried to install Revelation using the v0.4.0 (this one actually works) ebuild above. The ebuild fails with sandbox violations. GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL is set, not installing schemas /usr/bin/update-desktop-database ACCESS DENIED rename: /usr/share/applications/.mimeinfo.cache.ws6yKU ACCESS DENIED unlink: /usr/share/applications/.mimeinfo.cache.ws6yKU No directories in update-desktop-database search path could be processed and updated. make[4]: *** [install-data-hook] Error 1 make[4]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/data' make[3]: *** [install-data-am] Error 2 make[3]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/data' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/data' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/revelation-0.4.0/work/revelation-0.4.0/data' make: *** [install-recursive] Error 1 man: prepallstrip: strip: strip --strip-unneeded >>> Completed installing revelation-0.4.0 into /var/tmp/portage/revelation-0.4.0/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-app-admin_-_revelation-0.4.0-6966.log" rename: /usr/share/applications/.mimeinfo.cache.ws6yKU unlink: /usr/share/applications/.mimeinfo.cache.ws6yKU -------------------------------------------------------------------------------- Any thoughts?
I have a problem running revelation with the 0.4.0 ebuild, i get the following Am i missing a dependency or is there a another problem? Any ideas appreciated. Traceback (most recent call last): File "/usr/bin/revelation", line 1267, in ? app = Revelation() File "/usr/bin/revelation", line 52, in __init__ self.__init_facilities() File "/usr/bin/revelation", line 78, in __init_facilities self.items = ui.ItemFactory(self) File "/usr/lib/python2.3/site-packages/revelation/ui.py", line 1101, in __init__ self.__init_entryicons() File "/usr/lib/python2.3/site-packages/revelation/ui.py", line 1124, in __init_entryicons self.load_stock_icon(id, name, ( gtk.ICON_SIZE_MENU, ICON_SIZE_DATAVIEW, ICON_SIZE_DROPDOWN, ICON_SIZE_TREEVIEW )) File "/usr/lib/python2.3/site-packages/revelation/ui.py", line 1184, in load_stock_icon pixbuf = self.theme.load_icon(icon, pixelsize, 0) GError: Icon 'gnome-fs-directory' not present in theme
It's a known bug - I'll look into it for 0.4.1. It's related to your GNOME icon theme, you could try using a different theme. Thanks for the report.
Thanks, after a sugestion from Erik i changed theme and this worked, finaly got it running.
Created attachment 54075 [details] revelation-0.4.1.ebuild Updated ebuild to latest release
Just compiled revelation from source before I checked bugzilla. I'm running with ~x86 keyword and had cracklib-2.8.2 installed. When I ran ./configure it would fail due to cracklib-2.8.2 missing the mkdict command. I had to downgrade to cracklib-2.7-r11 in order for ./configure to work, and I was then able to compile and install without any other problems.
Created attachment 54215 [details] ebuild for revelation-0.4.2 Upgraded to new app version, which works with pygtk 2.4. This also depends on <sys-libs/cracklib-2.8. It seems like cracklib 2.8 uses new names for the dictionary generation programs. I have fixed this in the revelation svn repository, and will release a new version with the fix in a week or so. Thanks for letting me know.
Created attachment 54939 [details] revelation-0.4.3.ebuild New app version
Tested on AMD64. vesion 0.43 compiles fine. (upgrade from 0.30) Small "bug", it hangs on startup because of missing icon. Traceback (most recent call last): File "/usr/bin/revelation", line 1359, in ? app = Revelation() File "/usr/bin/revelation", line 52, in __init__ self.__init_ui() File "/usr/bin/revelation", line 157, in __init_ui gtk.window_set_default_icon_list( File "/usr/lib/python2.3/site-packages/revelation/ui.py", line 1258, in load_icon return self.theme.load_icon(id, size, 0) GError: Icon 'revelation' not present in theme I copied /usr/share/icons/hicolor/48x48/apps/revelation.png into my current theme /usr/share/icons/Bluecurve/48x48/apps/ to solve it... Now works fine.
Thanks, fixed in svn. May be a bug in Bluecurve as well, as I thought all GNOME themes were supposed to inherit from hicolor.
I just want to put a little note in this bug for those who wonder why it is not in portage. The reason is directly related to comment #22 as stated by the author. If Erik feels it is ready @ 0.4.3 stage, I would put it in portage after some testing. However, since he made the comments it was really not ready until 0.5.x, I wasn't going to do anything until said time. Jay
I recommended waiting until 0.5.0, but there is alot of work to be done before version 0.5.0 (most notably, design and implementation of a new file format and data model). This work will probably take a few months, and as I'm going on a 6-month trip to Asia this fall, version 0.5.0 probably won't be out until spring 2006. Since I'm going away for so long, I won't implement more than a few new features in the next 0.4.x releases, and instead focus on bug-fixes - since I obviously can't do any hacking in the jungle, I'll try to make sure it's relatively bug-free before I leave for Asia. It should be fine to include it in Portage when I release 0.4.4 (hopefully within a few weeks), any remaining issues should be fixed within a couple of months.
Created attachment 65301 [details] Ebuild for revelation-0.4.4 Updated to latest release, should be fine for inclusion in portage. Enjoy! ps: it only actually needs gnome-python-extras if using gnome-python >=2.10.0, but I'm not sure how to do conditional dependencies based on versions.
The attached ebuild is not quite perfect. Sometimes it's necessary to create the applets.defs file and revelation comes now with an panel-applet. So we need gnome-panel as a dependency.
Created attachment 65602 [details] revelation-0.4.4.ebuild Added gnome-panel dependency, thanks
Created attachment 66871 [details] revelation-0.4.5.ebuild
Updated to latest release
merging fails with the last ebuild ( didn't try the old ones ), i get this error during configure execution : checking python module bonobo.ui... no although it works using the source tar.gz and using exactly the same configure arguments passed by emerge, seems to be an environment problem ? should i include the config.log ?
This is probably because you don't have X running - the bonobo.ui module loads the gtk module, which requires X to run. Requiring X to build Revelation is of course completely silly, but it was a mistake on my part. Either build Revelation with X running, or apply the patch in this mail: http://oss.codepoet.no/pipermail/revelation-list/2005-August/000131.html (it would be great if someone would include this patch with the ebuild - I can't fix it myself as I'm writing this from an internet-cafe in Tokyo and will spend the next 6 months travelling around Asia)
Created attachment 69961 [details] revelation-0.4.5.ebuild ebuild that fixes bonobo.ui configure bug.
Created attachment 69962 [details, diff] revelation-bobobo.ui-fix.patch And the patch from the mentioned e-mail in prtage friendly format.
Created attachment 78237 [details] revelation-0.4.6.ebuild Ebuild for new version, released today. Removed gnome-panel from DEPEND since gnome-python-extras depends on it. General fixes.
Mr. Grinaker: Is Revelation ready for Portage yet? I've been copying the ebuild to my overlay for two years now :) BTW, one small suggestion: please include the dependencies and their version numbers in the documentation that comes with the revelation source.
I don't see any reason why Revelation shouldn't be put in Portage. It is still beta-grade though (until version 1.0.0), but getting better all the time. I'll add info on dependencies to the README-file, thanks.
Created attachment 79081 [details] revelation-0.4.7.ebuild Another new version. -Removed more of gnome-python-extras' DEPENDs -dodoc README
chris@hqws0021 ~ $ LC_ALL=C revelation /usr/lib/python2.4/site-packages/gtk-2.0/gnome/applet.py:4: DeprecationWarning: Module gnome.applet is deprecated; please import gnomeapplet instead DeprecationWarning) Traceback (most recent call last): File "/usr/bin/revelation", line 1494, in ? app = Revelation() File "/usr/bin/revelation", line 51, in __init__ self.__init_facilities() File "/usr/bin/revelation", line 77, in __init_facilities self.items = ui.ItemFactory(self) File "/usr/lib/python2.4/site-packages/revelation/ui.py", line 1239, in __init__ self.__init_entryicons() File "/usr/lib/python2.4/site-packages/revelation/ui.py", line 1270, in __init_entryicons self.load_stock_icon(id, name, ( gtk.ICON_SIZE_MENU, ICON_SIZE_DATAVIEW, ICON_SIZE_DROPDOWN, ICON_SIZE_TREEVIEW )) File "/usr/lib/python2.4/site-packages/revelation/ui.py", line 1353, in load_stock_icon pixbuf = self.load_icon(icon, pixelsize) File "/usr/lib/python2.4/site-packages/revelation/ui.py", line 1332, in load_icon pixbuf = self.theme.load_icon(id, size, 0) GError: Icon 'stock_creditcard' not present in theme any hints where this can come from? Fibbs
above fixed by downgrading from hicolor-icon-theme-0.9 to 0.8 Seems there is a bug in 0.9.
ok, let me look @ 0.4.7 and then if all is well, i'll add it portage.
This package must depend on gnome-python-desktop. emerge =revelation-0.4.6: [In configure] if i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"revelation\" -DVERSION=\"0.4.7\" -DHAVE_LIBCRACK=1 -DHAVE_REQUEST_FOCUS=1 -I. -I. `pkg-config --cflags gtk+-2.0 pygtk-2.0 libgnomeui-2.0 gnome-vfs-2.0 gnome-keyring-1 libpanelapplet-2.0` -fPIC -I/usr/include/python2.4 -I. -O2 -march=pentium-m -mtune=pentium-m -pipe -MT gnomemiscmodule.o -MD -MP -MF ".deps/gnomemiscmodule.Tpo" -c -o gnomemiscmodule.o gnomemiscmodule.c; \ then mv -f ".deps/gnomemiscmodule.Tpo" ".deps/gnomemiscmodule.Po"; else rm -f ".deps/gnomemiscmodule.Tpo"; exit 1; fi Traceback (most recent call last): File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1261, in ? sys.exit(main(sys.argv)) File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1224, in main p.startParsing() File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing for statement in statements: File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 28, in parse fp = open(filename, 'r') IOError: [Errno 2] No such file or directory: '/usr/share/pygtk/2.0/defs/applet.defs'
Could somebody please change the summary of this bug to revelation-0.4.7.ebuild (New package) ? And it would of course be fantastic, if revelation would make it into portage :) BTW: QA Notice: USE Flag 'doc' not in IUSE for app-admin/revelation-0.4.7
phobos revelation # ebuild *.ebuild digest >>> Downloading http://distfiles.gentoo.org/distfiles/revelation-0.4.7.tar.bz2 --20:19:41-- http://distfiles.gentoo.org/distfiles/revelation-0.4.7.tar.bz2 => `/usr/portage/distfiles/revelation-0.4.7.tar.bz2' Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135 Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected. HTTP request sent, awaiting response... 404 Not Found 20:19:41 ERROR 404: Not Found. No digest file available and download failed. >>> Downloading http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/revelation-0.4.7.tar.bz2 --20:19:41-- http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/revelation-0.4.7.tar.bz2 => `/usr/portage/distfiles/revelation-0.4.7.tar.bz2' Resolving distro.ibiblio.org... 152.2.210.109 Connecting to distro.ibiblio.org|152.2.210.109|:80... connected. HTTP request sent, awaiting response... 404 Not Found 20:19:43 ERROR 404: Not Found. No digest file available and download failed. >>> Downloading ftp://oss.codepoet.no/revelation/revelation-0.4.7.tar.bz2 --20:19:43-- ftp://oss.codepoet.no/revelation/revelation-0.4.7.tar.bz2 => `/usr/portage/distfiles/revelation-0.4.7.tar.bz2' Resolving oss.codepoet.no... 207.210.65.201 Connecting to oss.codepoet.no|207.210.65.201|:21... failed: Connection refused. No digest file available and download failed. !!! Couldn't download revelation-0.4.7.tar.bz2. Aborting.
Google. http://jkp-se.lunar-linux.org/lunar/cache/revelation-0.4.7.tar.bz2
The new 0.4.7 ebuild works well here.
works fine, thx.
I upgrade from gnome 2.12 to 2.14 and try emerge revelation 0.4.7, but het error during emerge process. i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -fPIC -I/usr/include/python2.4 -c crack.c -o crack.o i686-pc-linux-gnu-gcc -Wl --export-dynamic -pthread -shared crack.o -lcrack -o crack.so make[3]: Leaving directory `/var/tmp/portage/revelation-0.4.7/work/revelation-0.4.7/src/wrap/crack' Making all in gnomemisc make[3]: Entering directory `/var/tmp/portage/revelation-0.4.7/work/revelation-0.4.7/src/wrap/gnomemisc' /usr/bin/pygtk-codegen-2.0 --prefix gnomemisc \ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"revelation\" -DVERSION=\"0.4.7\" -DHAVE_LIBCRACK=1 -DHAVE_REQUEST_FOCUS=1 \ --register /usr/share/pygtk/2.0/defs/applet.defs \ --register /usr/share/pygtk/2.0/defs/bonobo-types.defs \ --override gnomemisc.override \ gnomemisc.defs > gnomemisc.c if i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"revelation\" -DVERSION=\"0.4.7\" -DHAVE_LIBCRACK=1 -DHAVE_REQUEST_FOCUS=1 -I. -I. `pkg-config --cflags gtk+-2.0 pygtk-2.0 libgnomeui-2.0 gnome-vfs-2.0 gnome-keyring-1 libpanelapplet-2.0` -fPIC -I/usr/include/python2.4 -I. -O2 -march=i686 -pipe -fomit-frame-pointer -MT gnomemiscmodule.o -MD -MP -MF ".deps/gnomemiscmodule.Tpo" -c -o gnomemiscmodule.o gnomemiscmodule.c; \ then mv -f ".deps/gnomemiscmodule.Tpo" ".deps/gnomemiscmodule.Po"; else rm -f ".deps/gnomemiscmodule.Tpo"; exit 1; fi Traceback (most recent call last): File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1261, in ? sys.exit(main(sys.argv)) File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1224, in main p.startParsing() File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing for statement in statements: File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 28, in parse fp = open(filename, 'r') IOError: [Errno 2] No such file or directory: '/usr/share/pygtk/2.0/defs/applet.defs' make[3]: *** [gnomemisc.c] Ошибка 1 make[3]: *** Ожидание завершения заданий... make[3]: Leaving directory `/var/tmp/portage/revelation-0.4.7/work/revelation-0.4.7/src/wrap/gnomemisc' make[2]: *** [all-recursive] Ошибка 1 make[2]: Leaving directory `/var/tmp/portage/revelation-0.4.7/work/revelation-0.4.7/src/wrap' make[1]: *** [all-recursive] Ошибка 1 make[1]: Leaving directory `/var/tmp/portage/revelation-0.4.7/work/revelation-0.4.7/src' make: *** [all-recursive] Ошибка 1 !!! ERROR: app-crypt/revelation-0.4.7 failed. !!! Function gnome2_src_compile, Line 58, Exitcode 2 !!! compile failure !!! If you need support, post the topmost build error, NOT this status message.
Created attachment 90325 [details] revelation-0.4.7-r1.ebuild Updated to work with gnome-python-desktop, requires >=gnome-2.14.
pfeifer: Waiting until 0.5 to put this in ~arch is understandable, but please at least put the current ebuild in Portage and package.mask it. I'm sure I'm not the only one who would like to use/test this app even before it's deemed ready for primetime. The current ebuild works and the app plays nicely with the system so there's really no need to keep it locked up in Bugzilla.
revelation 0.4.7 does have a problem with gnome-2.16. It just crashes if I try to select an item in my database: /usr/lib/python2.4/site-packages/gtk-2.0/gnome/applet.py:4: DeprecationWarning: Module gnome.applet is deprecated; please import gnomeapplet instead DeprecationWarning) /usr/lib/python2.4/site-packages/revelation/data.py:400: GtkWarning: gtk_tree_st ore_get_value: assertion `VALID_ITER (iter, tree_store)' failed e = self.get_value(iter, COLUMN_ENTRY) Traceback (most recent call last): File "/usr/bin/revelation", line 266, in <lambda> self.tree.selection.connect("changed", lambda w: self.__state_entry(self.tre e.get_selected())) File "/usr/bin/revelation", line 305, in __state_entry e = self.entrystore.get_entry(iter) File "/usr/lib/python2.4/site-packages/revelation/data.py", line 400, in get_e ntry e = self.get_value(iter, COLUMN_ENTRY) File "/usr/lib/python2.4/warnings.py", line 61, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.4/warnings.py", line 82, in warn_explicit for item in filters: TypeError: unknown type (null)
Please report that here http://oss.codepoet.no/revelation/bugs/
It's a bug in pygtk which should be fixed in the next version. bug 148247
(In reply to comment #73) > pfeifer: Waiting until 0.5 to put this in ~arch is understandable, but please > at least put the current ebuild in Portage and package.mask it. I'm sure I'm > not the only one who would like to use/test this app even before it's deemed > ready for primetime. The current ebuild works and the app plays nicely with the > system so there's really no need to keep it locked up in Bugzilla. > I completely agree. I've been waiting for revelation to be added to the portage tree for almost a year. Funny enough, I've come across this bug to get it added and started to comment only to find I could not find where I had written down my bugs.gentoo.org user/pass. I found that to be quite ironic. I'm running revelation 0.4.7 as ~amd64 and its working great. No problems, though I had to add ~amd64 to the ebuild to get it to compile... Thanks to those that care to see this great program in the portage tree! We shouldn't have to use an overlay to get revelation ;)
Created attachment 104840 [details] revelation-0.4.7.ebuild I'll take this one if no one else is going to. Here's the ebuild I've been using.
Fixed! Thanks everyone.
