Re: [gentoo-dev] Ohloh statistics updated
2011/7/22 Stanislav Ochotnicky : > Hello fellow devs, > > some of you know that our commit statistics at Ohloh[1] have been > outdated because they were not able to process our huge CVS tree for > some reason :-) > > One way or the other I managed to reuse robbat2's previous work on > cvs->git conversion and keep our experimental conversion repository > up-to-date (I don't have cron job, but it's still completely automated). > > After 3 weeks of crunching (or was it more?) Ohloh machines finally spit > out updated statistics, removing few warnings from our project page > (such as "Decreasing year-over-year development activity""). Updates are > faster of course so our stats shouldn't be outdated anymore. > > So go claim your commits, Nice! Thanks for taking this up! -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Ohloh statistics updated
2011/7/22 Stanislav Ochotnicky : > Hello fellow devs, > > some of you know that our commit statistics at Ohloh[1] have been > outdated because they were not able to process our huge CVS tree for > some reason :-) > > One way or the other I managed to reuse robbat2's previous work on > cvs->git conversion and keep our experimental conversion repository > up-to-date (I don't have cron job, but it's still completely automated). > > After 3 weeks of crunching (or was it more?) Ohloh machines finally spit > out updated statistics, removing few warnings from our project page > (such as "Decreasing year-over-year development activity""). Updates are > faster of course so our stats shouldn't be outdated anymore. > > So go claim your commits, > Good job! Thank you! > > [1] https://www.ohloh.net/p/gentoo > [2] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary > > -- > Stanislav Ochotnicky > > PGP: 7B087241 > jabber: stanis...@ochotnicky.com > -- Jesus Rivero (Neurogeek) Gentoo Developer
[gentoo-dev] Ohloh statistics updated
Hello fellow devs, some of you know that our commit statistics at Ohloh[1] have been outdated because they were not able to process our huge CVS tree for some reason :-) One way or the other I managed to reuse robbat2's previous work on cvs->git conversion and keep our experimental conversion repository up-to-date (I don't have cron job, but it's still completely automated). After 3 weeks of crunching (or was it more?) Ohloh machines finally spit out updated statistics, removing few warnings from our project page (such as "Decreasing year-over-year development activity""). Updates are faster of course so our stats shouldn't be outdated anymore. So go claim your commits, [1] https://www.ohloh.net/p/gentoo [2] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary -- Stanislav Ochotnicky PGP: 7B087241 jabber: stanis...@ochotnicky.com signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: leechcraft.eclass
* Alex Alexander schrieb am 22.07.11 um 13:30 Uhr: > On Fri, Jul 22, 2011 at 14:21, Marc Schiffbauer wrote: > > Am Freitag, 22. Juli 2011, 14:50:06 schrieb Maxim Koltsov: > >> Hi devs, > >> I'm about to add Leechcraft modular internet client to tree. It has 32 > >> packages and uses it's own eclass. Please review it and allow me to > >> commit it to the tree. > >> Also i'd want to ask: is it woth to add new category (e.g. > >> leechcraft-plugins) to simplify managing leechcraft ebuilds. And the > >> last question: is it good to add versions for all ebuilds too? > > > > IMO live ebuilds should only be held in an overlay. > > > > -Marc > > versions are nice, but they typically require more time and > effort to maintain. I'd recommend adding them only if you are willing > to do the work. Sometimes ebuilds are useful as a way to prepare > for the next release. Yes, but the big drawback is that you do not have any checksums of the source. So if for example an upstream source code gets exploited you will never notice until the trojan or whatever got in there will do something. Sure this can happen with normal tarballs too, but is much more unlikely and can only happen if the source is already bad at the time of "repoman manifest". -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpiMgjqTV4DQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: leechcraft.eclass
On Fri, 22 Jul 2011 14:57:08 +0400
Maxim Koltsov wrote:
> Sorry, forgot the eclass. Attaching it here...
> P.S. Email of author: 0xd34df...@gmail.com
Then you should CC him (like I did now).
> # Original author: 0xd34df00d <0xd34df...@gmail.com> and
> #Andrian Nord
>
> # Commiter: A.Vinogradov aka slepnoga
Use eclassdoc.
> case ${EAPI:-0} in
> 4|3|2) ;;
> 0|1) die "EAPI not supported, bug ebuild mantainer" ;;
> *) die "Unknown EAPI, Bug eclass maintainers." ;;
> esac
Don't mix space and tab indent.
> if [[ "${PV}" == "" ]]; then
Needs not to be quoted.
> EGIT_PROJECT="leechcraft-${PV}"
What's the reasoning for this?
> KEYWORDS=""
Keywords must not be set by an eclass. Package managers will complain
about this.
> MY_P='leechcraft'
Usually, ${MY_P} stands for [alternate PN]-[PV]. MY_PN's what you're
referring to here.
> S="${WORKDIR}/${MY_P}-${PV}"
You seem not to be using ${MY_P} anywhere else. Just put
'leechcraft-${PV}' there then, don't pollute the environment.
> KEYWORDS="~amd64 ~x86"
As above, completely illegal.
> DEPEND="${DEPEND}
> !www-client/leechcraft"
What's this and why is that?
> SLOT="0"
SLOTs don't fit eclasses too, unless special use. Eclass is no excuse
to avoid declaring standard variables in ebuilds.
> # @FUNCTION:leechcraft_src_unpack
> # @DESCRIPTION:
> # Standart src_unpack live ebuild
>
> leechcraft_src_unpack() {
> git-2_src_unpack
>
> cd "${S}"
> }
What's the point of redeclaring this? Inheriting git-2 should do
the same, wouldn't it?
> # @FUNCTION: leechcraft_src_configure
> # @DESCRIPTION:
> # Use for configure leechcraft source.
> # Build_type is magic :)
That's not an useful description.
> # @FUNCTION: leechcraft_src_install
> # @DESCRIPTION:
> # Call cmake-utils_src_install :)
>
> leechcraft_src_install() {
> cmake-utils_src_install
> }
Once again, inheriting cmake-utils should do that.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due dragonheart retirement
On Wed, Jul 20, 2011 at 11:08 AM, Pacho Ramos wrote: > Due dragonheart retirement the following packages need a new maintainer: > dev-python/pyspf > dev-python/python-lzo Python team will take these two. Best regards, -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] RFC: leechcraft.eclass
2011/7/22 Chí-Thanh Christopher Nguyễn : > But I do think it is > good to have live ebuilds in portage, especially for fast moving > applications. I think they can be useful for any application as long as they're maintained. I can see the value of the QA policy that they must be masked, but I don't see value in forcing them out of the tree. I think the key is that we want the tree to work - if it works then it belongs. The ability to seamlessly support live builds is one of Gentoo's distinctive features - since we're already a bit of a niche we should embrace this. Rich
Re: [gentoo-dev] RFC: leechcraft.eclass
Maxim Koltsov schrieb: > Also i'd want to ask: is it woth to add new category (e.g. > leechcraft-plugins) to simplify managing leechcraft ebuilds. And the > last question: is it good to add versions for all ebuilds too? > I don't think there is a need for a new category. But I do think it is good to have live ebuilds in portage, especially for fast moving applications. If you are very close to upstream (as it seems to be) then you can submit patches directly there which makes maintaining the live ebuilds easier. Best regards, Chí-Thanh Christopher Nguyen
Re: [gentoo-dev] RFC: leechcraft.eclass
On Fri, Jul 22, 2011 at 14:21, Marc Schiffbauer wrote: > Am Freitag, 22. Juli 2011, 14:50:06 schrieb Maxim Koltsov: >> Hi devs, >> I'm about to add Leechcraft modular internet client to tree. It has 32 >> packages and uses it's own eclass. Please review it and allow me to >> commit it to the tree. >> Also i'd want to ask: is it woth to add new category (e.g. >> leechcraft-plugins) to simplify managing leechcraft ebuilds. And the >> last question: is it good to add versions for all ebuilds too? > > IMO live ebuilds should only be held in an overlay. > > -Marc versions are nice, but they typically require more time and effort to maintain. I'd recommend adding them only if you are willing to do the work. Sometimes ebuilds are useful as a way to prepare for the next release. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] RFC: leechcraft.eclass
Am Freitag, 22. Juli 2011, 14:50:06 schrieb Maxim Koltsov: > Hi devs, > I'm about to add Leechcraft modular internet client to tree. It has 32 > packages and uses it's own eclass. Please review it and allow me to > commit it to the tree. > Also i'd want to ask: is it woth to add new category (e.g. > leechcraft-plugins) to simplify managing leechcraft ebuilds. And the > last question: is it good to add versions for all ebuilds too? IMO live ebuilds should only be held in an overlay. -Marc
[gentoo-dev] Re: RFC: leechcraft.eclass
Sorry, forgot the eclass. Attaching it here... P.S. Email of author: 0xd34df...@gmail.com leechcraft.eclass Description: Binary data
[gentoo-dev] RFC: leechcraft.eclass
Hi devs, I'm about to add Leechcraft modular internet client to tree. It has 32 packages and uses it's own eclass. Please review it and allow me to commit it to the tree. Also i'd want to ask: is it woth to add new category (e.g. leechcraft-plugins) to simplify managing leechcraft ebuilds. And the last question: is it good to add versions for all ebuilds too?
