Re: [yocto] Perforce fetcher ignores module and label
Hi Katu,
Sorry for my delay in responding.
On 09/14 11:13, Katu Txakur wrote:
> Have you had time to look at this? I tried to go back to the old perforce
> fetcher but I got a license error and I couldn't work around it.
On the pyro branch of poky, if you revert these two commits, in this
order:
35081f55185a8a9804c21b16cd4600ba70646a10 "bitbake: bitbake-user-manual: Addeds
support for the Perforce Fetcher"
40f3099e8ec5c6f3a8b7f3d0e90f1c65c388ee77 "base.bbclass: p4 fetcher supports
srcrev"
And then apply the patch attached, this should bring the pyro branch of
poky back to how the old perforce fetcher worked. I have tested having
two different depot paths in a recipe SRC_URI and they both are fetched
how I believe you want them to be, next to each other in WORKDIR.
Just be aware, I believe this loses the ability to use
SRC_REV="${AUTOREV}" to automatically find the newest changelist which
my previous changes introduced.
The format for SRC_URI that I tested was like:
SRC_URI =
"p4://username:password:server.hostname.example.com:1666@depot/path/to/directory/...;cset=178374"
You should also be able to specify P4PORT to set the host and port
number but you may then lose the ability to have the username and
password (although I haven't tested this and don't remember how it used
to work). You should also be able to specify the P4DATE variable in
your recipe to apply to all p4 fetches instead of using the "cset="
parameter, and instead of using the "cset=" param you should also be
able to specify a "revision=" for a single file or a "label=" for a
label. I've only tested using the "cset=" way as the others don't
easily apply to how my team internally uses perforce, sorry.
I think I understand how I could make the current perforce fetcher
(without the above reverts or attached patch) do the multi-directory
fetching that you want, but I don't personally want to do that in my
workflow so I'm not going to spend a bunch of time implementing it now.
But if you do implement it, I'd be happy to test patches for you.
Thanks,
Andrew
> 2017-08-31 18:54 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com>:
>
> > Hi Katu,
> >
> > On 08/28 17:43, Katu Txakur wrote:
> > > 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?
> >
> > Sorry, I've been swamped this week and haven't been able to look into
> > this yet. This coming weekend is a holiday weekend in the USA, too.
> > But I plan to look at this early next week, hope that's OK.
> >
> > We should be able to create a patch series to revert my changes so you
> > can go back to the old perforce fetcher. It might also be worth
> > investigating how to take the current perforce fetcher and enable some
> > of the use cases that you have (but we can do this after we successfully
> > revert).
> >
> > I'll try to send a patch to you next week for the reverting.
> > Thanks,
> > Andrew
> >
> > > DESCRIPTION = "Dummy recipe to fetch from Perforce"
> > > SECTION = "PerforceRecipes"
> > > LICENSE = "CLOSED"
> > > PR = "r0"
> > >
> > > inherit cmake
> > > DEPENDS = "boost alsa-tools"
> > >
> > > P4USER = "myuser"
> > > P4PASSWD = ""
> > > P4PORT = "192.168.1.55:1666"
> > > FETCHCMD_p4 = "/usr/local/bin/p4"
> > >
> > > SRC_URI = " \
> > > p4://${P4USER}:${P4PASSWD}@myrepo/myfolder/...; \
> > > file://perforce-recipe.service \
> > > "
> > > SRCREV = "${AUTOREV}"
> > > S = "${WORKDIR}/p4"
> > >
> > > do_install_append () {
> > > install -d ${D}${systemd_unitdir}/system
> > > install -m 0644 ../perforce-recipe.service
> > ${D}${systemd_unitdir}/system
> > > }
> > >
> > > NATIVE_SYSTEMD_SUPPORT = "1"
> > > SYSTEMD_PACKAGES = "perforce-recipe"
> > > SYSTEMD_SERVICE_${PN} = "perforce-recipe.service"
> > >
> > > SYSTEMD_AUTO_ENABLE = "disable"
> > >
> > > FILES_${PN} = "${systemd_unitdir} ${bindir}"
> > >
> > >
> &
Re: [yocto] Perforce fetcher ignores module and label
Hi Katu,
On 08/28 17:43, Katu Txakur wrote:
> 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?
Sorry, I've been swamped this week and haven't been able to look into
this yet. This coming weekend is a holiday weekend in the USA, too.
But I plan to look at this early next week, hope that's OK.
We should be able to create a patch series to revert my changes so you
can go back to the old perforce fetcher. It might also be worth
investigating how to take the current perforce fetcher and enable some
of the use cases that you have (but we can do this after we successfully
revert).
I'll try to send a patch to you next week for the reverting.
Thanks,
Andrew
> DESCRIPTION = "Dummy recipe to fetch from Perforce"
> SECTION = "PerforceRecipes"
> LICENSE = "CLOSED"
> PR = "r0"
>
> inherit cmake
> DEPENDS = "boost alsa-tools"
>
> P4USER = "myuser"
> P4PASSWD = ""
> P4PORT = "192.168.1.55:1666"
> FETCHCMD_p4 = "/usr/local/bin/p4"
>
> SRC_URI = " \
> p4://${P4USER}:${P4PASSWD}@myrepo/myfolder/...; \
> file://perforce-recipe.service \
> "
> SRCREV = "${AUTOREV}"
> S = "${WORKDIR}/p4"
>
> do_install_append () {
> install -d ${D}${systemd_unitdir}/system
> install -m 0644 ../perforce-recipe.service ${D}${systemd_unitdir}/system
> }
>
> NATIVE_SYSTEMD_SUPPORT = "1"
> SYSTEMD_PACKAGES = "perforce-recipe"
> SYSTEMD_SERVICE_${PN} = "perforce-recipe.service"
>
> SYSTEMD_AUTO_ENABLE = "disable"
>
> FILES_${PN} = "${systemd_unitdir} ${bindir}"
>
>
> 2017-08-28 15:27 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com>:
>
> > Hi Katu,
> >
> > On 08/28 08:56, Katu Txakur wrote:
> > > 2017-08-11 13:52 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com
> > >:
> > > On 08/11 11:34, Katu Txakur wrote:
> > > > > 2017-08-07 12:17 GMT+01:00 Andrew Bradford <
> > and...@bradfordembedded.com
> > > > >:
> > > > > > On 08/02 10:28, Paul Eggleton wrote:
> > > > > > > On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > > > > > > > I'm still having problems fetching from Perforce. Is there any
> > > > > > > > documentation based on the latest implementation of the
> > > > > > > > poky/bitbake/lib/bb/fetch2/perforce.py file?
> > > > > >
> > > > > > There's some documentation now in the official Yocto Project
> > > > > > documentation location for bitbake fetchers [1]. Prior to my
> > changes
> > > > > > there was very little if any documentation, afaik.
> > > > > >
> > > > > > [1]: http://www.yoctoproject.org/docs/2.3.1/bitbake-user-
> > > > > > manual/bitbake-user-manual.html#perforce-fetcher
> > > > > >
> > > > > > > > 2017-07-25 10:05 GMT+01:00 Katu Txakur <katutxaku...@gmail.com
> > >:
> > > > > > > > > I'm upgrading a recipe that fetches the source code from
> > > > Perforce.
> > > > > > > > >
> > > > > > > > > The old recipe was:
> > > > > > > > >
> > > > > > > > > SRC_URI = " \
> > > > > > > > > p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/
> > pe
> > > > > > > > > rforce/...;module=local/path/relativeto/p4;label=${
> > P4CHANGELIST}
> > > > \
> > > > > > > > > "
> > > > > > > > >
> > > > > > > > > With the new version of /lib/bb/fetch2/perforce.py, I had to
> > set
> > > > > > P4PORT
> > > > > > > > > outside SRC_URI, leaving the recipe with:
> > > > > > > > >
> > > > > > > > > SRC_URI = " \
> > > > > > > > > p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > > > > > > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > > > > > > > &
Re: [yocto] Perforce fetcher ignores module and label
Hi Katu,
On 08/28 08:56, Katu Txakur wrote:
> 2017-08-11 13:52 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com>:
> On 08/11 11:34, Katu Txakur wrote:
> > > 2017-08-07 12:17 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com
> > >:
> > > > On 08/02 10:28, Paul Eggleton wrote:
> > > > > On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > > > > > I'm still having problems fetching from Perforce. Is there any
> > > > > > documentation based on the latest implementation of the
> > > > > > poky/bitbake/lib/bb/fetch2/perforce.py file?
> > > >
> > > > There's some documentation now in the official Yocto Project
> > > > documentation location for bitbake fetchers [1]. Prior to my changes
> > > > there was very little if any documentation, afaik.
> > > >
> > > > [1]: http://www.yoctoproject.org/docs/2.3.1/bitbake-user-
> > > > manual/bitbake-user-manual.html#perforce-fetcher
> > > >
> > > > > > 2017-07-25 10:05 GMT+01:00 Katu Txakur <katutxaku...@gmail.com>:
> > > > > > > I'm upgrading a recipe that fetches the source code from
> > Perforce.
> > > > > > >
> > > > > > > The old recipe was:
> > > > > > >
> > > > > > > SRC_URI = " \
> > > > > > > p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > > > > > > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST}
> > \
> > > > > > > "
> > > > > > >
> > > > > > > With the new version of /lib/bb/fetch2/perforce.py, I had to set
> > > > P4PORT
> > > > > > > outside SRC_URI, leaving the recipe with:
> > > > > > >
> > > > > > > SRC_URI = " \
> > > > > > > p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > > > > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > > > > > "
> > > > > > >
> > > > > > > The Perforce fetcher kind of works, but it seems to be ignoring
> > the
> > > > > > > "module" and the "label" attributes. After reading the Python
> > script
> > > > I can
> > > > > > > see that after the "@", only the substring before the first ";"
> > is
> > > > used.
> > > >
> > > > Sorry for not making the label change more clear, but you should be
> > able
> > > > to simply set SRCREV="labelname" and have the functionality you desire.
> > > > However, we don't use labels very often internally, so the use of
> > labels
> > > > in SRCREV isn't tested that often by me.
> > > >
> > >
> > > I don't use labels that much either, however, I used to be able to write
> > > the changeslist number as a label and it would
> > > fetch the code for that changelist. This doesn't work using SRCREV =
> > > "changelistnumber"
> >
> > This does work for me using oe-core morty branch and bitbake
> > 1.32 which is the versions where these changes were first applied and
> > where I did my testing.
> >
> > Like I have a recipe which I put:
> >
> > SRCREV = "184127"
> >
> > The p4 fetcher will go fetch changelist 184127 of the SRC_URI path in
> > perforce.
> >
> > Or if I put:
> >
> > SRCREV = "${AUTOREV}"
> >
> > Then it'll fetch the HEAD/tip of the SRC_URI path in perforce.
> >
> > Is this not working the same way with poky now?
> >
>
> I'm using yocto pyro with bitbake 1.34.0. When I first fetch the code for
> my recipe, it gets the latest changelist.
> I submit a change and the next time, the recipe thinks there nothing new to
> fetch. Also, using SRCREV = "184127"
> doesn't work for me, it always gets the latest changelist.
Can you post the recipe where this is failing for you?
I could then try to recreate this issue in a sandbox depot we have in
our perforce server and see what's going on.
> >
> > > > This change to using labels, changelist numbers, and allowing the use
> > of
> > > > AUTOREV was made so that the perforce fetcher would act more like the
> > > > other source code control system fetchers. Prior to my changes to the
> > > > p4 fetcher, the way that rec
Re: [yocto] Perforce fetcher ignores module and label
Hi Katu,
I added back the yocto ml on CC, could you please keep this conversation
on-list?
On 08/11 11:34, Katu Txakur wrote:
> 2017-08-07 12:17 GMT+01:00 Andrew Bradford <and...@bradfordembedded.com>:
> > On 08/02 10:28, Paul Eggleton wrote:
> > > On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > > > I'm still having problems fetching from Perforce. Is there any
> > > > documentation based on the latest implementation of the
> > > > poky/bitbake/lib/bb/fetch2/perforce.py file?
> >
> > There's some documentation now in the official Yocto Project
> > documentation location for bitbake fetchers [1]. Prior to my changes
> > there was very little if any documentation, afaik.
> >
> > [1]: http://www.yoctoproject.org/docs/2.3.1/bitbake-user-
> > manual/bitbake-user-manual.html#perforce-fetcher
> >
> > > > 2017-07-25 10:05 GMT+01:00 Katu Txakur <katutxaku...@gmail.com>:
> > > > > I'm upgrading a recipe that fetches the source code from Perforce.
> > > > >
> > > > > The old recipe was:
> > > > >
> > > > > SRC_URI = " \
> > > > > p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > > > > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > > > "
> > > > >
> > > > > With the new version of /lib/bb/fetch2/perforce.py, I had to set
> > P4PORT
> > > > > outside SRC_URI, leaving the recipe with:
> > > > >
> > > > > SRC_URI = " \
> > > > > p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > > > "
> > > > >
> > > > > The Perforce fetcher kind of works, but it seems to be ignoring the
> > > > > "module" and the "label" attributes. After reading the Python script
> > I can
> > > > > see that after the "@", only the substring before the first ";" is
> > used.
> >
> > Sorry for not making the label change more clear, but you should be able
> > to simply set SRCREV="labelname" and have the functionality you desire.
> > However, we don't use labels very often internally, so the use of labels
> > in SRCREV isn't tested that often by me.
> >
>
> I don't use labels that much either, however, I used to be able to write
> the changeslist number as a label and it would
> fetch the code for that changelist. This doesn't work using SRCREV =
> "changelistnumber"
Hmmm... This does work for me using oe-core morty branch and bitbake
1.32 which is the versions where these changes were first applied and
where I did my testing.
Like I have a recipe which I put:
SRCREV = "184127"
The p4 fetcher will go fetch changelist 184127 of the SRC_URI path in
perforce.
Or if I put:
SRCREV = "${AUTOREV}"
Then it'll fetch the HEAD/tip of the SRC_URI path in perforce.
Is this not working the same way with poky now?
> > This change to using labels, changelist numbers, and allowing the use of
> > AUTOREV was made so that the perforce fetcher would act more like the
> > other source code control system fetchers. Prior to my changes to the
> > p4 fetcher, the way that recipes using p4 had to be written seemed
> > rather awkward to me. The way it is now isn't perfect, but it's closer
> > to how the other fetchers act, I think (and hope).
> >
>
> > > > Is there a way to set module and label/changelist? I have several
> > folders
> > > > > per recipe that I need to map to different subfolders and with the
> > current
> > > > > script some of the folders don't get fetched.
> >
> > I'm not sure I understand enough about how you use perforce and what you
> > mean by mapping different subfolders. Can you explain this in a more
> > expanded way to me? Maybe with some examples?
> >
>
> What I mean by this is taking folders in different locations in Perforce
> and fetch them to a custom folder structure inside the {WORKDIR}/p4 folder.
> This is an example of how I was doing this with the old version of the
> fetcher:
>
> #leave blank, "", for latest revision
> P4CHANGELIST = "${PR}"
> S = "${WORKDIR}"
> SRC_URI = " \
> p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/project1/folder1/...;module=subfolderunderp4/src/;label=${P4CHANGELIST}
> \
> p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/project2/folder3/...;module=subfol
Re: [yocto] Perforce fetcher ignores module and label
Hi Katu,
Sorry for the delay in my reply, I was on holiday.
On 08/02 10:28, Paul Eggleton wrote:
> Andrew Bradford (on CC) was the last person to make significant changes to
> that module.
>
> On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > I'm still having problems fetching from Perforce. Is there any
> > documentation based on the latest implementation of the
> > poky/bitbake/lib/bb/fetch2/perforce.py file?
There's some documentation now in the official Yocto Project
documentation location for bitbake fetchers [1]. Prior to my changes
there was very little if any documentation, afaik.
[1]:
http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#perforce-fetcher
> > 2017-07-25 10:05 GMT+01:00 Katu Txakur <katutxaku...@gmail.com>:
> >
> > > Hi,
> > >
> > > I'm upgrading a recipe that fetches the source code from Perforce.
> > >
> > > The old recipe was:
> > >
> > > SRC_URI = " \
> > > p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > "
> > >
> > > With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
> > > outside SRC_URI, leaving the recipe with:
> > >
> > > SRC_URI = " \
> > > p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > "
> > >
> > > The Perforce fetcher kind of works, but it seems to be ignoring the
> > > "module" and the "label" attributes. After reading the Python script I can
> > > see that after the "@", only the substring before the first ";" is used.
Sorry for not making the label change more clear, but you should be able
to simply set SRCREV="labelname" and have the functionality you desire.
However, we don't use labels very often internally, so the use of labels
in SRCREV isn't tested that often by me.
This change to using labels, changelist numbers, and allowing the use of
AUTOREV was made so that the perforce fetcher would act more like the
other source code control system fetchers. Prior to my changes to the
p4 fetcher, the way that recipes using p4 had to be written seemed
rather awkward to me. The way it is now isn't perfect, but it's closer
to how the other fetchers act, I think (and hope).
> > > Is there a way to set module and label/changelist? I have several folders
> > > per recipe that I need to map to different subfolders and with the current
> > > script some of the folders don't get fetched.
I'm not sure I understand enough about how you use perforce and what you
mean by mapping different subfolders. Can you explain this in a more
expanded way to me? Maybe with some examples?
Thanks,
Andrew
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem creating debug build with inlined functions
Hi Khem, On 08/13 18:51, Khem Raj wrote: On Thu, Aug 13, 2015 at 1:25 PM, Todd Efflam todd.eff...@gmail.com wrote: Hello, We're trying to create a debug build so we can use our image with gdb, however we're unable to get it to compile. We've added the lines DEBUG_BUILD = 1 and EXTRA_IMAGE_FEATURES += tools-sdk dbg-pkgs tools-debug debug-tweaks to the local.conf file, but it seems to be failing on glibc. The errors we get have to do with inlined functions (./tlsdeschtab.h:28:1: error: inlining failed in call to 'hash_tlsdesc': indirect function call with a yet undetermined callee [-Werror=inline] | hash_tlsdesc (void *p)). Are we missing a compile flag? We tried adding -gdwarf-2 to the CFLAGS option in local.conf but still got the same error. Any help would be appreciated! when you choose DEBUG_BUILD = 1 it also changes the default optimization settings for glibc to -O which is -O1 really. Thats not a common flag used to build glibc so you might have fallen into less used case Please test out this patch and let me know if it fixed the problem for you http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/masterid=16935bb4b6df99c6443dab06c77a9cfd4eb35f5d Although I'm not the reporter of this issue, I ran into it as well and this patch fixes this issue for me when applying it on top of the fido-13.0.0 tag of poky. Thanks! -Andrew -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
