Hi, I'm one of the developers of the Avant Window Navigator dock. We just released version 0.2.4. A number of the dependencies have changed, but we have been working with the desktop-effects overlay to have an ebuild that keeps track of the new dependencies. Please look at their live ebuild to update the DEPENDs and RDEPENDs, in addition to the new USE flags. http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=tree;f=gnome-extra/avant-window-navigator;hb=HEAD Thanks!
Forgot to mention that we released 0.2.6 a while ago to address some build issues.
does it really need to depend on libgmail?! I do actually use gmail, but it's forwarded to my regular mailbox, so I surely don't need it. Atleast have it done via a useflag :)
(In reply to comment #2) > does it really need to depend on libgmail?! I do actually use gmail, but it's > forwarded to my regular mailbox, so I surely don't need it. > > Atleast have it done via a useflag :) > libgmail is not a dependency anymore, due to the fact that it's broken with the new Gmail 2.0.
Created attachment 146254 [details] avant-window-navigator-0.2.6.ebuild Here's an updated ebuild for 0.2.6.
(In reply to comment #4) > Created an attachment (id=146254) [edit] > avant-window-navigator-0.2.6.ebuild > > Here's an updated ebuild for 0.2.6. > I have some questions/criticisms about this: * The HOMEPAGE and SRC_URI are https:, not http: * pyxdg is an RDEPEND, I think. * py-compile handling: that looks rather ugly. Is that how other packages handle it? * USE=vala should be removed, because vala isn't in portage (yet). (As a side note, vala support was temporarily disabled for awn-extras-0.2.6 due to dist problems - it works fine in trunk, though.) * need to add CCPL-Attribution-ShareAlike-3.0 to LICENSE (images are CC-licensed) * it seems a little odd that you're DEPENDing on dev-libs/glib when USE=-gnome, when it's already an implied dependency of pygtk, dbus-glib, etc.
(In reply to comment #5) > * it seems a little odd that you're DEPENDing on dev-libs/glib when > USE=-gnome, when it's already an implied dependency of pygtk, dbus-glib, etc. {R,}DEPEND should be based on what the configure.ac (or whatever script) needs. If it specifically checks for glib, then it should be added as a direct dep (even if it seems silly)
(In reply to comment #5) > I have some questions/criticisms about this: > * The HOMEPAGE and SRC_URI are https:, not http: I just followed the original awn ebuilds in portage wrt to this. > * pyxdg is an RDEPEND, I think. Not according to configure.in. > * py-compile handling: that looks rather ugly. Is that how other packages > handle it? Yes, or at least the ones I've seen. Again, a direct copy from the ebuild in portage. > * USE=vala should be removed, because vala isn't in portage (yet). (As a side > note, vala support was temporarily disabled for awn-extras-0.2.6 due to dist > problems - it works fine in trunk, though.) > * need to add CCPL-Attribution-ShareAlike-3.0 to LICENSE (images are > CC-licensed) I have only checked the distributed COPYING* files; they list the GPL and LGPL. > * it seems a little odd that you're DEPENDing on dev-libs/glib when > USE=-gnome, when it's already an implied dependency of pygtk, dbus-glib, etc. Configure.in explicitly checks for glib-2.0. See also Rémi's comment. I will upload an updated ebuild soon.
Created attachment 146298 [details] avant-window-navigator-0.2.6.ebuild Updated ebuild. This fixes the HOMEPAGE and SRC_URI fields and disables the vala support. It also adds a DEPEND on dev-util/pkgconfig (see #206433). I couldn't find any mention of the "CCPL-Attribution-ShareAlike-3.0" licence in the source tree. This means that all I have to go by is a note on the awn launchpad page. Is this even applicable to 0.2.6? I don't know Gentoo policy for situations like this.
(In reply to comment #8) > I couldn't find any mention of the "CCPL-Attribution-ShareAlike-3.0" licence in > the source tree. This means that all I have to go by is a note on the awn > launchpad page. Is this even applicable to 0.2.6? I don't know Gentoo policy > for situations like this. It's in the debian/ folder. Not being in the toplevel folder is an oversight. The SVG files are explicitly labeled as CC-BY-SA-3.0 (unported), so in my opinion, not having it listed in the LICENSE variable would be a bad thing.
(In reply to comment #7) > (In reply to comment #5) > > * pyxdg is an RDEPEND, I think. > Not according to configure.in. Well...I would actually append the flag --disable-pymod-checks and make pyxdg an RDEPEND, because checking for the existence of python modules means doing an "python -c 'import foo'"...which has the possibility of touching files outside the sandbox. The package manager is already doing the dependency work, anyway.
(In reply to comment #9) > It's in the debian/ folder. Not being in the toplevel folder is an oversight. > The SVG files are explicitly labeled as CC-BY-SA-3.0 (unported), so in my > opinion, not having it listed in the LICENSE variable would be a bad thing. awn-0.2.6 doesn't have a debian folder in the source tarball; it exists only in bzr. While I understand how these files are licensed under the CC-BY-SA-3.0 I can find no files in the source tarball that make note of this. I would like to know about Gentoo policy wrt this. The pymod-checks cause an access violation for awn-extras which is why I've disabled them in the ebuild I posted to bug #210835. Since they do not cause such a violation for awn I see no reason to disable them here. However, if somebody wants to disable them pre-emptively I'm all game. Either way, in the most recent ebuild pyxdg is an RDEPEND, as well as a DEPEND because of DEPEND="${RDEPEND}".
(In reply to comment #11) > awn-0.2.6 doesn't have a debian folder in the source tarball; it exists only in > bzr. While I understand how these files are licensed under the CC-BY-SA-3.0 I > can find no files in the source tarball that make note of this. > I would like to know about Gentoo policy wrt this. Easy : use the license of whatever material you're installing. If the released tarballs don't have CC-BY-SA material, then no need to add it. Period.
*** Bug 214466 has been marked as a duplicate of this bug. ***
Sorry for the delay. I was waiting on some deps to hit the main tree before I did the bump. Most of them are there, on gvfs is presently pmasked. I went ahead and committed what I had. I had already merged in changes from the one in the overlay. However I see some stuff in the ebuild above not in mine. I will have to review the differences, and in the mean time patches are welcome. Please do not attach entire ebuilds to bugs. Instead please provide a patch against the last version in tree for any revision bumps or changes. Helps to make changes clearer, easier integration, and smaller stuff stored in bugzilla :) Thanks. Also since I decided to buy another ATI card to help out with ati-driver maintenance. I have lost composite ability in X :( Along with stability all around and other things. So I can no longer test this ebuild running wise. Nor am I presently able to use awn :( Which really sucks because I like it allot. Now on to the extras ebuild.
- dev-python/pyxdg is not an RDEPEND but a DEPEND if --disable-pymod-checks is not passed - see also the discussion in this bug. - you should *really* have a second look at your deps; they are in my ebuild. I read through the configure script to get to them; I didn't add them just for the heck of it. - the urls are https instead of http - see also the discussion in this bug. See also my comments to #210835.
Also, have a look at the --enable-gtk-doc switch and gtk-doc dep for building libawn documentation. I included it in my ebuild.
Sorry for the additional comments, but I forgot: - gtk-doc should be a *conditional* dep; again, look at my ebuild.
If it was a patch the differences would be easier to spot and apply. :) FYI I had started to bump the ebuild in tree to 2.4, but was side tracked and didn't get a chance to resume. At that time I was merging in changes from the live ebuild in an overlay. So I was looking yours over today as I was about to commit the one I had and applying some differences. I should have just downloaded yours and diffed it against what I was about to commit. Didn't really want to toss what I had since I had some time in it already. I will sync the ebuilds and commit a -r1 in a bit.
