Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Damo Brisbane]

"suspicious of" to strong a word - "wary of" !

On Mon, Dec 4, 2017 at 7:16 AM, Damo Brisbane  wrote:

> As a relative newbie I wonder about the format generally of the lists,
> however "unbroken", I would be concerned about a dated look. Also, IMO
> anything requiring "manual restructuring" - verses automation - I am a
> little suspicious of. If dumb stuff is coming through, why cant the good
> stuff be automatically curated and presented on top of existing lists? ie
> run a PoC, curated content targeting mobile users. From there drivers may
> emerge for incorporating updates or come back to suggestions herein.
>
> On Sun, Dec 3, 2017 at 9:18 AM, Michał Górny  wrote:
>
>> Hello, everyone.
>>
>> This is something that's been talked about privately a lot lately but it
>> seems that nobody went forward to put things into motion. SO here's
>> a proposal that aims to improve the condition of our mailing lists
>> and solve some of the problems they are facing today.
>>
>>
>> Problems
>> 
>>
>> Currently the developer-oriented mailing lists gentoo-dev and gentoo-
>> project are open to posting by everyone. While this has been generally
>> beneficial, we seem to be having major problems with some
>> of the posters for more than a year. Off hand, I can think of three:
>>
>> 1. Repeating attacks against Gentoo and/or Gentoo developers (including
>> pure personal attacks). While it is understandable that some people may
>> be frustrated and need to vent off, repeating attacks from the same
>> person are seriously demotivating to everyone.
>>
>> 2. Frequent off-topics, often irrelevant to the thread at hand.
>> I understand that some of those topics are really interesting but it is
>> really time-consuming to filter through all the off-topic mails
>> in search of data relevant to the topic at hand. What's worst, sometimes
>> you don't even get a single on-topic reply.
>>
>> 3. Support requests. Some of our 'expert users' have been abusing
>> the mailing lists to request support (because it's easier to ask
>> everyone than go through proper channels) and/or complain about bug
>> resolutions. This is a minor issue but still it is one.
>>
>>
>> All of those issues are slowly rendering the mailing lists impossible to
>> use. People waste a lot of time trying to gather feedback, and get
>> demotivated in the process. A steadily growing number of developers
>> either stop reading the mailing lists altogether, or reduce their
>> activity.
>>
>> For example, eclass reviews usually don't get more than one reply,
>> and even that is not always on-topic. And after all, getting this kind
>> of feedback is one of the purposes of the -dev mailing list!
>>
>>
>> Proposal
>> 
>>
>> Give the failure of other solutions tried for this, I'd like to
>> establish the following changes to the mailing lists:
>>
>> 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
>> initially restricted to active Gentoo developers.
>>
>> 1a. Subscription (reading) and archives will still be open.
>>
>> 1b. Active Gentoo contributors will be able to obtain posting access
>> upon being vouched for by an active Gentoo developer.
>>
>> 2. A new mailing list 'gentoo-expert' will be formed to provide
>> a discussion medium for expert Gentoo users and developers.
>>
>> 2a. gentoo-expert will have open posting access like gentoo-dev has now.
>>
>>
>> Rationale
>> =
>>
>> I expect that some of you will find this a drastic measure. However, I
>> would like to point out that I believe we've already exhausted all other
>> options to no avail.
>>
>> The problems of more abusive behavior from some of the mailing list
>> members have been reported to ComRel numerous times. After the failure
>> of initial enforcement, I'm not aware of ComRel doing anything to solve
>> the problem. The main arguments I've heard from ComRel members were:
>>
>> A. Bans can be trivially evaded, and history proves that those evasions
>> create more noise than leaving the issue as is.
>>
>> B. People should be allowed to express their opinion [even if it's pure
>> hate speech that carries no value to anyone].
>>
>> C. The replies of Gentoo developers were worse [no surprise that people
>> lose their patience after being attacked for a few months].
>>
>>
>> The alternative suggested by Com

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Damo Brisbane]

As a relative newbie I wonder about the format generally of the lists,
however "unbroken", I would be concerned about a dated look. Also, IMO
anything requiring "manual restructuring" - verses automation - I am a
little suspicious of. If dumb stuff is coming through, why cant the good
stuff be automatically curated and presented on top of existing lists? ie
run a PoC, curated content targeting mobile users. From there drivers may
emerge for incorporating updates or come back to suggestions herein.

On Sun, Dec 3, 2017 at 9:18 AM, Michał Górny  wrote:

> Hello, everyone.
>
> This is something that's been talked about privately a lot lately but it
> seems that nobody went forward to put things into motion. SO here's
> a proposal that aims to improve the condition of our mailing lists
> and solve some of the problems they are facing today.
>
>
> Problems
> 
>
> Currently the developer-oriented mailing lists gentoo-dev and gentoo-
> project are open to posting by everyone. While this has been generally
> beneficial, we seem to be having major problems with some
> of the posters for more than a year. Off hand, I can think of three:
>
> 1. Repeating attacks against Gentoo and/or Gentoo developers (including
> pure personal attacks). While it is understandable that some people may
> be frustrated and need to vent off, repeating attacks from the same
> person are seriously demotivating to everyone.
>
> 2. Frequent off-topics, often irrelevant to the thread at hand.
> I understand that some of those topics are really interesting but it is
> really time-consuming to filter through all the off-topic mails
> in search of data relevant to the topic at hand. What's worst, sometimes
> you don't even get a single on-topic reply.
>
> 3. Support requests. Some of our 'expert users' have been abusing
> the mailing lists to request support (because it's easier to ask
> everyone than go through proper channels) and/or complain about bug
> resolutions. This is a minor issue but still it is one.
>
>
> All of those issues are slowly rendering the mailing lists impossible to
> use. People waste a lot of time trying to gather feedback, and get
> demotivated in the process. A steadily growing number of developers
> either stop reading the mailing lists altogether, or reduce their
> activity.
>
> For example, eclass reviews usually don't get more than one reply,
> and even that is not always on-topic. And after all, getting this kind
> of feedback is one of the purposes of the -dev mailing list!
>
>
> Proposal
> 
>
> Give the failure of other solutions tried for this, I'd like to
> establish the following changes to the mailing lists:
>
> 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> initially restricted to active Gentoo developers.
>
> 1a. Subscription (reading) and archives will still be open.
>
> 1b. Active Gentoo contributors will be able to obtain posting access
> upon being vouched for by an active Gentoo developer.
>
> 2. A new mailing list 'gentoo-expert' will be formed to provide
> a discussion medium for expert Gentoo users and developers.
>
> 2a. gentoo-expert will have open posting access like gentoo-dev has now.
>
>
> Rationale
> =
>
> I expect that some of you will find this a drastic measure. However, I
> would like to point out that I believe we've already exhausted all other
> options to no avail.
>
> The problems of more abusive behavior from some of the mailing list
> members have been reported to ComRel numerous times. After the failure
> of initial enforcement, I'm not aware of ComRel doing anything to solve
> the problem. The main arguments I've heard from ComRel members were:
>
> A. Bans can be trivially evaded, and history proves that those evasions
> create more noise than leaving the issue as is.
>
> B. People should be allowed to express their opinion [even if it's pure
> hate speech that carries no value to anyone].
>
> C. The replies of Gentoo developers were worse [no surprise that people
> lose their patience after being attacked for a few months].
>
>
> The alternative suggested by ComRel pretty much boiled down to 'ignore
> the trolls'. While we can see this is actually starting to happen right
> now (even the most determined developers stopped replying), this doesn't
> really solve the problem because:
>
> I. Some people are really determined and continue sending mails even if
> nobody replies to them. In fact, they are perfectly capable of replying
> to themselves.
>
> II. This practically assumes that every new mailing list subscriber will
> be able to recognize the problem. Otherwise, new people will repeatedly
> be lured into discussing with them.
>
> III. In the end, it puts Gentoo in a bad position. Firstly, because it
> silently consents to misbehavior on the mailing lists. Secondly, because
> the lack of any statement in reply to accusations could be seen
> as a sign of shameful silent admittance.
>
>
> Yet another alternative that was proposed 

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Damo Brisbane]

Cheers Michael,

I've made most those changes, including USER/GROUP*, that confuses me too;
copied pattern from another ebuild. Also removed creating separate folder
/etc/fabio.d; re this, I noticed the fabio configuration accepts either
folder path or *URL* for configuration file; not sure how this works,
though it does seem to underlie some type of arbitrariness in including
such a /etc/fabio.d folder within this ebuild.

Re for...keepdir, I found removing it then the /var/log/fabio folders were
not getting created, so keeping it in there.

http://www.calculate-linux.org/main/en/using_ebuild, says this of *keepdir*:

*Creates (if necessary) a .keep file in the given directory so that it
isn't auto-cleaned. Never create a .keep file yourself. If Portage changes
how keepdir works, then creating the file yourself will break the package.*

regards,
Damon

On Fri, Nov 10, 2017 at 10:59 PM, Michael Orlitzky  wrote:

> On 11/09/2017 11:08 PM, Damo Brisbane wrote:
> > I've run up a couple of golang based ebuilds - for the fabio load
> > balancer. My first run at it, not completely sure of any follow up
> > process, mentor? other posting, overlap with existing work? Anyway,
> > would appreciate the feedback.
>
> Your $VERSION variable can probably be replaced with "${PV}" to save a
> line.
>
> Your init script takes care of the permissions on /var/lib/fabio and
> /var/log/fabio/fabio.log...
>
>   start_pre() {
> checkpath -q -d -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_HOMEDIR}
> checkpath -q -f -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_LOGFILE}
>   }
>
> so the following in the ebuild might be redundant?
>
>   for x in /var/{lib,log}/${PN}; do
> keepdir "${x}"
> fowners fabio:fabio "${x}"
>   done
>
> (warning: I have never understood what keepdir is supposed to
> accomplish, so maybe I'm wrong here).
>
> On the other hand, if you've created a dedicated user and group for the
> daemon, I don't think there's much benefit to letting the end user
> switch them via FABIO_USER and FABIO_GROUP (it just makes the
> permissions harder to get right). That's a judgment call though.
>
> Finally, if the stanza above *does* turn out to be redundant, then
> there's another small improvement that can be made. Since the "fabio"
> user and group are used nowhere else in the ebuild, you could create
> them in pkg_preinst() instead of pkg_setup(). Doing that has one main
> benefit -- namely that if the installation fails, the user and group
> won't be created.
>
> Overall, looks good.
>
> For testing help, you'll probably have the best luck in #gentoo-user on
> IRC. For ebuild reviews, we have a dedicated mailing list,
> gentoo-devh...@lists.gentoo.org and an associated IRC channel,
> #gentoo-dev-help (yes, they're hyphenated differently...)
>
>

Re: [gentoo-dev] Open Build Service

[Damo Brisbane]

My two cents worth,

I think broader features not necessarily better; to draw an analogy, dotGo
2015 - Rob Pike - Simplicity is Complicated
, ".. a lot of people talk
about tooling... but the real reason [that the go language is sucessful] is
simplicity..most of the [other languages keep adding] new
features..javascript gets classes.. I realised.. that all of these
languages are changing into the same language"... and more, but interesting
nonetheless.

I am opinionated, I have come to Gentoo because I rejected what I saw as
increased abstraction and concepts being piled onto other distributions,
ironically with such features diminishing rather than expanding choices. So
what would be more powerful? IMHO patience and more concentration on
current build tools in the short term at least, back the current product
and skills within this existing platform, for now. Why? because it is a
good platform, patchy perhaps in some areas, but too good to throw away and
this product is in a perfect position to continue to encouraging community
involvement and improvement against the current toolset. Jumping on, or
dissapating current work across big changes to build concepts, will harm
the product at least in the short term. Long term, let the law of commits
decide.

Kind regards,



On Fri, Nov 10, 2017 at 9:03 AM, Samuel Bernardo <
samuelbernardo.m...@gmail.com> wrote:

> Hi,
>
> I send this email to know the devs opinion about Gentoo integration with
> Open Build Service[1].
>
> When creating specialized images and using an automated process for
> testing before deployment, I think that Open Build Service would be
> useful. It already support all major binary based distros and I think
> that Gentoo could be in there also.
>
> There is also a subforum with some interesting posts[2], where was
> mentioned some references for Gentoo@OBS.
>
> I reviewed catalyst scripts and Gentoo workflow when creating the
> package repository, and I think that it could be integrated in OBS. The
> advantage is about creating repositories of binary packages from Gentoo
> that would be used to deploy containers or VMs. This way, updates could
> be applied to the images. OBS will be responsible to compile all images
> that would be associated with their own created binary repository.
>
> To use the binary repository in Gentoo is suggested to use a nfs share
> for portage/packages directory[3], but it would be a smoother
> integration if emerge gets the packages directly from an url.
>
> You can ask, but for that why not using a binary disto? Well they're not
> Gentoo... What I mean with this is that all the Gentoo tools, portage
> architecture and the ebuild format that allows for excellent source
> package definition (EAPI), turn it unique. Also the freedom associated
> with Gentoo distribution that, with less effort than the others, allows
> for the creation of new distros. Cross compiling tools are also amazing.
>
> So why shouldn't I wish to use Gentoo always?
>
> Well it don't need to be OBS, but since this opensource project have
> some nice ideas, why not starting from there?
>
> Best,
>
> Samuel
>
> [1] http://openbuildservice.org/
>
> [2] https://forums.gentoo.org/viewtopic-p-7829060.html
>
> [3] https://wiki.gentoo.org/wiki/Binary_package_guide
>
>
>

[gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Damo Brisbane]

I've run up a couple of golang based ebuilds - for the fabio load balancer.
My first run at it, not completely sure of any follow up process, mentor?
other posting, overlap with existing work? Anyway, would appreciate the
feedback.

FYI, custom overlay at * https://github.com/damobrisbane/damo-overlay *.

Tried to follow ?prior art? - but first run at it, probably dumb stuff in
there, of note:

* Followed "consul" ebuild for template, specifically adds users/openrc
init and confd files and logging. Not a systemd fan so please dont ask
unless you want to do it yourself..

* I think installs ok?:

>>> emerge -aq fabio

[ebuild  N] dev-go/govendor-1.0.9
[ebuild  N] dev-go/vendorfmt-
[ebuild  N] net-proxy/fabio-1.5.3

Would you like to merge these packages? [Yes/No] y

>>> Verifying ebuild manifests
>>> Emerging (1 of 3) dev-go/govendor-1.0.9::damo-overlay
>>> Installing (1 of 3) dev-go/govendor-1.0.9::damo-overlay
>>> Emerging (2 of 3) dev-go/vendorfmt-::damo-overlay
>>> Installing (2 of 3) dev-go/vendorfmt-::damo-overlay
>>> Emerging (3 of 3) net-proxy/fabio-1.5.3::damo-overlay
>>> Installing (3 of 3) net-proxy/fabio-1.5.3::damo-overlay
>>> Recording net-proxy/fabio in "world" favorites file...

>>>

Thanks in advance
Damon

Re: [gentoo-dev] "Not a git repository" error on ebuild

[Damo Brisbane]

Thanks all, commenting out below line in source Makefile eems to have
removed error

GO = GOGC=off go
#GOFLAGS = -ldflags "-X main.version=$(shell git describe --tags)"
GOVENDOR = $(shell which govendor)


On Wed, Nov 8, 2017 at 7:45 AM, Damo Brisbane  wrote:

> We have this in the project makefile..
>
> GOFLAGS = -ldflags "-X main.version=$(shell git describe --tags)"
>
> ..
>
> On Wed, Nov 8, 2017 at 7:44 AM, Damo Brisbane 
> wrote:
>
>> attached, ok?
>>
>> On Wed, Nov 8, 2017 at 5:33 AM, Alan McKinnon 
>> wrote:
>>
>>> On 07/11/2017 21:10, Damo Brisbane wrote:
>>> > Hi,
>>> >
>>> > I am getting an error on custom fabio-1.5.2.ebuild
>>> > <https://github.com/damobrisbane/damo-overlay/blob/master/ne
>>> t-proxy/fabio/fabio-1.5.2.ebuild> -
>>> > "Not a git repository (or any of the parent directories)..." I've been
>>> > looking on web, trying some things, but still message is coming up,
>>> > appreciate suggestions. Note package is installing fine, just not sure
>>> > how to clean up this message.
>>> >
>>> >  Thanks in advance:
>>>
>>>
>>>
>>>
>>> Please post the ebuild. That's a git error (not a portage error) and it
>>> means you are trying to run "git " without running "git
>>> init" first
>>>
>>>
>>> >
>>> >
>>> >
>>> >>>> Emerging (2 of 2) net-proxy/fabio-1.5.2::damo-overlay
>>> >  * fabio-1.5.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...
>>>
>>> >  [ ok ]
>>> >  * Adding group 'fabio' to your system ...
>>> >  *  - Groupid: next available
>>> >  * Adding user 'fabio' to your system ...
>>> >  *  - Userid: 116
>>> >  *  - Shell: /sbin/nologin
>>> >  *  - Home: /var/lib/fabio
>>> >  *  - Groups: fabio
>>> >  *  - GECOS: added by portage for fabio
>>> >  *  - Creating /var/lib/fabio in /
>>> >>>> Unpacking source...
>>> >>>> Source unpacked in /tmp/portage/net-proxy/fabio-1.5.2/work
>>> >>>> Preparing source in
>>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>>> >>>> Source prepared.
>>> >>>> Configuring source in
>>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>>> >>>> Source configured.
>>> >>>> Compiling source in
>>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>>> > make -j5 -C
>>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/gith
>>> ub.com/fabiolb/fabio
>>> > <http://github.com/fabiolb/fabio> install
>>> > make: Entering directory
>>> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
>>> hub.com/fabiolb/fabio
>>> > <http://github.com/fabiolb/fabio>'
>>> > *fatal: Not a git repository (or any of the parent directories): .git*
>>> > GOGC=off go install -ldflags "-X main.version="
>>> > make: Leaving directory
>>> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
>>> hub.com/fabiolb/fabio
>>> > <http://github.com/fabiolb/fabio>'
>>> >>>> Source compiled.
>>> >
>>>
>>>
>>> --
>>> Alan McKinnon
>>> alan.mckin...@gmail.com
>>>
>>>
>>>
>>
>

Re: [gentoo-dev] "Not a git repository" error on ebuild

[Damo Brisbane]

We have this in the project makefile..

GOFLAGS = -ldflags "-X main.version=$(shell git describe --tags)"

..

On Wed, Nov 8, 2017 at 7:44 AM, Damo Brisbane  wrote:

> attached, ok?
>
> On Wed, Nov 8, 2017 at 5:33 AM, Alan McKinnon 
> wrote:
>
>> On 07/11/2017 21:10, Damo Brisbane wrote:
>> > Hi,
>> >
>> > I am getting an error on custom fabio-1.5.2.ebuild
>> > <https://github.com/damobrisbane/damo-overlay/blob/master/
>> net-proxy/fabio/fabio-1.5.2.ebuild> -
>> > "Not a git repository (or any of the parent directories)..." I've been
>> > looking on web, trying some things, but still message is coming up,
>> > appreciate suggestions. Note package is installing fine, just not sure
>> > how to clean up this message.
>> >
>> >  Thanks in advance:
>>
>>
>>
>>
>> Please post the ebuild. That's a git error (not a portage error) and it
>> means you are trying to run "git " without running "git
>> init" first
>>
>>
>> >
>> >
>> >
>> >>>> Emerging (2 of 2) net-proxy/fabio-1.5.2::damo-overlay
>> >  * fabio-1.5.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...
>> >  [ ok ]
>> >  * Adding group 'fabio' to your system ...
>> >  *  - Groupid: next available
>> >  * Adding user 'fabio' to your system ...
>> >  *  - Userid: 116
>> >  *  - Shell: /sbin/nologin
>> >  *  - Home: /var/lib/fabio
>> >  *  - Groups: fabio
>> >  *  - GECOS: added by portage for fabio
>> >  *  - Creating /var/lib/fabio in /
>> >>>> Unpacking source...
>> >>>> Source unpacked in /tmp/portage/net-proxy/fabio-1.5.2/work
>> >>>> Preparing source in
>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>> >>>> Source prepared.
>> >>>> Configuring source in
>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>> >>>> Source configured.
>> >>>> Compiling source in
>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>> > make -j5 -C
>> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/gith
>> ub.com/fabiolb/fabio
>> > <http://github.com/fabiolb/fabio> install
>> > make: Entering directory
>> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
>> hub.com/fabiolb/fabio
>> > <http://github.com/fabiolb/fabio>'
>> > *fatal: Not a git repository (or any of the parent directories): .git*
>> > GOGC=off go install -ldflags "-X main.version="
>> > make: Leaving directory
>> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
>> hub.com/fabiolb/fabio
>> > <http://github.com/fabiolb/fabio>'
>> >>>> Source compiled.
>> >
>>
>>
>> --
>> Alan McKinnon
>> alan.mckin...@gmail.com
>>
>>
>>
>

Re: [gentoo-dev] "Not a git repository" error on ebuild

[Damo Brisbane]

attached, ok?

On Wed, Nov 8, 2017 at 5:33 AM, Alan McKinnon 
wrote:

> On 07/11/2017 21:10, Damo Brisbane wrote:
> > Hi,
> >
> > I am getting an error on custom fabio-1.5.2.ebuild
> > <https://github.com/damobrisbane/damo-overlay/
> blob/master/net-proxy/fabio/fabio-1.5.2.ebuild> -
> > "Not a git repository (or any of the parent directories)..." I've been
> > looking on web, trying some things, but still message is coming up,
> > appreciate suggestions. Note package is installing fine, just not sure
> > how to clean up this message.
> >
> >  Thanks in advance:
>
>
>
>
> Please post the ebuild. That's a git error (not a portage error) and it
> means you are trying to run "git " without running "git
> init" first
>
>
> >
> >
> >
> >>>> Emerging (2 of 2) net-proxy/fabio-1.5.2::damo-overlay
> >  * fabio-1.5.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...
> >  [ ok ]
> >  * Adding group 'fabio' to your system ...
> >  *  - Groupid: next available
> >  * Adding user 'fabio' to your system ...
> >  *  - Userid: 116
> >  *  - Shell: /sbin/nologin
> >  *  - Home: /var/lib/fabio
> >  *  - Groups: fabio
> >  *  - GECOS: added by portage for fabio
> >  *  - Creating /var/lib/fabio in /
> >>>> Unpacking source...
> >>>> Source unpacked in /tmp/portage/net-proxy/fabio-1.5.2/work
> >>>> Preparing source in
> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
> >>>> Source prepared.
> >>>> Configuring source in
> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
> >>>> Source configured.
> >>>> Compiling source in
> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
> > make -j5 -C
> > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
> hub.com/fabiolb/fabio
> > <http://github.com/fabiolb/fabio> install
> > make: Entering directory
> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
> hub.com/fabiolb/fabio
> > <http://github.com/fabiolb/fabio>'
> > *fatal: Not a git repository (or any of the parent directories): .git*
> > GOGC=off go install -ldflags "-X main.version="
> > make: Leaving directory
> > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/git
> hub.com/fabiolb/fabio
> > <http://github.com/fabiolb/fabio>'
> >>>> Source compiled.
> >
>
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>


fabio-1.5.2.ebuild
Description: Binary data

[gentoo-dev] "Not a git repository" error on ebuild

[Damo Brisbane]

Hi,

I am getting an error on custom fabio-1.5.2.ebuild

 - "Not a git repository (or any of the parent directories)..." I've been
looking on web, trying some things, but still message is coming up,
appreciate suggestions. Note package is installing fine, just not sure how
to clean up this message.

 Thanks in advance:



>>> Emerging (2 of 2) net-proxy/fabio-1.5.2::damo-overlay
 * fabio-1.5.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...
   [ ok ]
 * Adding group 'fabio' to your system ...
 *  - Groupid: next available
 * Adding user 'fabio' to your system ...
 *  - Userid: 116
 *  - Shell: /sbin/nologin
 *  - Home: /var/lib/fabio
 *  - Groups: fabio
 *  - GECOS: added by portage for fabio
 *  - Creating /var/lib/fabio in /
>>> Unpacking source...
>>> Source unpacked in /tmp/portage/net-proxy/fabio-1.5.2/work
>>> Preparing source in /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2
...
>>> Source prepared.
>>> Configuring source in
/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ...
>>> Source configured.
>>> Compiling source in /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2
...
make -j5 -C /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/
github.com/fabiolb/fabio install
make: Entering directory
'/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/
github.com/fabiolb/fabio'
*fatal: Not a git repository (or any of the parent directories): .git*
GOGC=off go install -ldflags "-X main.version="
make: Leaving directory
'/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/
github.com/fabiolb/fabio'
>>> Source compiled.

Re: [gentoo-dev] git checkout in ebuild?

[Damo Brisbane]

The git.r3 eclass method seems good practice for a specific commit. I'll
have a look at the snap site today (AEST) - see if I can find a tarball -
this seems preferable to commit.Thanks for the very helpful replies;

On Tue, Oct 17, 2017 at 8:04 AM, Kent Fredric  wrote:

> On Mon, 16 Oct 2017 13:31:53 +1000
> Damo Brisbane  wrote:
>
> > Hello,
> >
> > I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap
> > monitoring framework (https://github.com/intelsdi-x/snap). It seems the
> > current version (2.0.0) does not compile the golang binaries with some
> type
> > of recent grpc API incompatibility. I can successfully compile by going:
> >
> > go get ...
> > cd 
> > git checkout 1.3.0
> > make all
> >
> > This gets me the binaries (snaptel, snapteld); does anyone know if I can
> > put this process (git checkout..) into an .ebuild file (or some other
> > suggestion)?
> >
> > Cheers,
>
> emerge -va app-portage/eclass-manpages
> man 5 git-r3.eclass
>
> -> ECLASS_VARIABLES
>
> Look at almost any ebuild in tree using git-r3.eclass with a -
> version for examples of how you can use this if the eclass
> documentation isn't clear enough.
>
> But, these are forbidden in gentoo as a normal package.
>
> Typically, the solution there is finding a tarball, or producing
> a snapshot of the tree and publishing it somewhere.
>
> There's writing on that here:
>
> https://devmanual.gentoo.org/ebuild-writing/functions/src_
> unpack/svn-sources/index.html
>
> and
>
> https://devmanual.gentoo.org/ebuild-writing/functions/src_
> unpack/cvs-sources/index.html
>
> But there's no specific reference for Git sources, although the general
> rules and concepts still apply.
>
> Other commenters have mentioned using github tagged release's for
> tarballs, but even those aren't necessarily great, because:
>
> - Historically, the tarball's SHA1 can change due to github's tooling
> changing
> - Tags are not in any way immutable, and its been seen that people
>   forcibly replace tags in order to keep their git history tidy.
>   ( Which doesn't change the functional source code, bug can be
>   sufficient to change timestamps in the tarball, and thus, the SHA1 )
>
>

[gentoo-dev] git checkout in ebuild?

[Damo Brisbane]

Hello,

I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap
monitoring framework (https://github.com/intelsdi-x/snap). It seems the
current version (2.0.0) does not compile the golang binaries with some type
of recent grpc API incompatibility. I can successfully compile by going:

go get ...
cd 
git checkout 1.3.0
make all

This gets me the binaries (snaptel, snapteld); does anyone know if I can
put this process (git checkout..) into an .ebuild file (or some other
suggestion)?

Cheers,