Re: [gentoo-dev] RFC: an eclass for github snapshots?

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Leho Kraav]

On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> 
> Right now, a quick 'grep -l github.*tarball' shows that there are about
> 147 ebuilds in portage using github snapshots. This evaluates to 83
> different packages.
> 
> The problem with github is that it suffixes the tarballs with
> a complete git commit id. This means that the `S' variable
> in the ebuild needs to refer to a long hash changing randomly. Right
> now, the problem is handled in a number of ways:
> 
> 1) (from app-admin/rudy)
> 2) (app-emacs/calfw and suggested solution for Sunrise)
> 3) (app-misc/bgrep)
> 4) (app-misc/tmux-mem-cpu-load)
> 
> What I'd like to do is creating a small github.eclass, encapsulating
> a common, nice way of handling the S issue. I guess the best solution
> would be to git with something like 2) above, with the eclass providing
> github_src_unpack() for EAPIs 2+.

What is the current situation with this one? Every once in a while I run into a github ebuild I need to create and I am not really sure what to do with it.

Right now 2) seems like the safest approach. But did anything get into EAPI?

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Zac Medico]

On 03/11/2012 10:25 AM, Leho Kraav wrote:
> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
>>
>> Right now, a quick 'grep -l github.*tarball' shows that there are about
>> 147 ebuilds in portage using github snapshots. This evaluates to 83
>> different packages.
>>
>> The problem with github is that it suffixes the tarballs with
>> a complete git commit id. This means that the `S' variable
>> in the ebuild needs to refer to a long hash changing randomly. Right
>> now, the problem is handled in a number of ways:
>>
>> 1) (from app-admin/rudy)
>> 2) (app-emacs/calfw and suggested solution for Sunrise)
>> 3) (app-misc/bgrep)
>> 4) (app-misc/tmux-mem-cpu-load)
>>
>> What I'd like to do is creating a small github.eclass, encapsulating
>> a common, nice way of handling the S issue. I guess the best solution
>> would be to git with something like 2) above, with the eclass providing
>> github_src_unpack() for EAPIs 2+.
> 
> What is the current situation with this one? Every once in a while I run into a github ebuild I need to create and I am not really sure what to do with it.
> 
> Right now 2) seems like the safest approach. But did anything get into EAPI?

No, there's no EAPI extension for that yet, and no bug filed for it here:

  https://bugs.gentoo.org/show_bug.cgi?id=174380
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
Leho Kraav <leho@kraav.com> wrote:

> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> > 
> > Right now, a quick 'grep -l github.*tarball' shows that there are
> > about 147 ebuilds in portage using github snapshots. This evaluates
> > to 83 different packages.
> > 
> > The problem with github is that it suffixes the tarballs with
> > a complete git commit id. This means that the `S' variable
> > in the ebuild needs to refer to a long hash changing randomly. Right
> > now, the problem is handled in a number of ways:
> > 
> > 1) (from app-admin/rudy)
> > 2) (app-emacs/calfw and suggested solution for Sunrise)
> > 3) (app-misc/bgrep)
> > 4) (app-misc/tmux-mem-cpu-load)
> > 
> > What I'd like to do is creating a small github.eclass, encapsulating
> > a common, nice way of handling the S issue. I guess the best
> > solution would be to git with something like 2) above, with the
> > eclass providing github_src_unpack() for EAPIs 2+.
> 
> What is the current situation with this one? Every once in a while I
> run into a github ebuild I need to create and I am not really sure
> what to do with it.
> 
> Right now 2) seems like the safest approach. But did anything get
> into EAPI?

You mean eclass? I submitted one for review but didn't get much of
positive feedback on it. I'll commit it anyway soon, just let me double
check and do some testing.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Ben]

On 12 March 2012 02:27, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
> Leho Kraav <leho@kraav.com> wrote:
>
>> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
>> >
>> > Right now, a quick 'grep -l github.*tarball' shows that there are
>> > about 147 ebuilds in portage using github snapshots. This evaluates
>> > to 83 different packages.
>> >
>> > The problem with github is that it suffixes the tarballs with
>> > a complete git commit id. This means that the `S' variable
>> > in the ebuild needs to refer to a long hash changing randomly. Right
>> > now, the problem is handled in a number of ways:
>> >
>> > 1) (from app-admin/rudy)
>> > 2) (app-emacs/calfw and suggested solution for Sunrise)
>> > 3) (app-misc/bgrep)
>> > 4) (app-misc/tmux-mem-cpu-load)
>> >
>> > What I'd like to do is creating a small github.eclass, encapsulating
>> > a common, nice way of handling the S issue. I guess the best
>> > solution would be to git with something like 2) above, with the
>> > eclass providing github_src_unpack() for EAPIs 2+.
>>
>> What is the current situation with this one? Every once in a while I
>> run into a github ebuild I need to create and I am not really sure
>> what to do with it.
>>
>> Right now 2) seems like the safest approach. But did anything get
>> into EAPI?
>
> You mean eclass? I submitted one for review but didn't get much of
> positive feedback on it. I'll commit it anyway soon, just let me double
> check and do some testing.

+1 from me. I think it would be useful to have a standard way of handling this.

Cheers,
Ben | yngwin

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Michał Górny]

[-- Attachment #1.1: Type: text/plain, Size: 2059 bytes --]

On Mon, 12 Mar 2012 09:36:00 +0800
Ben <yngwin@gmail.com> wrote:

> On 12 March 2012 02:27, Michał Górny <mgorny@gentoo.org> wrote:
> > On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
> > Leho Kraav <leho@kraav.com> wrote:
> >
> >> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> >> >
> >> > Right now, a quick 'grep -l github.*tarball' shows that there are
> >> > about 147 ebuilds in portage using github snapshots. This
> >> > evaluates to 83 different packages.
> >> >
> >> > The problem with github is that it suffixes the tarballs with
> >> > a complete git commit id. This means that the `S' variable
> >> > in the ebuild needs to refer to a long hash changing randomly.
> >> > Right now, the problem is handled in a number of ways:
> >> >
> >> > 1) (from app-admin/rudy)
> >> > 2) (app-emacs/calfw and suggested solution for Sunrise)
> >> > 3) (app-misc/bgrep)
> >> > 4) (app-misc/tmux-mem-cpu-load)
> >> >
> >> > What I'd like to do is creating a small github.eclass,
> >> > encapsulating a common, nice way of handling the S issue. I
> >> > guess the best solution would be to git with something like 2)
> >> > above, with the eclass providing github_src_unpack() for EAPIs
> >> > 2+.
> >>
> >> What is the current situation with this one? Every once in a while
> >> I run into a github ebuild I need to create and I am not really
> >> sure what to do with it.
> >>
> >> Right now 2) seems like the safest approach. But did anything get
> >> into EAPI?
> >
> > You mean eclass? I submitted one for review but didn't get much of
> > positive feedback on it. I'll commit it anyway soon, just let me
> > double check and do some testing.
> 
> +1 from me. I think it would be useful to have a standard way of
> handling this.

Attaching my current conceptual eclass. I've tested it with github,
gitweb and bitbucket. It won't work with gitorious but their snapshot
download mechanism is broken anyway (they like to submit 'try again
later' in plaintext).

-- 
Best regards,
Michał Górny

[-- Attachment #1.2: vcs-snapshot.eclass --]
[-- Type: text/plain, Size: 1419 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: vcs-snapshot.eclass
# @MAINTAINER:
# mgorny@gentoo.org
# @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does support
# working with snapshots generated by various VCS-es. It unpacks those
# to ${S} rather than the original directory containing commit id.
#
# Note that this eclass handles only unpacking. You need to specify
# SRC_URI yourself, and call any autoreconfiguration as necessary.
# The example does that using autotools-utils eclass.
#
# Right now, the eclass was tested with github, bitbucket and gitweb
# snapshots. Feel free to report snapshotting services which aren't
# working.
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot
#
# SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
# @CODE

case ${EAPI:-0} in
	0|1) die "EAPI ${EAPI} unsupported.";; # default(), SRC_URI arrows
	2|3|4) ;;
	*) die "github-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac

EXPORT_FUNCTIONS src_unpack

vcs-snapshot_src_unpack() {
	default

	# github, bitbucket: username-projectname-hash
	# gitweb: projectname-tagname-hash
	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]

On Mon, 12 Mar 2012 10:47:41 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 12 Mar 2012 09:36:00 +0800
> Ben <yngwin@gmail.com> wrote:
> 
> > On 12 March 2012 02:27, Michał Górny <mgorny@gentoo.org> wrote:
> > > On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
> > > Leho Kraav <leho@kraav.com> wrote:
> > >
> > >> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> > >> >
> > >> > Right now, a quick 'grep -l github.*tarball' shows that there
> > >> > are about 147 ebuilds in portage using github snapshots. This
> > >> > evaluates to 83 different packages.
> > >> >
> > >> > The problem with github is that it suffixes the tarballs with
> > >> > a complete git commit id. This means that the `S' variable
> > >> > in the ebuild needs to refer to a long hash changing randomly.
> > >> > Right now, the problem is handled in a number of ways:
> > >> >
> > >> > 1) (from app-admin/rudy)
> > >> > 2) (app-emacs/calfw and suggested solution for Sunrise)
> > >> > 3) (app-misc/bgrep)
> > >> > 4) (app-misc/tmux-mem-cpu-load)
> > >> >
> > >> > What I'd like to do is creating a small github.eclass,
> > >> > encapsulating a common, nice way of handling the S issue. I
> > >> > guess the best solution would be to git with something like 2)
> > >> > above, with the eclass providing github_src_unpack() for EAPIs
> > >> > 2+.
> > >>
> > >> What is the current situation with this one? Every once in a
> > >> while I run into a github ebuild I need to create and I am not
> > >> really sure what to do with it.
> > >>
> > >> Right now 2) seems like the safest approach. But did anything get
> > >> into EAPI?
> > >
> > > You mean eclass? I submitted one for review but didn't get much of
> > > positive feedback on it. I'll commit it anyway soon, just let me
> > > double check and do some testing.
> > 
> > +1 from me. I think it would be useful to have a standard way of
> > handling this.
> 
> Attaching my current conceptual eclass. I've tested it with github,
> gitweb and bitbucket. It won't work with gitorious but their snapshot
> download mechanism is broken anyway (they like to submit 'try again
> later' in plaintext).

Committed.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] RFC: an eclass for github snapshots?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

Hello,

Right now, a quick 'grep -l github.*tarball' shows that there are about
147 ebuilds in portage using github snapshots. This evaluates to 83
different packages.

The problem with github is that it suffixes the tarballs with
a complete git commit id. This means that the `S' variable
in the ebuild needs to refer to a long hash changing randomly. Right
now, the problem is handled in a number of ways:

1) (from app-admin/rudy)

S="${WORKDIR}/solutious-${PN}-*"

I'm surprised if that actually works. I'd say that seems not
PMS-compliant but in fact PMS seems to almost not mention S.

2) (app-emacs/calfw and suggested solution for Sunrise)

src_unpack() {
	unpack ${A}
	mv kiwanami-emacs-calfw-* ${P} || die
}

3) (app-misc/bgrep)

GITHUB_USER="tmbinc"
GITHUB_HASH="49b098be9548d174023ad05c10f6af9d02b8e18e"
MY_P="${GITHUB_USER}-${PN}-${GITHUB_HASH:0:7}"
S="${WORKDIR}/${MY_P}"

4) (app-misc/tmux-mem-cpu-load)

src_prepare() {
	cd "${WORKDIR}"/thewtex-${PN}-*
	S=$(pwd)
}


What I'd like to do is creating a small github.eclass, encapsulating
a common, nice way of handling the S issue. I guess the best solution
would be to git with something like 2) above, with the eclass providing
github_src_unpack() for EAPIs 2+.

Maybe the eclass could be extended to support other kinds of snapshots.
I'm not sure if there aren't other services providing snapshots similar
to github.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]