<div dir="ltr"><div>Hi Andrew,<br><br></div>Thanks for looking at this. See my recipe below. I've left the bits related to systemd service but I don't think they matter for this. I'm using an old implementation of Perforce (2010) in case this matters. I've tried going back to the old perforce.py fetcher but I get a license error... do you know if it would be easy to revert to the old version in my bitbake folder until we make this work?<br><br>DESCRIPTION = "Dummy recipe to fetch from Perforce"<br>SECTION = "PerforceRecipes"<br>LICENSE = "CLOSED"<br>PR = "r0"<br><br>inherit cmake<br>DEPENDS = "boost alsa-tools"<br><br>P4USER = "myuser"<br>P4PASSWD = ""<br>P4PORT = "<a href="http://192.168.1.55:1666">192.168.1.55:1666</a>"<br>FETCHCMD_p4 = "/usr/local/bin/p4"<br><br>SRC_URI = " \<br>p4://${P4USER}:${P4PASSWD}@myrepo/myfolder/...; \<br>file://perforce-recipe.service \<br>"<br>SRCREV = "${AUTOREV}"<br>S = "${WORKDIR}/p4"<br><br>do_install_append () {<br>    install -d ${D}${systemd_unitdir}/system<br>    install -m 0644 ../perforce-recipe.service ${D}${systemd_unitdir}/system<br>}<br><br>NATIVE_SYSTEMD_SUPPORT = "1"<br>SYSTEMD_PACKAGES = "perforce-recipe"<br>SYSTEMD_SERVICE_${PN} = "perforce-recipe.service"<br><br>SYSTEMD_AUTO_ENABLE = "disable"<br><br>FILES_${PN} = "${systemd_unitdir} ${bindir}"<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-28 15:27 GMT+01:00 Andrew Bradford <span dir="ltr"><<a href="mailto:andrew@bradfordembedded.com" target="_blank">andrew@bradfordembedded.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Katu,<br>
<span class=""><br>
On 08/28 08:56, Katu Txakur wrote:<br>
> 2017-08-11 13:52 GMT+01:00 Andrew Bradford <<a href="mailto:andrew@bradfordembedded.com">andrew@bradfordembedded.com</a>>:<br>
</span><div><div class="h5">> On 08/11 11:34, Katu Txakur wrote:<br>
> > > 2017-08-07 12:17 GMT+01:00 Andrew Bradford <<a href="mailto:andrew@bradfordembedded.com">andrew@bradfordembedded.com</a><br>
> > >:<br>
> > > > On 08/02 10:28, Paul Eggleton wrote:<br>
> > > > > On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:<br>
> > > > > > I'm still having problems fetching from Perforce. Is there any<br>
> > > > > > documentation based on the latest implementation of the<br>
> > > > > > poky/bitbake/lib/bb/fetch2/<wbr>perforce.py file?<br>
> > > ><br>
> > > > There's some documentation now in the official Yocto Project<br>
> > > > documentation location for bitbake fetchers [1].  Prior to my changes<br>
> > > > there was very little if any documentation, afaik.<br>
> > > ><br>
> > > > [1]: <a href="http://www.yoctoproject.org/docs/2.3.1/bitbake-user-" rel="noreferrer" target="_blank">http://www.yoctoproject.org/<wbr>docs/2.3.1/bitbake-user-</a><br>
> > > > manual/bitbake-user-manual.<wbr>html#perforce-fetcher<br>
> > > ><br>
> > > > > > 2017-07-25 10:05 GMT+01:00 Katu Txakur <<a href="mailto:katutxakurra@gmail.com">katutxakurra@gmail.com</a>>:<br>
> > > > > > > I'm upgrading a recipe that fetches the source code from<br>
> > Perforce.<br>
> > > > > > ><br>
> > > > > > > The old recipe was:<br>
> > > > > > ><br>
> > > > > > > SRC_URI = " \<br>
> > > > > > >  Â p4://${P4USER}:${P4PASSWD}:${<wbr>P4HOST}:${P4PORT}@Depot/path/<wbr>pe<br>
> > > > > > > rforce/...;module=local/path/<wbr>relativeto/p4;label=${<wbr>P4CHANGELIST}<br>
> > \<br>
> > > > > > >  Â "<br>
> > > > > > ><br>
> > > > > > > With the new version of /lib/bb/fetch2/perforce.py, I had to set<br>
> > > > P4PORT<br>
> > > > > > > outside SRC_URI, leaving the recipe with:<br>
> > > > > > ><br>
> > > > > > > SRC_URI = " \<br>
> > > > > > >  Â p4://${P4USER}:${P4PASSWD}@<wbr>Depot/path/perforce/...;<wbr>module=<br>
> > > > > > > local/path/relativeto/p4;<wbr>label=${P4CHANGELIST} \<br>
> > > > > > >  Â "<br>
> > > > > > ><br>
> > > > > > > The Perforce fetcher kind of works, but it seems to be ignoring<br>
> > the<br>
> > > > > > > "module" and the "label" attributes. After reading the Python<br>
> > script<br>
> > > > I can<br>
> > > > > > > see that after the "@", only the substring before the first ";"<br>
> > is<br>
> > > > used.<br>
> > > ><br>
> > > > Sorry for not making the label change more clear, but you should be<br>
> > able<br>
> > > > to simply set SRCREV="labelname" and have the functionality you desire.<br>
> > > > However, we don't use labels very often internally, so the use of<br>
> > labels<br>
> > > > in SRCREV isn't tested that often by me.<br>
> > > ><br>
> > ><br>
> > > I don't use labels that much either, however, I used to be able to write<br>
> > > the changeslist number as a label and it would<br>
> > > fetch the code for that changelist. This doesn't work using SRCREV =<br>
> > > "changelistnumber"<br>
> ><br>
> > This does work for me using oe-core morty branch and bitbake<br>
> > 1.32 which is the versions where these changes were first applied and<br>
> > where I did my testing.<br>
> ><br>
> > Like I have a recipe which I put:<br>
> ><br>
> > SRCREV = "184127"<br>
> ><br>
> > The p4 fetcher will go fetch changelist 184127 of the SRC_URI path in<br>
> > perforce.<br>
> ><br>
> > Or if I put:<br>
> ><br>
> > SRCREV = "${AUTOREV}"<br>
> ><br>
> > Then it'll fetch the HEAD/tip of the SRC_URI path in perforce.<br>
> ><br>
> > Is this not working the same way with poky now?<br>
> ><br>
><br>
> I'm using yocto pyro with bitbake 1.34.0. When I first fetch the code for<br>
> my recipe, it gets the latest changelist.<br>
> I submit a change and the next time, the recipe thinks there nothing new to<br>
> fetch. Also, using SRCREV = "184127"<br>
> doesn't work for me, it always gets the latest changelist.<br>
<br>
</div></div>Can you post the recipe where this is failing for you?<br>
<br>
I could then try to recreate this issue in a sandbox depot we have in<br>
our perforce server and see what's going on.<br>
<div><div class="h5"><br>
> ><br>
> > > > This change to using labels, changelist numbers, and allowing the use<br>
> > of<br>
> > > > AUTOREV was made so that the perforce fetcher would act more like the<br>
> > > > other source code control system fetchers.  Prior to my changes to the<br>
> > > > p4 fetcher, the way that recipes using p4 had to be written seemed<br>
> > > > rather awkward to me.  The way it is now isn't perfect, but it's closer<br>
> > > > to how the other fetchers act, I think (and hope).<br>
> > > ><br>
> > ><br>
> > > > > > Is there a way to set module and label/changelist? I have several<br>
> > > > folders<br>
> > > > > > > per recipe that I need to map to different subfolders and with<br>
> > the<br>
> > > > current<br>
> > > > > > > script some of the folders don't get fetched.<br>
> > > ><br>
> > > > I'm not sure I understand enough about how you use perforce and what<br>
> > you<br>
> > > > mean by mapping different subfolders.  Can you explain this in a more<br>
> > > > expanded way to me?  Maybe with some examples?<br>
> > > ><br>
> > ><br>
> > > What I mean by this is taking folders in different locations in Perforce<br>
> > > and fetch them to a custom folder structure inside the {WORKDIR}/p4<br>
> > folder.<br>
> > > This is an example of how I was doing this with the old version of the<br>
> > > fetcher:<br>
> > ><br>
> > > #leave blank, "", for latest revision<br>
> > > P4CHANGELIST = "${PR}"<br>
> > > S = "${WORKDIR}"<br>
> > > SRC_URI = " \<br>
> > > p4://${P4USER}:${P4PASSWD}:${<wbr>P4HOST}:${P4PORT}@Depot/<wbr>project<br>
> > 1/folder1/...;module=<wbr>subfolderunderp4/src/;label=${<wbr>P4CHANGELIST}<br>
> > > \<br>
> > > p4://${P4USER}:${P4PASSWD}:${<wbr>P4HOST}:${P4PORT}@Depot/<wbr>project<br>
> > 2/folder3/...;module=<wbr>subfolderunderp4/pkg/;label=${<wbr>P4CHANGELIST}<br>
> > > \<br>
> > > "<br>
> > ><br>
> > > Where folder1 contains the src files and folder3 contains the pkg<br>
> > > information. These need to be in an specific folder structure for the<br>
> > > recipe to work.<br>
> > > I had some issue when adding more than one line because it was trying to<br>
> > > copy everything to the same p4 folder.<br>
> ><br>
> > Ah, yeah... Sorry, that is a bit of a shortcoming of my changes.  The<br>
> > reason I made this change is because putting the given SRC_URI's<br>
> > repository directly into a directory like ${WORKDIR}/p4/ is how some of<br>
> > the other fetchers operate and it makes the automatic tasks just work<br>
> > correctly.  This is how the git fetcher does things so I tried to mimmic<br>
> > that but maybe I missed some nuance in how the git fetcher deals with<br>
> > more than one SRC_URI line being a git repo.  I hadn't realized that<br>
> > there was users of the p4 fetcher who did things like you are doing,<br>
> > sorry.<br>
> ><br>
> > I think it should be reasonably easy to make a patch to the p4 fetcher<br>
> > which will put each SRC_URI line which uses the p4 fetcher into its own<br>
> > directory within the ${WORKDIR}/p4/ directory such that it supports your<br>
> > style of fetching.  This then will likely require your recipe to know<br>
> > that this is the directory structure and properly change into<br>
> > directories as needed, but it sounds like you already comprehend that.<br>
> > And for users of the p4 fetcher who only use one SRC_URI line, I believe<br>
> > they would just need to set the S variable correctly to the directory<br>
> > name within ${WORKDIR}/p4/ to get the current operation.<br>
><br>
</div></div><span class="">> I have been looking at this and it wasn't straight forward for me... I<br>
> don't have much experience with this. I will continue trying but I might<br>
> need some help.<br>
> It's not only not being able to fetch more than one SRC_URI. We are also<br>
> loosing the flexibility of fetching different changelists for each line.<br>
> I'm not sure if this can be solved in this new fetcher whilst keeping git<br>
> and p4 "similar" as git doesn't work this way afaik.<br>
<br>
</span>It sounds like you really just want to revert to how the p4 fetcher used<br>
to work.  My changes were because I wanted the p4 fetcher to work more<br>
like the git and svn fetchers.  But that doesn't sound like what you<br>
want.<br>
<br>
My p4 fetcher changes which are impacting you on poky's pyro are these:<br>
<br>
35081f55185a8a9804c21b16cd4600<wbr>ba70646a10 bitbake: bitbake-user-manual: Addeds support for the Perforce Fetcher<br>
40f3099e8ec5c6f3a8b7f3d0e90f1c<wbr>65c388ee77 base.bbclass: p4 fetcher supports srcrev<br>
26447a0d0bf5ceaac382a78c1dbd00<wbr>807dbab706 bitbake: fetch2/perforce: Rework to support SRCREV and P4CONFIG<br>
<br>
But that last one will run into conflicts if you just try to revert it<br>
directly due to having other commits since then which git can't easily<br>
figure out, but if you revert all of these commits too, then you may<br>
have to redo some of the changes they made which are related to general<br>
things and are not p4 specific.  Commits you'll want to look at are:<br>
<br>
b16192c93834d0a6530169557aa341<wbr>22e1417bcf bitbake: fetch2: don't use deprecated bb.data APIs<br>
6c611d697f9c03867c938cba1b481f<wbr>38eebed8bf bitbake: fetch2: Rename "setup_revisons" to "setup_revisions"<br>
38438b6cf42fb7ad45b9a901f57913<wbr>af7e7591a3 bitbake: fetch2: obey BB_ALLOWED_NETWORKS when checking network access<br>
1fce7ecbbb004a5ad82da3eef79cfd<wbr>52b276708d bitbake: bitbake: remove True option to getVar calls<br>
ab09541d5517da9b1a23923ea8f5c2<wbr>6ddf745084 bitbake: fetch2: preserve current working directory<br>
26447a0d0bf5ceaac382a78c1dbd00<wbr>807dbab706 bitbake: fetch2/perforce: Rework to support SRCREV and P4CONFIG<br>
<br>
I haven't actually reviewed any of these commits after the "preserve<br>
current working directory" one as I'm still doing my day-to-day work on<br>
the morty branch of oe-core and bitbake 1.32.  But possibly one of these<br>
commits are unintentionally impacting your ability to specify SRCREV and<br>
that's worth checking into.<br>
<br>
Thanks,<br>
Andrew<br>
</blockquote></div><br></div>