24 replies to this topic

[-M-]

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.

[WanWizard]

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

[betacentauri]

It would be easier if you show us your changes. Eg switching from a Git source to a Tarball or similar need more changes.

[-M-]

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

[WanWizard]

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.

[-M-]

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.

[betacentauri]

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

Remove SRCREV if it is defined.

[-M-]

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.

[-M-]

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.

[-M-]

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.

[WanWizard]

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

[-M-]

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.

[-M-]

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

[-M-]

How should I update my local repo. I have done this:
$ git checkout develop
$ git fetch
$ git pull

However it says that several meta- are modified (new commits). I did this:
$ git submodule update --recursive

Now it is okay. Is this the prefered and correct method?

PS. Maybe this information can be added to https://wiki.openpli.org/Git-commands
 

[-M-]

I still cannot build, I got:

ERROR: enigma2-2.7+gitAUTOINC+c858670401-r0 do_populate_lic: QA Issue: enigma2: The LIC_FILES_CHKSUM does not match for file://LICENSE;md5=751419260aa954499f7abaabaa882bbe

 

Can I have destroy something locally?

[betacentauri]

You can call:

make update

It pulls latest head and updates submodules. You can look into the makefile to see which git commands are called.

 

Did you change enigma2 bitbake or do you use own e2 repository?

[WanWizard]

There has been an update to the license file, I haven't pushed the hash update yet. 

 

edit: fix pushed.

Edited by WanWizard, 9 May 2019 - 17:35.

[-M-]

Thanks!

 

#1 How is it to build different things in the same tree. If I like to build for two boxes. Is it okay to do like this:
$ cd build
$ source env.source
$ MACHINE=xxXXXX bitbake openpli-enigma2-image
$ MACHINE=yyYYYY bitbake openpli-enigma2-image
 

#2 How about jump between different versions. For example like this:
$ git checkout  release-6.2
$ cd build
$ source env.source
$ MACHINE=xxXXXX bitbake openpli-enigma2-image
$ cd ..
$ git checkout develop
$ cd build
$ MACHINE=xxXXXX bitbake openpli-enigma2-image
$ cd ..
$ git checkout release-7.0
$ cd build
$ MACHINE=xxXXXX bitbake openpli-enigma2-image

Is it safe to jump between version like this (both forward and backwards)? Will all be in correct versions or do I need to do some kind of clean in between and get a total rebuild.

[WanWizard]

It is not a problem to build multiple images from the same tree. We do so for 70+ different receivers on a daily basis.

 

You will have to make sure the feed URL's are configured properly, you don't want to mix packages from different versions. We don't checkout, we use different directories to build from. to avoid mixing up different versions.

 

Obviously, you need to diskspace for that, we need around 800GB for a complete build run for a single version, with rm_work enabled, buildhistory disabled, and regular temp and cache cleanup.

[blzr]

#2 How about jump between different versions. For example like this:
$ git checkout  release-6.2
$ cd build
$ source env.source
$ MACHINE=xxXXXX bitbake openpli-enigma2-image
$ cd ..
$ git checkout develop
$ cd build
$ MACHINE=xxXXXX bitbake openpli-enigma2-image
$ cd ..
$ git checkout release-7.0
$ cd build
$ MACHINE=xxXXXX bitbake openpli-enigma2-image

Is it safe to jump between version like this (both forward and backwards)? Will all be in correct versions or do I need to do some kind of clean in between and get a total rebuild.

 

In addition, after swutching version, before build you'd need:

$ git pull
$ git submodule update --init

and regarding 'cleanup' I always simply delete the tmp completely, and build from scratch, to avoid any strange problems during build...
(not sure, possibly you can clean just selectvely (sstate only?) but I always go with atomic option ;-))