Jump to content


Photo

Build questions


  • Please log in to reply
12 replies to this topic

#1 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 09:21

Hello, may I ask some build questions?

 

I try to update a recipe, in short take the source from other location (both git) and newer version. However I got an error:

do_fetch: Fetcher failure: Unable to resolve 'AUTOINC' in upstream git repository in git ls-remote output for

 

I have struggle with this for some time now. It seems like something is remembered from earlier build (with other source), or maybe I write wrong in the recipe file. However if I make a copy of my recipe and rename it. I can build it (with the new name). So the content of the recipe seems to be ok. Can some variables be 'cached' by the build system and stay, even if removed from the recipe?

 

How can I clear everything about a recipe build?

 

I have found these commands:

$ bitbake -c clean <recipe>
$ bitbake -c cleansstate <recipe>
 

However many files is still left. I have delete manually, but no luck with build.

 

I have looked into other recipe and it seems to be several ways to do things. For example why does some use "inherit gitpkgv"?

 

PS. I think you will tell me to show the recipe and maybe I need to do that, but first see if I can get some general tip.



Re: Build questions #2 WanWizard

  • Forum Moderator
    PLi® Core member
  • 45,707 posts

+737
Excellent

Posted 5 April 2019 - 10:39

Not sure what you mean by AUTOINC. Is that a typo, and do you mean AUTOREV (as in "give me the latest revision from the repo")?

 

There is also a 'cleanall' command that may do what you want.

 

And from the code:

# inherit gitpkgv
#
# PV = "1.0+gitr${SRCPV}"      # expands to something like 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b
# PKGV = "1.0+gitr${GITPKGV}"  # expands also to something like 1.0+gitr31337+4c1c21d7d
#
# or
#
# inherit gitpkgv
#
# PV = "1.0+gitr${SRCPV}" # expands to something like 1.0+gitr3+4c1c21d7dbbf93b0df336994524313dfe0d4963b
# PKGV = "${GITPKGVTAG}"  # expands to something like 1.0-31337+g4c1c21d
#                           if there is tag v1.0 before this revision or
#                           ver1.0-31337+g4c1c21d if there is tag ver1.0

see https://github.com/o...gitpkgv.bbclass


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), SAB Alpha Triple HD (S2+T2), Zgemma H3.2TC ©, Zgemma H6 (fallback), VU+Zero (fallback)

Many answers to your question can be found in our new and improved wiki.

note: I do not provide support via PM !

 


Re: Build questions #3 betacentauri

  • PLi® Core member
  • 4,979 posts

+233
Excellent

Posted 5 April 2019 - 14:21

It would be easier if you show us your changes. Eg switching from a Git source to a Tarball or similar need more changes.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Build questions #4 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 15:59

AUTOINC is something that the build system found out by it self. It is used for many packages (search the build tree for files that include it).

 

Here I show the things I think is related to this problem. Before...

inherit gitpkgv
PV = "1.1.0+git${SRCPV}"
PKGV = "1.1.0+git${GITPKGV}"
SRC_URI = "git://github.com/NathanaelA/minidlna.git;branch=origin_master;protocol=http \

Now...

SRCREV = "799e6cf505ec470b2bf0ae4118143380aa16b837"
SRC_URI = "git://git.code.sf.net/p/minidlna/git;protocol=https;branch=master;tag=${SRCREV} \

Note that I want to catch a tag (commit). If I don't use SRCREV (instead another name), I got a conflict. It seems SRCREV is set to AUTOINC automatically, if I don't set it.

do_fetch: Fetcher failure: Conflicting revisions (AUTOINC from SRCREV and 799e6cf505ec470b2bf0ae4118143380aa16b837 from the url) found, please spcify one valid value

 

I still don't understand the gitpkgv stuff. Is it only to name things, or is it used in some way towards the git repo? Since I don't understand it and I see other bb without it, I remove it.

 

Still it is strange that it works if I rename the bb file. So it isn't possible to modify an existing bb like this, but a new is okay. Therefor it seems the build system remember something.

 

//Michael



Re: Build questions #5 WanWizard

  • Forum Moderator
    PLi® Core member
  • 45,707 posts

+737
Excellent

Posted 5 April 2019 - 16:03

SRCREV is a git commit hash, and not a git tag. So you can't use SRCREV like that?

 

gitkpgv = package version from git. So it uses the placeholders in the PV and PKGV variable to replace them by (derivatives of) the commit hash, thus creating a unique version.

 

Alternatively, you need to maintain and bump your versions manually every time something is updated somewhere.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), SAB Alpha Triple HD (S2+T2), Zgemma H3.2TC ©, Zgemma H6 (fallback), VU+Zero (fallback)

Many answers to your question can be found in our new and improved wiki.

note: I do not provide support via PM !

 


Re: Build questions #6 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 16:13

Thanks for answer. However I need to think more about this pkgv stuff. I still don't get it. Shame on me, working with git for several years.

 

I can say that cleanall also fails, because of AUTOINC. However I can run cleanall if I go back to old version on bb. But it doesn't help.

 

commit and tag: Isn't that the same thing in this aspect. Possible to checkout both with the same command.



Re: Build questions #7 betacentauri

  • PLi® Core member
  • 4,979 posts

+233
Excellent

Posted 5 April 2019 - 16:15

And please look into this file in your build environment
https://github.com/O...o/reporefs.conf

Remove SRCREV if it is defined.
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Build questions #8 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 16:17

I notice that gitpkgv seems to look at SRCREV (thanks for the links earlier). So maybe I can run without specify tag= ...

I paste in the 3 lines about pkgv and removed branch and tag... it seems to work :-)

 

Now I need to verifiy more what actually happens.



Re: Build questions #9 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 16:21

About reporefs.conf: Yes there it can be set to AUTOREV. However I override. I don't change this file.

 

PS. Now I take a long walk in sunshine! I will take care of this another time.



Re: Build questions #10 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 5 April 2019 - 21:34

Is it possible to use the devtool modify <recipe> command?

 

If so, what is the appropriate thing to do before execute it.

 

PS. I normally do source env.source and export MACHINE before build, but it seems not to be enough for this command.



Re: Build questions #11 WanWizard

  • Forum Moderator
    PLi® Core member
  • 45,707 posts

+737
Excellent

Posted 5 April 2019 - 23:04

I have to pass that on, as said I don't use a standard bitbake environment.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), SAB Alpha Triple HD (S2+T2), Zgemma H3.2TC ©, Zgemma H6 (fallback), VU+Zero (fallback)

Many answers to your question can be found in our new and improved wiki.

note: I do not provide support via PM !

 


Re: Build questions #12 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 7 April 2019 - 09:42

I can say that it doesn't work, what I wrote above. I actually think I had tested that before. I begin think a little more and I think I do something that shouldn't be like that. This recipe takes the latest code from a git repo. So it can do. However if it should take a specific version. I think it should be different, i.e. a new recipe file. Normally the recipe (bb file) have a two divided name. The name and a version (separated with an underscore). If the recipe will be rename (if it will be changed to take a specific commit/tag), the problem I facing will not exist.



Re: Build questions #13 -M-

  • Senior Member
  • 37 posts

0
Neutral

Posted 8 April 2019 - 16:42

From another thread...

I don't think is a good design idea with modules that automatically takes the latest source. I think a release of OpenPLi should be the same independet of then it is built.


Which is where the reporefs.conf file comes in.

Develop uses AUTOREV for most recipes, as soon as we start our release process we generate a reporefs.conf from buildhistory data, pinning the release on a commit hash or version.

This together with previous information in this thread... I now begin to understand what is going on and know why it didn't work for me. Thanks!
Directiv from reporefs was in conflict with my change. If the recipe will take a specific version, then it shouldn't be in reporefs. On the contrary. If taken the latest commit in the recipe, we can control which by the reporefs.

//Newbie




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users