On Fri, Aug 12, 2011 at 9:55 PM, Christopher Friedt <chrisfriedt@gmail.com> wrote:


On Fri, Aug 12, 2011 at 2:48 PM, Christopher Friedt

<chrisfriedt@gmail.com> wrote:

> Is there any way to generate the manifest file using 'ebuild' so that

> it will just read the files from my DISTDIR rather than trying to

> fetch them?



Got it...



FETCHCOMMAND="echo" ebuild A/B/B.ebuild digest



But this is not the solution!
I have the same tree for my embedded systems, and I do the same as you.
My header looks like this:
EAPI="3"
inherit cmake-utils flag-o-matic
MY_P="${P}-Source"


SRC_URI="${MY_P}.tar.bz2"
RESTRICT="fetch" # This file resides locally and can't be fetched

Please check the EAPI you use, maybe it needs to change.
Also look close on the SRC_URI, it has just the name of the file.


I'm also using repoman to generate all my manifests like this:
cd portage_local_tree; repoman -f manifest

This is much better way to do it.

Regards,
Kfir

On Fri, Aug 12, 2011 at 5:23 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:
> But this is not the solution!
> I have the same tree for my embedded systems, and I do the same as you.
> My header looks like this:
> EAPI="3"
> inherit cmake-utils flag-o-matic
> MY_P="${P}-Source"
> SRC_URI="${MY_P}.tar.bz2"
> RESTRICT="fetch" # This file resides locally and can't be fetched
>
> Please check the EAPI you use, maybe it needs to change.
> Also look close on the SRC_URI, it has just the name of the file.
> I'm also using repoman to generate all my manifests like this:
> cd portage_local_tree; repoman -f manifest

Hmm... I'm using EAPI=4 in this ebuild. The SRC_URI is OK, since it
works with FETCHCOMMAND=echo and properly hashes the files in DISTDIR.
The inherit line is unnecessary AFAIK.

I wouldn't doubt that it was a bug in the portage version I'm using.
It's been 43 days since my last emerge --sync, but I can't update ATM
because I don't want to break any APIs in the (rather large) project
I'm building right now.

Oh well - problem has been solved anyway.

C

On Sat, Aug 13, 2011 at 2:00 AM, Christopher Friedt <chrisfriedt@gmail.com> wrote:


On Fri, Aug 12, 2011 at 5:23 PM, Kfir Lavi <lavi.kfir@gmail.com> wrote:

> But this is not the solution!

> I have the same tree for my embedded systems, and I do the same as you.

> My header looks like this:

> EAPI="3"

> inherit cmake-utils flag-o-matic

> MY_P="${P}-Source"

> SRC_URI="${MY_P}.tar.bz2"

> RESTRICT="fetch" # This file resides locally and can't be fetched

>

> Please check the EAPI you use, maybe it needs to change.

> Also look close on the SRC_URI, it has just the name of the file.

> I'm also using repoman to generate all my manifests like this:

> cd portage_local_tree; repoman -f manifest



Hmm... I'm using EAPI=4 in this ebuild. The SRC_URI is OK, since it

works with FETCHCOMMAND=echo and properly hashes the files in DISTDIR.

The inherit line is unnecessary AFAIK.



I wouldn't doubt that it was a bug in the portage version I'm using.

It's been 43 days since my last emerge --sync, but I can't update ATM

because I don't want to break any APIs in the (rather large) project

I'm building right now.



Oh well - problem has been solved anyway.



C



Yes you right, the inherit line is not needed.
What I was trying to say is that I'm not using FETCHCOMMAND=echo,
and it works for me.

I would also forward this message to gentoo-dev.



Regards,
Kfir

В Сбт, 13/08/2011 в 10:14 +0300, Kfir Lavi пишет:
> I wouldn't doubt that it was a bug in the portage version I'm
> using.
> It's been 43 days since my last emerge --sync, but I can't
> update ATM
> because I don't want to break any APIs in the (rather large)
> project
> I'm building right now.

Upgrading portage does not breaks API.

> Oh well - problem has been solved anyway.

If something still requires FETCHCOMMAND, I really encourage you to open
bug at bugs.gentoo.org.

> I would also forward this message to gentoo-dev.

Oh, no! Bug reports should go to bugs.gentoo.org.

With kind regards,
--
Peter.

On Sat, Aug 13, 2011 at 8:17 AM, Peter Volkov <pva@gentoo.org> wrote:
> Oh, no! Bug reports should go to bugs.gentoo.org.

Well... I was hoping I could just let this one slide by ... but ok

C

Odd... now that I'm trying it again, it's working fine... and I
haven't even touched my PC since yesterday except for email.

Oh well - problem solved in any case.

C

On Sat, Aug 13, 2011 at 8:26 AM, Christopher Friedt
<chrisfriedt@gmail.com> wrote:
> On Sat, Aug 13, 2011 at 8:17 AM, Peter Volkov <pva@gentoo.org> wrote:
>> Oh, no! Bug reports should go to bugs.gentoo.org.
>
> Well... I was hoping I could just let this one slide by ... but ok
>
> C
>