public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] RFC: an eclass for github snapshots?
@ 2011-05-30  6:27 Michał Górny
  0 siblings, 0 replies; 7+ messages in thread
From: Michał Górny @ 2011-05-30  6:27 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
       [not found] <gY49c-206-11@gated-at.bofh.it>
@ 2012-03-11 17:25 ` Leho Kraav
  2012-03-11 18:15   ` Zac Medico
  2012-03-11 18:27   ` Michał Górny
  0 siblings, 2 replies; 7+ messages in thread
From: Leho Kraav @ 2012-03-11 17:25 UTC (permalink / raw
  To: linux.gentoo.dev; +Cc: gentoo-dev

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?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
  2012-03-11 17:25 ` [gentoo-dev] RFC: an eclass for github snapshots? Leho Kraav
@ 2012-03-11 18:15   ` Zac Medico
  2012-03-11 18:27   ` Michał Górny
  1 sibling, 0 replies; 7+ messages in thread
From: Zac Medico @ 2012-03-11 18:15 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
  2012-03-11 17:25 ` [gentoo-dev] RFC: an eclass for github snapshots? Leho Kraav
  2012-03-11 18:15   ` Zac Medico
@ 2012-03-11 18:27   ` Michał Górny
  2012-03-12  1:36     ` Ben
  1 sibling, 1 reply; 7+ messages in thread
From: Michał Górny @ 2012-03-11 18:27 UTC (permalink / raw
  To: gentoo-dev; +Cc: leho, linux.gentoo.dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
  2012-03-11 18:27   ` Michał Górny
@ 2012-03-12  1:36     ` Ben
  2012-03-12  9:47       ` Michał Górny
  0 siblings, 1 reply; 7+ messages in thread
From: Ben @ 2012-03-12  1:36 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
  2012-03-12  1:36     ` Ben
@ 2012-03-12  9:47       ` Michał Górny
  2012-03-19  8:41         ` Michał Górny
  0 siblings, 1 reply; 7+ messages in thread
From: Michał Górny @ 2012-03-12  9:47 UTC (permalink / raw
  To: gentoo-dev; +Cc: yngwin


[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [gentoo-dev] RFC: an eclass for github snapshots?
  2012-03-12  9:47       ` Michał Górny
@ 2012-03-19  8:41         ` Michał Górny
  0 siblings, 0 replies; 7+ messages in thread
From: Michał Górny @ 2012-03-19  8:41 UTC (permalink / raw
  To: gentoo-dev; +Cc: yngwin

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-03-19  8:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <gY49c-206-11@gated-at.bofh.it>
2012-03-11 17:25 ` [gentoo-dev] RFC: an eclass for github snapshots? Leho Kraav
2012-03-11 18:15   ` Zac Medico
2012-03-11 18:27   ` Michał Górny
2012-03-12  1:36     ` Ben
2012-03-12  9:47       ` Michał Górny
2012-03-19  8:41         ` Michał Górny
2011-05-30  6:27 Michał Górny

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox