seahorse-0.8.1.ebuild works for 0.9.0 without any changes.
Gnome peoples - interested in retaking over the stable branch?
seahorse 0.9.1 is out. Both 0.9.0 and 0.9.1 don't compile for me with just renaming the ebuild. Getting the following issue. No time to look into it. make[3]: *** No rule to make target `../libseahorse/libseahorse-internal.la', needed by `seahorse-ssh-askpass'. Stop.
I had exactly the same problem as comment #2 with MAKEOPTS="-j2" in my make.conf, then it compiled fine with MAKEOPTS="-j1" (this is not the first package with this kind of behavior...)
Guillaume - please report parallel make problems. FYI i'm hoping to phase out my support of seahorse unstable branch especially with 0.8.1 going stable (bug 130624).
Created attachment 88883 [details, diff] Patch for 0.9.1 ebuild This patch migth wrong but it includes modifications related to new features in 0.9.1 : http://sourceforge.net/mailarchive/forum.php?thread_id=10179444&forum_id=4102 There was a QA notice about the doc flag not being present, but I'm not sure of what to do about it. It compiled without any problems for me. I executed it and played around with signing, encryption plugin for gedit and all. Please test and add it to the tree as unstable.
Whatever You do here, please remember that this is a testing/development version.
Is it possible to filter MAKEOPTS? I had this problem with -j>1. With and without ssh flag.
Created attachment 98079 [details] seahorse-0.9.5.ebuild Adding autoreconf and _elibtoolize-macros to make it compile with on x64-architectures, added MAKEOPTS=-j1
Created attachment 98091 [details] seahorse-0.9.5.ebuild Still lots of assert errors. But it compiles. Cleaned up previous ebuild. LDAP support is broken. Get error about invalid URI for ldap. Had to delete LDAP entry. Crashes on exit in some situations. Generally very slow. Not tree ready IMHO.
0.8.2 is out in the stable branch, according to my list at http://dev.gentoo.org/~leio/gnome/ftp-status.html
Yep. But I thought this bug tracked the unstable testing version?
Created attachment 99989 [details] patch fixes crash in ssh-agent for 0.9.5 Pulled from Ubuntu Edgy, I'm using an ebuild from the break-my-gentoo overlay, so I'll let you add this to the ebuild here as it differs from mine
Created attachment 103131 [details] seahorse-0.9.7.ebuild This is my ebuild for 0.9.7, the software is still very slow but it compiles and install fine.
Hello, Need to version bump, or fix the app-crypt/gnupg dependency in order to allow gpg-2.X series. Thanks!
Comment #14: See bug #159623. They are re-slotting gnupg.
0.9.9 is out since end of December, so adjusting the summary
(In reply to comment #15) > Comment #14: > > See bug #159623. They are re-slotting gnupg. I am from bug#159623... Do you have a problem with the newer gnupg? Have you tried it with recent seahorse releases? I don't think we are going to slot gnupg.
Even in build 0.9.9 (check gentopia overlay), configure script still checks for a >gnupg-2
Created attachment 105236 [details, diff] seahorse-0.9.9-gpg2.patch It checks only for 1.2 for special case. Please try the above patch to accept 2.0.
Alon, Please stop trying to avoid the issue here. There are other reasons beyond just seahorse to slot gnupg. As stated by upstream, it has been designed as such. Please put an end to this, it's getting a bit out of control on a minor issue. Having one extra ebuild around or a slot isn't going to kill anyone or hurt anything. For the problems it would fix, not to mention flexibility for end users, which is part of the point behind Gentoo. It needs to be done, please.
This does not belong to this bug... but... (In reply to comment #20) > As stated by upstream, it has been designed as such. No it doesn't... They renamed the executables to gpg2 and gpgv2, so current applications will not be able to use gpg if gpg-1.X series is not installed. In order to make it work, we can just link the gpg->gpg2, gpgv->gpgv2 and solve the issue, or we can start playing with virtual/gnupg and eselect modules, which is much more complicated to user than adding a simple line to package.mask (>=app-crypt/gnupg-2.0.0) if the user wish to use the 1.4 series. > Please put an end to this, it's getting a bit out of control on a minor > issue. That's right. This is a minor issue... And nobody has found a good reason why a user should install BOTH versions at THE SAME time. > Having one extra ebuild around or a slot isn't going to kill anyone or > hurt anything. For the problems it would fix, not to mention flexibility for > end users, which is part of the point behind Gentoo. It needs to be done, > please. The most stable gnupg-1.X will NOT be removed from tree. Every user WILL be able to install it if he does not wish to upgrade to 2.X series, as with any other version upgrade. Nothing behind Gentoo is ideas is damanged. But please comment in the appropriate bug (bug#159623). Regards,
Created attachment 106001 [details, diff] Patch to fix check in seahorse-deamon startup This patch fixes a small problem in a header that made seahorse-daemon fail upon startup when trying to read options from command line. Please note that the other provided patch for gpg2 support didn't subsitute correctly the $major and $minor values in the configure-generated config.h file. Please the author fix that. Thanks, matteo
(In reply to comment #22) > Please note that the other provided patch for gpg2 support didn't subsitute > correctly the $major and $minor values in the configure-generated config.h > file. Please the author fix that. Why do you thing it is important? 1. config.h will be overwritten during configure 2. config.h will be overwritten during eautoreconf
filed a bug upstream at http://bugzilla.gnome.org/show_bug.cgi?id=404081
Created attachment 109044 [details] seahorse-0.9.10.ebuild ebuild that works with patches posted upstream. Those patches are a little rework of those that have been attached to this bug.
Ok, my bug was to late, this is the good bug report : http://bugzilla.gnome.org/show_bug.cgi?id=375062
Just an FYI, there is a working version of seahorse 0.9.x in the gentopia overlay. Please use that as that is the version that will go into portage once seahorse is stable.
Saleem, since you mentionned it here I thought it would interest you. There is little typo in your ebuild pkg_config should be changed pkg_setup or seahorse configure won't get the options the user wants. I also have a patch I've posted upstream for MAKEOPTS>-j1. Would you like to get it or just wait for the next release ?
Created attachment 113346 [details] seahorse-1.0.ebuild Seems to work...
Hi all, I've modified the ebuild deleting the epiphany dependency because I use gnome-light without epiphany (and i don't want it installed, i dont' need it). it works well. So, is it possible to put epiphany as USE flag? Thanks a lot, tek
compnerd: Thanks for adding this ebuild... But why not closing this bug? Also you did not add the gnupg detection fixup from the ebuild at attachment#113346 [details]. src_unpack() { gnome2_src_unpack sed -i 's/accepted_versions="1.2 1.4"/accepted_versions="1.2 1.4 2.0"/' configure.in AT_M4DIR="m4" eautoreconf } Note that you can sed configure also so autoreconf is not necessary. But please add this fixup, thanks!
Seems that seahorse-1.0 requires gnupg-1.4* or gnupg-1.2* but latest gpgme requires >=gnupg-1.9.20-r1. This causes a 'emerge -Du world' to fail because all 3 versions of gnupg are in the same slot and therefore can't be installed simultaneously. A possible work-around is to unmerge >=gnupg-1.4* and then 'emerge -u world' (assuming seahorse is in the world file, but gnupg and gpgme aren't), but this might be undesirable for those who have already migrated to gnupg-2.x.
(In reply to comment #32) > Seems that seahorse-1.0 requires gnupg-1.4* or gnupg-1.2* but latest gpgme > requires >=gnupg-1.9.20-r1. This causes a 'emerge -Du world' to fail because > all 3 versions of gnupg are in the same slot and therefore can't be installed > simultaneously. If you work with stable gnupg then you get: gnupg-1.4.6 gnupg-1.9.21 If you work with unstable then you should migrate to latest: gnupg-2.0.3 So I don't see where the conflict is... Can you please explain little more? > A possible work-around is to unmerge >=gnupg-1.4* and then 'emerge -u world' > (assuming seahorse is in the world file, but gnupg and gpgme aren't), but this > might be undesirable for those who have already migrated to gnupg-2.x. People who migrated to gnupg-2.X should have no problem, provided that the fixup from comment#31 is applied.
Ok, prior to syncing portage I had gnupg-2.0.3, gpgme-1.1.4, and seahorse-0.8.2 installed. I did an 'emerge --sync' and then 'emerge -DuvaN world' and I got: !!! Multiple versions within a single package slot have been !!! pulled into the dependency graph: ('ebuild', '/', 'app-crypt/gnupg-1.4.7', 'nomerge') pulled in by ('ebuild', '/', 'app-crypt/seahorse-1.0', 'nomerge') ('ebuild', '/', 'app-crypt/gnupg-2.0.3', 'merge') pulled in by ('ebuild', '/', 'app-crypt/gpgme-1.1.4', 'nomerge') Looking at the ebuilds, it appears that seahorse-1.0 depends on gnupg-1.4* or gnupg-1.2* however gpgme-1.1.4 depends on >=gnupg-1.9.20-r1. gnupg-1.4.7 satisties the first dependency, and gnupg-2.0.3 satisfies the second. However, gnupg-2.0.3 and gnupg-1.4.* are all SLOT=0 (gnupg-1.2* doesn't exist at all in portage) therefore they cannot coexist. The only way I could satisfy all dependencies is to replace gnupg-2.0* with gnupg-1.4.7 and do an 'emerge -u' instead of 'emerge -Du' although clearly that's not an appropriate solution.
(In reply to comment #34) > Ok, prior to syncing portage I had gnupg-2.0.3, gpgme-1.1.4, and seahorse-0.8.2 You are right! compnerd did not take the ebuild from this bug at all... Or just ignored it. You should have: || ( =app-crypt/gnupg-1.4* >=app-crypt/gnupg-2.0.1-r2 ) In dependency. Well... Too many differences between the committed ebuild and the attached one. As I am not the maintainer nor a user of this package, all I ask is to make the fixups needed for dependency and detection of gnupg-2.X.
Any news on changing the DEPEND line to allow for the latest version of gnupg? I've had no problems with the gnome-experimental version (0.9.92-r1). I can open a separate bug if you'd like to close this one...
Well, I am going to close this bug, I had forgotten to do so. The reason that I have not applied the mentioned change to allow for GPG 2 is because upstream decided to remove GPG 2.x support when they did the release.
It works even to upstream. But since there is ANOTHER issue, as people get confused at bug#164523, it decided to play it safe. Upstream developer is working with gpg2 without any problem, see: http://bugzilla.gnome.org/show_bug.cgi?id=375062#c25 I also get reports of other people who are working correctly with gnupg-2, for example: http://bugs.gentoo.org/show_bug.cgi?id=172331#c6 Please add the gnupg-2 dependency.
no it doesn't work. At least not entirely and upstream acknowlegdes it. Please see http://sourceforge.net/mailarchive/forum.php?thread_name=1174765646.12335.11.camel%40su.perronet.esiee.net&forum_name=seahorse-devel http://sourceforge.net/mailarchive/forum.php?thread_name=8298be230703061235x46d20e29p52b0ef11e587c931%40mail.gmail.com&forum_name=seahorse-devel
Both of these are environment related issue and *NOT* a problem with the interface seahorse as gpg-agent replacement. People who like to use gpg2 can use seahorse, by setting the GPG_AGENT_INFO correctly. I don't see any reason why not allowing user to have a working environment. Of course, some gnome developer or user may help understanding how to set an environment with GPG_AGENT_INFO set to all sessions in Gentoo distribution... But it is not seem that anyone is interested in making this work. gnome: You can close this bug and ignore bug#164523... Only users loses.
Maybe you misread but what is written is that gnupg2 interaction with gpgme is _broken_. It doesn't allow proper passphrase caching. This is not a gnome nor a seahorse problem, it is a gpgme+gnupg2 problem. It's all in the hands of gnupg devs.
Is it this issue or are there more? https://bugs.g10code.com/gnupg/issue772
Created attachment 122822 [details, diff] seahorse-1.0.1.ebuild.diff Should be diff against current.
seahorse 2.20 will support gpg2, this will happen with the gnome 2.20 push into portage.
