This ebuild is in gnome layman overlay, which looks like officially supported: https://cgit.gentoo.org/proj/gnome.git/ It still uses git:// protocol. Also projects are not hosted at gitlab.gnome.org. For example, i tried to install live gtksourceview. Exact clone URI is now: https://gitlab.gnome.org/GNOME/gtksourceview.git After transient look to https://gitlab.gnome.org/explore/groups it makes me to assume good default: EGIT_URI=https://gitlab.gnome.org/GNOME/${PN}.git
Assuming you meant eclass/gnome2-live.eclass[1]. [1] https://cgit.gentoo.org/proj/gnome.git/tree/eclass/gnome2-live.eclass
Oh, right :D
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/gnome.git/commit/?id=0c5ffc8bc9d1816b6a6880e112a664faddcd3cce commit 0c5ffc8bc9d1816b6a6880e112a664faddcd3cce Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-02-24 08:39:57 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-02-24 08:39:57 +0000 gnome2-live.eclass: Update repo URI to gitlab Closes: https://bugs.gentoo.org/678106 Signed-off-by: Mart Raudsepp <leio@gentoo.org> eclass/gnome2-live.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Note that the live ebuilds in there are rather out of date and only rarely blindly synced. Many projects upstream use meson by now, while the live ebuild still tries to use autotools tobuild it, etc. I intended to clean up all such outdated live ebuilds (for starters all that are autotools but upstream is meson), and will proceed with that shortly. gtksourceview is one of such. We currently don't have the time to maintain these ourselves, while busy with getting released versions up to date for starters. Eventually I do consider doing 9999 ebuilds or at least tracking development and beta releases, but will take some time to have caught up to get to that. If you are committed to maintaining some live ebuilds, we could look into getting them to the overlay and if work is of sufficient quality, then also eventually direct push access to the overlay for that purpose.
I just noticed - while it is able to be used to build projects, using gtk3, its name (gnome2) assumes it is for old (classic) gnome. I took closer look for gnome.org.eclass - looks like it defines only SRC_URI and S. It could be extended to handle both releases and live versions. Just like some ebuilds do: if "${PV}" == 9999; then..... This could be done in eclass, inheriting git-r3 (or its possible successor) and defining e.g. gnome-org_src_unpack(), which does proper dirty work, also exporing default src_unpack().
gnome.org.eclass only purpose is to set up $SRC_URI and $S, that's it. We don't want to add some git-r3.eclass defining to it really, that's out of its scope and sort of a layer violation or how to say that, as it doesn't inherit git-r3 itself. the gnome2 in eclass names are historical; we don't want to have to edit all ebuilds and break all overlays using it just to get the name changed to generic gnome.eclass or a gnome3.eclass. gnome2-live has no real need of existence imho these days; it started off in a separate gnome-live overlay, I believe; it just unconditionally pulls in various things needed by an eautoreconf and some other typing saving. Now with many things in meson, there isn't much or any difference to building the project between a release tarball and a git snapshot, and we probably just need a 9999 conditional block that inherits git-r3 and declares REPO. Though on second thought, it may be beneficial to have that set up automatically from some eclass indeed; may very well be gnome.org.eclass or some gnome-meson.eclass indeed then.. we will see once we can maintain these ebuilds more reliably, if ever.
