I use Jethro, a simple local git repo and this recipe: --> DESCRIPTION = "Simple helloworld application + git + AUTOREV" SECTION = "examples" LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" SRCREV = "${AUTOREV}" SRC_URI = "git:///home/genius/yocto-repos/simple-hello-world-git.git;protocol=file;branch=master" PV = "0.0+git${SRCPV}" S = "${WORKDIR}/git" do_compile() { ${CC} simple-hello-world-git.c -o simple-hello-world-git } do_install() { install -d ${D}${bindir} install -m 0755 simple-hello-world-git ${D}${bindir} } <-- I get this result when I make modifications to the git repo. PV="0.0+gitAUTOINC+ecf1f0bc87" armv7a-vfp-neon/simple-hello-world-git_0.0+git0+ecf1f0bc87-r0_armv7a-vfp-neon.ipk PV="0.0+gitAUTOINC+2880461cde" armv7a-vfp-neon/simple-hello-world-git_0.0+git0+2880461cde-r0_armv7a-vfp-neon.ipk PV="0.0+gitAUTOINC+b6558dd387" armv7a-vfp-neon/simple-hello-world-git_0.0+git0+b6558dd387-r0_armv7a-vfp-neon.ipk I can somehow understand the gitAUTOINC part in PV, but I thought that git0 would be automatically incremented to git1 git2 in the package names as the commit id changes. Isn't this what AUTOREV/AUTOINC were supposed to do? Do you see anything strange is my recipe? Who is supposed to increment the AUTOINC in the package name?
With morty things seem to work as expected: simple-hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk simple-hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk Does this have anything to do with the fact that the PR server is being used with morty or is there some patch needed for jethro to work? NOTE: Started PRServer with DBfile: /tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/res-custom-morty-multi-v7-core-image-minimal/build/build/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40368, PID: 18681
Answering to myself: It's not the PR_Server, I also use it on Jethro;)
On a second thought running it a couple of times with the PR Sever on jethro it seems to work as well. Can you please confirm that the component responsible for replacing/incrementing AUTOINC in the package name is the PR_server? And if so update the doc?
(In reply to comment #3) > On a second thought running it a couple of times with the PR Sever on jethro > it seems to work as well. > > Can you please confirm that the component responsible for > replacing/incrementing AUTOINC in the package name is the PR_server? Yes, I confirm that this is how it works. Bitbake (and its build environment) does not track the history of package versions for this purpose. AUTOINC in this case is comparable to PR. If PR server is _not_ in use, AUTOINC in the package version is simply replaced by '0'. If PR server is in use, it keeps track of the package versions and bumps the number when revision changes. > And if so update the doc? Yes, seems that this hasn't been covered in the docs. Assigning to Scott for documentation update.
Hi, Accepted this and am looking into a doc solution for it. Also, setting the days to 3 to get me off Jolly's list for this particular bug. Scott
Hi, Setting to NEEDINFO and putting the target to 2.3 M4 now. Scott
Hi, There is a section in the dev-manual about incrementing a package revision number at http://www.yoctoproject.org/docs/2.3/mega-manual/mega-manual.html#incrementing-a-package-revision-number. Right now, this section describes two ways to accomplish this: 1) using a PR Service, and 2) manually by bumping the PR value. I am thinking that a third method exists now based on this issue. That third method would be to use the AUTOINC variable when you do not have a PR Service running. Is this true? If so, I can add a new subsection here describing that situation. Please advise. Additionally, we do not document "AUTOINC" anywhere in the mainstream YP documentation. Should we be doing this? Would this be needed in the glossary of the ref-manual, bb-manual, or both? Thanks, Scott
Uh-oh, this bug had somehow dropped below my radar. I'm sorry for the slow response time. (In reply to comment #7) > There is a section in the dev-manual about incrementing a package revision > number at > http://www.yoctoproject.org/docs/2.3/mega-manual/mega-manual. > html#incrementing-a-package-revision-number. Right now, this section > describes two ways to accomplish this: 1) using a PR Service, and 2) > manually by bumping the PR value. I am thinking that a third method exists > now based on this issue. That third method would be to use the AUTOINC > variable when you do not have a PR Service running. Is this true? If so, I > can add a new subsection here describing that situation. Please advise. Hmm, good question. Clearly, the combined usage of AUTOREV and SRCPV should be described more clearly. Technically, describing the usage of AUTOREV and SRCPV would not belong under "Incrementing a Package Revision Number" because it does not change the package _revision_ (but package version). However, that would probably be a logical place for the description. A description how it works: SRCPV can be used to automatically update the package version, whenever revision (SRCREV) of the package changes. You can do this by including SRCPV in the PV variable e.g. (PV="1.0+git${SRCPV}"). Internally, SRCPV will be substituted with "AUTOINC+<source revision>" by the build system. When writing packages the AUTOINC placeholder will be replaced by a number: If PR Service is used it will increment the number (similarly to PR), resulting in linearly increasing package versions. However, if PR Service is not enabled, AUTOINC will simply be replaced by 0, resulting in changing package versions (because source revision is included) but not increasing linearly. I hope you are able to write an entry to the manual based on the description above. Please assign back to me if you need more clarification or have further questions. > Additionally, we do not document "AUTOINC" anywhere in the mainstream YP > documentation. Should we be doing this? Would this be needed in the > glossary of the ref-manual, bb-manual, or both? Good question, again. It could be mentioned in the text but it's not that significant because it's not variable, but, just an internal placeholder value that gets replaced by PR Service, or, by bitbake if PR Service is not in use.
I really am having trouble understanding all of this. First, let's look at where we put this new information. You indicated that since we are talking about incrementing package versions and not package revisions, that the new information would not belong in that "Incrementing a Package Revision Number" section I pointed out. But then you say in your comment that it would probably be a logical place for the description. This is confusing to me. However, there is a bit mentioned in the introductory part of that section (http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-package-revision-number) in the second paragraph that talks about things hinging on version numbering increases in a linear fashion. So I am thinking maybe we could still use a third subsection (i.e. 5.18.2.3) that specifically addresses on what the user can do to get version numbers to increase linearly. I would introduce that section as such up there in the start of 5.18.2 along with how I introduce the existing two subsections as ways to bump the PR. Do you think this placement would work? Scott
(In reply to comment #9) > I really am having trouble understanding all of this. First, let's look at > where we put this new information. You indicated that since we are talking > about incrementing package versions and not package revisions, that the new > information would not belong in that "Incrementing a Package Revision > Number" section I pointed out. But then you say in your comment that it > would probably be a logical place for the description. This is confusing to > me. Sorry, that was probably quite confusing. What I tried to say is that the heading (Incrementing a Package Revision Number) would become technically a bit misleading/incorrect if we make that addidition, i.e. describe AUTOREV/SRCPV in a third subsection. Probably the heading could just be changed to something like "Incrementing a Package Version Number". > However, there is a bit mentioned in the introductory part of that section > (http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual. > html#incrementing-a-package-revision-number) in the second paragraph that > talks about things hinging on version numbering increases in a linear > fashion. So I am thinking maybe we could still use a third subsection (i.e. > 5.18.2.3) that specifically addresses on what the user can do to get version > numbers to increase linearly. Yes, I think that is a logical thing to do. Probably the main heading should be changed as I mentioned above, because even the current text talks about "increasing version numbers linearly". > I would introduce that section as such up > there in the start of 5.18.2 along with how I introduce the existing two > subsections as ways to bump the PR. Do you think this placement would work? Sounds good. It just becomes slightly more complicated as using SRCPV bumps PV, not PR :) I.e. need to have wording something like "...then the value of the PV or PR variable needs to be increased..."
It appears the question has been answered. If you still have questions please reask the question and place this back into NEEDINFO.
Hi Markus, I have updated the manuals and need your review. In thinking about this a bit more, I decided not to bury the new section describing how to make sure you get linear package revision numbers inside that existing section. I made a new section specifically for that that follows the existing section on how to increment the package version number. The reason I did that is that original section was so focused on how to increment the version number I could not create a meaningful organization that mixed the two. However, I did reference the new section from within that existing section. See the second paragraph in http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-package-version-number for the reference. For the new section, see http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-package-revision-number, which describes the nuts and bolts of this bug. I also referenced the new section in the AUTOREV varaiable here http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-AUTOREV and in the SRCREV variable here http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-SRCREV. The final build for the YP 2.3 release is coming fast. I would like to get a sanity check on this new section as I made some assumptions on my understanding of this issue to create the new information. Thanks, Scott
I'm not entirely happy with it, yet. The text is partly a bit misleading/ambiguous. Some background info: The naming/terminology is annoyingly subtle around this subject. The "package version" that we're talking about is the version of the binary package that is eventually built and installed into the image. The *binary package version* is composed of two components, namely version and revision (there's actually a third optional component, 'epoch', but let's forget it here) which are taken from the PV and PR variables. PV and PR should probably be called "recipe version" and "recipe revision". So, whenever the binary package output changes the binary package version should be changed and this can be accomplished by changing PR and/or PV. Now, some comments to the text. I still think that it could be logical to cover both PV and PR under "Incrementing a Package Version Number". That is, mention both PV and PR in the introductory section (i.e binary package version is composed of both and either of them needs to be changed when the package output changes) and have the new section as a subsection of that. However, if you think that is not possible (and I understand that it would probably require larger overhaul of the text), then the heading texts need to be swapped. I.e. 5.18.2. would be "Incrementing a Package Revision Number" and 5.18.3. would be "Automatically Incrementing a Package Version Number". I think this would best describe the new section. In addition, I would suggest a new wording for paragraphs 2 and 3 of the new section in order to clarify the terminology. For example this way: --------- 8<8<8< ---------------- Furthermore, you need to reference SRCPV in PV in order to automatically update the package version whenever the revision of the source code changes. Here is an example: PV = "1.0+git${SRCPV}" The OpenEmbedded build system substitutes SRCPV with the following: AUTOINC+source_code_revision --------- 8<8<8< ---------------- PaulE has a lot better insight into the history of variable naming and terminology and might have ideas about how to best formulate the text.
Hi Markus, Thanks for the background information. That in itself was invaluable in letting me rewrite this section. You will see that I have integrated everything under one section heading now. After understanding it better it does make sense to gather it all together. If you would not mind, I would like you to look over all the sections. I touched nearly everything trying to be clear with terminology. Here is the very top section - http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#working-with-packages. The new section is http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-binary-package-revision-number, which is part of http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-binary-package-version. Make sure that I am treating PR and PV correctly. My one point of "fogginess" is the treatment of these two variables. Initially, I wanted to treat them equally, but the PR Service wiki page (https://wiki.yoctoproject.org/wiki/PR_Service) really focuses on PR with regards to all this. So I am thinking that the main purpose of the PR Service is to deal with PR and then PV gets dealt with somewhat automatically as a result of PR changing? Not sure. Anyway, I think this is a much better section. Let me know what you think. Thanks, Scott
Markus, Adding a note here that I implemented your email suggestions. I will leave the bug in IN PROGRESS REVIEW for now. thanks, Scott http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html#incrementing-a-binary-package-version
Markus, I am marking this bug as RESOLVED now and putting the doc flag to "done". I think we are good for it. Scott
Agree, I think we're fine, for now. To the reporter: please re-open if you're not satisfied.