[yocto] Current situation with gobject introspection?
I'm currently using Jethro (though about to move to Krogoth), and have an external package which need gobject introspection. I'm building on 64-bit x86, for ARM iMX6 target. I've been searching around to work out if this is possible under Yocto, but not sure which of the info I've found is up-to-date. So I wondered what the latest [krogoth] situation is - am I likely to be able to get this package to build, and where/how might I get started? Thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Current situation with gobject introspection?
On 28 March 2017 at 09:05, wrote: > So I wondered what the latest [krogoth] situation is – am I likely to be > able to get this package to build, and where/how might I get started? > > Krogoth (2.1) isn't the latest, that's Morty (2.2) released in October 2016 and next month Pyro (2.3) is being released. Krogoth has support for gobject-introspection, and is covered in the documentation: http://www.yoctoproject.org/docs/2.2.1/dev-manual/dev-manual.html#enabling-gobject-introspection-support Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Current situation with gobject introspection?
On 28 March 2017 at 11:05, wrote: > > I’m currently using Jethro (though about to move to Krogoth), and have an external package which need gobject introspection. I’m building on 64-bit x86, for ARM iMX6 target. > > I’ve been searching around to work out if this is possible under Yocto, but not sure which of the info I’ve found is up-to-date. > > So I wondered what the latest [krogoth] situation is – am I likely to be able to get this package to build, and where/how might I get started? > > Thanks Hi Colin, Alexander can give you the gory details if needed but the summary is: Krogoth has full gobject-introspection support (for architectures that qemu supports), jethro does not. There is a distro feature but it is backfilled by default so no action should be needed. For many libraries you only need to inherit the class, but do read the fine manual just in case: http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#enabling-gobject-introspection-support Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Current situation with gobject introspection?
> On 28 March 2017 at 09:39 "Burton, Ross" wrote: > > On 28 March 2017 at 09:05, wrote: > > > So I wondered what the latest [krogoth] situation is – am I likely to be > > able to get this package to build, and where/how might I get started? > > Krogoth (2.1) isn't the latest, that's Morty (2.2) released in October 2016 > and next month Pyro (2.3) is being released. > Yeah, sorry - I meant 'the latest situation w.r.t Krogoth', rather than Krogoth being the latest version :) > Krogoth has support for gobject-introspection, and is covered in the > documentation: > > http://www.yoctoproject.org/docs/2.2.1/dev-manual/dev-manual.html#enabling-gobject-introspection-support > Thanks guys, I'll get moved over to Krogoth and take it from there. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] package managers
Hello, Is it possible to configure more than one package manager in yocto ? Does it mean it will create install package for both ? Thank you, Ran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Questions
Hi, How to install a command (pmount) in poky distribution. What are the steps to follow? Thanks, ARUNKUMAR K -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] package managers
On 28 March 2017 at 10:09, Ran Shalit wrote: > Is it possible to configure more than one package manager in yocto ? > Does it mean it will create install package for both ? > This is explained in the documentation: http://www.yoctoproject.org/docs/2.2.1/ref-manual/ref-manual.html#var-PACKAGE_CLASSES Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] multiple, different kernel images in one rootfs
Hi, I'm currently using Jethro and like to include multiple, different kernel (fit)images (with different source branches/versions) in one RootFS. When booting such a system the bootloader (U-Boot) will decide which kernel to load. I've already done some searches on the Internet, but found only Bug 6945, which seems to be something similar. But I'm unable to find any documentation on it, and the commits linked to the bugzilla [1] aren't very helpful. Furthermore a similar question on the mailing list in 2015 [2] wasn't answered. So does anybody of you know how to implement that or where/how I might get started? Thanks & regards, Richard L [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6945 [2] https://lists.yoctoproject.org/pipermail/yocto/2015-May/025031.html -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] package managers
On Tue, Mar 28, 2017 at 12:21 PM, Burton, Ross wrote: > > On 28 March 2017 at 10:09, Ran Shalit wrote: >> >> Is it possible to configure more than one package manager in yocto ? >> Does it mean it will create install package for both ? > > > This is explained in the documentation: > > http://www.yoctoproject.org/docs/2.2.1/ref-manual/ref-manual.html#var-PACKAGE_CLASSES > > Ross Hi, Thanks a lot for the reference. It is said: "The build system uses only the first argument in the list as the package manager when creating your image or SDK. However, packages will be created using any additional packaging classes you specify" I understand from this that in target it will be possible to install a package, using the other package manager. Regards, Ran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] package managers
On 28 March 2017 at 11:00, Ran Shalit wrote: > I understand from this that in target it will be possible to install a > package, using the other package manager. > Why would you want to do this? You'll need to install the package management tooling, and the database of the one you install after the rootfs creation won't know about anything that is already in the rootfs. It's a lot easier to just pick a package manager and use it consistently. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unpack hierarchy - jethro vs. krogoth
Is there a change to recipe parsing and/or variables between jethro and
krogoth?
I'm migrating from the former to the latter and have hit a patch failure.
Looking at the unpacked source, jethro has the relevant file at
build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/
whereas krogoth has it at
build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/driver/
Indeed, all the sources have been unpacked under an additional 'driver'
directory level .e.g.
src/driver/* -> 3.0.2-r0/driver/driver/
src/config/* -> 3.0.2-r0/driver/config/
instead of
src/driver/* -> 3.0.2-r0/driver/
src/config/* -> 3.0.2-r0/config/
The recipe includes
SRC_URI = "file://driver/*.c \
file://driver/*.h \
file://Makefile \
file://COPYING \
"
FILESEXTRAPATHS_prepend := "${BSPDIR}/../Apps/MyDriver/src:"
S = "${WORKDIR}"
As I say, it works on jethro...!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] package managers
On Tue, Mar 28, 2017 at 1:25 PM, Burton, Ross wrote: > > On 28 March 2017 at 11:00, Ran Shalit wrote: >> >> I understand from this that in target it will be possible to install a >> package, using the other package manager. > > > Why would you want to do this? > > You'll need to install the package management tooling, and the database of > the one you install after the rootfs creation won't know about anything that > is already in the rootfs. > > It's a lot easier to just pick a package manager and use it consistently. > Ok, Thank you ! > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] host sysroot
Hello, I am trying to understand what's the purpose of host sysroot (in /build/tmp/sysroots/) ? I see it contains a set of libraries too. But for cross compiling an application in host isn't all we need is toolchain and target sysroot ? If so, than what's the purpose of host sysroot ? Thank you, Ran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Copying Static library to libdir of YOCTO
Hello ,
I am facing some issues , when trying to copy static libraries like
libaccess.a & liblang.a to ${libdir} of rootfs.
I can see those libraries in the "usr/lib" directory of that particular
package which is generated in "tmp/work" folder . But somehow these
libraries are not copied to rootfs "/usr/lib" directory.
I am using below instructions:
install -d ${D}${libdir}/
install -m 0755 ${S}/accesslib_new/libaccess.a ${D}${libdir}
install -d ${D}${libdir}/
install -m 0755 ${S}/WebServices_LanguageLibrary/liblang.a
${D}${libdir}
Any suggestion...
Thanks & regards
Surya
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Copying Static library to libdir of YOCTO
On 28 March 2017 at 12:02, Surya wrote:
> I can see those libraries in the "usr/lib" directory of that particular
> package which is generated in "tmp/work" folder . But somehow these
> libraries are not copied to rootfs "/usr/lib" directory.
>
Static libraries are part of the ${PN}-staticdev package, so won't be
installed if you just install the ${PN}-dev package.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Current situation with gobject introspection? (off-topic)
On 28-03-17 10:39, Burton, Ross wrote: Krogoth (2.1) isn't the latest, that's Morty (2.2) released in October 2016 and next month Pyro (2.3) is being released. So what happened to the missing two walker bots? :-) Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unpack hierarchy - jethro vs. krogoth
> On 28 March 2017 at 11:33 colin.helliw...@ln-systems.com wrote:
>
> Is there a change to recipe parsing and/or variables between jethro and
> krogoth?
> I'm migrating from the former to the latter and have hit a patch failure.
> Looking at the unpacked source, jethro has the relevant file at
> build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/
> whereas krogoth has it at
> build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/driver/
>
> Indeed, all the sources have been unpacked under an additional 'driver'
> directory level .e.g.
> src/driver/* -> 3.0.2-r0/driver/driver/
> src/config/* -> 3.0.2-r0/driver/config/
> instead of
> src/driver/* -> 3.0.2-r0/driver/
> src/config/* -> 3.0.2-r0/config/
>
> The recipe includes
> SRC_URI = "file://driver/*.c \
> file://driver/*.h \
> file://Makefile \
> file://COPYING \
> "
> FILESEXTRAPATHS_prepend := "${BSPDIR}/../Apps/MyDriver/src:"
> S = "${WORKDIR}"
>
> As I say, it works on jethro...!
>
Can't spot a reason, even in the bbclass's, why it's unpacking differently.
log.do_unpack reports:
DEBUG: Searching for driver/*.c in paths:
DEBUG: Searching for driver/*.c in path:
/home/colin/100051-krogoth/fsl-community-bsp/../Apps/MyDriver/src/.
NOTE: Unpacking
/home/colin/100051-krogoth/fsl-community-bsp/../Apps/MyDriver/src/. to
/home/colin/100051-krogoth/fsl-community-bsp/build/tmp/work/wg2xx_tx6s-poky-linux-gnueabi/linmux/3.0.2-r0/
which suggests it should've ended up in the 'right' place?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Questions
Hi Arun, You need to add poky manager support to Poky and install it by adding the following line to your build/conf/local.conf file. https://wiki.yoctoproject.org/wiki/How_do_I For the conf/local.conf entry please add this: IMAGE_INSTALL_append = " package" After that you have to bitbake a new image that contains your package. Thanks, Ulf From: on behalf of Arun Maha <2233arunku...@gmail.com> Date: Tuesday, March 28, 2017 at 2:14 AM To: "yocto@yoctoproject.org" Subject: [yocto] Questions Hi, How to install a command (pmount) in poky distribution. What are the steps to follow? Thanks, ARUNKUMAR K -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Remove a recipe's do_install_append() function in an append file
Hello,
I am building zsh from meta-oe layer, and it has a do_install_append()
function defined like this:
do_install_append () {
rm -fr ${D}/usr/share
}
which gets rid of lots lots of useful functionality, like
context-aware autocompletion. Can a bbappend file get rid of that
function, or do I need to edit the actual recipe? I've attempted
defining an empty do_install_append() { : } but it didn't work.
Thanks,
Cody
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: how to enable c++11 support in yocto
-- Forwarded message -- From: Vadalasetti Sivanageswararao Date: Sun, Mar 26, 2017 at 9:26 PM Subject: Re: how to enable c++11 support in yocto To: Khem Raj Dear Yocto Team, when i compiling my c++ programs it is giving below error. please give me the solution for below error. i have written a simple recipe to compile the c++11 support programmes. cc1plus: warning: include location "/usr/local/include" is unsafe for cross-compilation [-Wpoison-system-directories] | ../SourceFiles/AutomaticShutdown.cpp:12:17: fatal error: cmath: No such file or directory | #include | ^ | compilation terminated. | make: *** [SourceFiles/AutomaticShutdown.o] Error 1 | WARNING: exit code 2 from a shell command. Presently I am using internal compiler in yocto not SDK. Thankyou, > -- > V.SIVANAGESWARA RAO -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to enable c++11 support in yocto
Ok i will send mail to those people , Thankyou for your Help, and Please send me some text or docs Regarding your development of poky toolchain. On Mon, Mar 27, 2017 at 10:28 AM, Vadalasetti Sivanageswararao < vsivanag...@gmail.com> wrote: > > -- Forwarded message -- > From: Vadalasetti Sivanageswararao > Date: Sun, Mar 26, 2017 at 9:26 PM > Subject: Re: how to enable c++11 support in yocto > To: Khem Raj > > > Dear Yocto Team, > > when i compiling my c++ programs it is giving below error. please give me > the solution for below error. > > i have written a simple recipe to compile the c++11 support programmes. > > cc1plus: warning: include location "/usr/local/include" is unsafe for > cross-compilation [-Wpoison-system-directories] > | ../SourceFiles/AutomaticShutdown.cpp:12:17: fatal error: cmath: No such > file or directory > | #include > | ^ > | compilation terminated. > | make: *** [SourceFiles/AutomaticShutdown.o] Error 1 > | WARNING: exit code 2 from a shell command. > > Presently I am using internal compiler in yocto not SDK. > > Thankyou, > > >> -- >> > V.SIVANAGESWARA RAO > -- V.SIVANAGESWARA RAO -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove a recipe's do_install_append() function in an append file
On Thu, Mar 23, 2017 at 5:28 PM, Cody Piersall wrote:
> Hello,
>
> I am building zsh from meta-oe layer, and it has a do_install_append()
> function defined like this:
>
> do_install_append () {
> rm -fr ${D}/usr/share
> }
>
> which gets rid of lots lots of useful functionality, like
> context-aware autocompletion. Can a bbappend file get rid of that
> function, or do I need to edit the actual recipe? I've attempted
> defining an empty do_install_append() { : } but it didn't work.
We hit this sometime so curious if anyone has better suggestions. But
you can add a do_install_prepend to save the data somewhere, and an
append to put it back. Also, you can use the priority of your layer
could come into play here.
-M
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: how to enable c++11 support in yocto
On 27 March 2017 at 05:58, Vadalasetti Sivanageswararao < vsivanag...@gmail.com> wrote: > cc1plus: warning: include location "/usr/local/include" is unsafe for > cross-compilation [-Wpoison-system-directories] > Your build is referring to host files so this is likely the problem. This is a bug in your sources, or recipe. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove a recipe's do_install_append() function in an append file
On Thu, Mar 23, 2017 at 3:28 PM, Cody Piersall wrote:
> Hello,
>
> I am building zsh from meta-oe layer, and it has a do_install_append()
> function defined like this:
>
> do_install_append () {
> rm -fr ${D}/usr/share
> }
>
> which gets rid of lots lots of useful functionality, like
> context-aware autocompletion. Can a bbappend file get rid of that
> function, or do I need to edit the actual recipe? I've attempted
> defining an empty do_install_append() { : } but it didn't work.
>
if its in a bbappend, there is not much you can do about undoing it except
to not apply the bbappend or modify it directly.
So you can send a patch to meta-oe to convince that its a good idea to keep
/usr/share for zsh, or you can carry a local patch to meta-oe where you undo it
> Thanks,
> Cody
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.3_M3.rc2 now available.
A release candidate build for yocto-2.3_M3.rc2 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M3.rc2 Please begin QA on this build as soon as possible. Build hash information: meta-intel : 5587993816a6cb2ea46dffbb527bb04baa9bd660 meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 meta-mingw : b4ef177e6ebdc0aded3e202e0decbf1cb21c73dd meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f meta-gplv2 : de001bd6bfcec943d274b649c62be6848cc9c3e6 poky : 415b72ffcbd26e5f3664370d8b2a9b8105fb6342 This is an automated message from The Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder Email: joshua.g.l...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiple, different kernel images in one rootfs
On 3/28/17 2:53 AM, Richard Leitner wrote: > Hi, > I'm currently using Jethro and like to include multiple, different > kernel (fit)images (with different source branches/versions) in one > RootFS. When booting such a system the bootloader (U-Boot) will decide > which kernel to load. > There is/was a way to build multiple kernels see something like this https://git.digitalstrom.org/dss-oe/dss-oe/commit /1e0c2307a910e8fc7e2482a757c52277c4f4e01e might help you > I've already done some searches on the Internet, but found only Bug > 6945, which seems to be something similar. But I'm unable to find any > documentation on it, and the commits linked to the bugzilla [1] aren't > very helpful. > > Furthermore a similar question on the mailing list in 2015 [2] wasn't > answered. > > So does anybody of you know how to implement that or where/how I might > get started? > > Thanks & regards, > Richard L > > [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=6945 > [2] https://lists.yoctoproject.org/pipermail/yocto/2015-May/025031.html > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove a recipe's do_install_append() function in an append file
On Tue, Mar 28, 2017 at 10:27:15AM -0700, Khem Raj wrote:
> On Thu, Mar 23, 2017 at 3:28 PM, Cody Piersall wrote:
> > Hello,
> >
> > I am building zsh from meta-oe layer, and it has a do_install_append()
> > function defined like this:
> >
> > do_install_append () {
> > rm -fr ${D}/usr/share
> > }
> >
> > which gets rid of lots lots of useful functionality, like
> > context-aware autocompletion. Can a bbappend file get rid of that
> > function, or do I need to edit the actual recipe? I've attempted
> > defining an empty do_install_append() { : } but it didn't work.
> >
>
> if its in a bbappend, there is not much you can do about undoing it except
> to not apply the bbappend or modify it directly.
>
> So you can send a patch to meta-oe to convince that its a good idea to keep
> /usr/share for zsh, or you can carry a local patch to meta-oe where you undo
> it
Perhaps instead of deleting it, it should be put in another package that
people can choose to install if they want it. Deleting it certainly
does seem rather unfortunate if someone actulally wanted it.
--
Len Sorensen
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] host sysroot
On 3/28/17 4:18 AM, Ran Shalit wrote: > Hello, > > I am trying to understand what's the purpose of host sysroot (in > /build/tmp/sysroots/) ? > I see it contains a set of libraries too. But for cross compiling an > application in host isn't all we need is toolchain and target sysroot > ? If so, than what's the purpose of host sysroot ? > there is more to it than just cross toolchains. Build system is building some components for the build host itself and does not rely on the host to provide them, they are also hosted in the host sysroot. > Thank you, > Ran > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove a recipe's do_install_append() function in an append file
On 3/28/17 11:19 AM, Lennart Sorensen wrote:
> On Tue, Mar 28, 2017 at 10:27:15AM -0700, Khem Raj wrote:
>> On Thu, Mar 23, 2017 at 3:28 PM, Cody Piersall wrote:
>>> Hello,
>>>
>>> I am building zsh from meta-oe layer, and it has a do_install_append()
>>> function defined like this:
>>>
>>> do_install_append () {
>>> rm -fr ${D}/usr/share
>>> }
>>>
>>> which gets rid of lots lots of useful functionality, like
>>> context-aware autocompletion. Can a bbappend file get rid of that
>>> function, or do I need to edit the actual recipe? I've attempted
>>> defining an empty do_install_append() { : } but it didn't work.
>>>
>>
>> if its in a bbappend, there is not much you can do about undoing it except
>> to not apply the bbappend or modify it directly.
>>
>> So you can send a patch to meta-oe to convince that its a good idea to keep
>> /usr/share for zsh, or you can carry a local patch to meta-oe where you undo
>> it
>
> Perhaps instead of deleting it, it should be put in another package that
> people can choose to install if they want it. Deleting it certainly
> does seem rather unfortunate if someone actulally wanted it.
>
We put common stuff in commonly used layers. Secondly, a patch to
package the content of /usr/share into a package of its own something
like zsh-misc might be OK and we don't have to delete it and keep both
camps happy.
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using ${SRCVP} in PR of BB file
Hello,
We are preparing to move to PRservice in Yocto to handle auto rolling
our revisions on every build. As an interim step we are doing some
reordering or our current PR and PV parameters in our bitbake files. Our
current syntax is as follows and works as expected
BB File
SRC_URI =
"git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/bcastforwd;protocol=ssh"
SRCREV = "${AUTOREV}"
PV = "1.1"
PR = "r0"
PV_append = "+git${SRCPV}"
Output from build
bcastforwd_1.0-r0git0+afc68d4a00_arm926ejste.ipk
When we change git${SRCPV} to append to the PR we get "AUTOINC" in place of
the revision number
BB File
"git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/bcastforwd;protocol=ssh"
SRCREV = "${AUTOREV}"
PV = "1.1"
PR = "r0"
PR_append = "+git${SRCPV}"
ipk Output from build
bcastforwd_1.0-r0gitAUTOINC+afc68d4a00_arm926ejste.ipk
I took a look at the package.bbclass file which appears to be the
magic sauce for searching and replacing the "AUTOINC" string but
nothing jumped out at me as to why this would work for PV but not PR.
Is it possible to support AUTOREV on PR?
Thanks,
Ian Welch
Trimble Inc.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using ${SRCVP} in PR of BB file
On 3/28/17 1:27 PM, Ian Welch wrote:
> Hello,
> We are preparing to move to PRservice in Yocto to handle auto
> rolling our revisions on every build. As an interim step we are doing
> some reordering or our current PR and PV parameters in our bitbake
> files. Our current syntax is as follows and works as expected
>
> BB File
> SRC_URI =
> "git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/bcastforwd;protocol=ssh"
> SRCREV = "${AUTOREV}"
> PV = "1.1"
> PR = "r0"
> PV_append = "+git${SRCPV}"
>
> Output from build
>
> bcastforwd_1.0-r0git0+afc68d4a00_arm926ejste.ipk
>
>
>
> When we change git${SRCPV} to append to the PR we get "AUTOINC" in place
> of the revision number
>
> BB File
> "git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/bcastforwd;protocol=ssh"
> SRCREV = "${AUTOREV}"
> PV = "1.1"
> PR = "r0"
> PR_append = "+git${SRCPV}"
>
> ipk Output from build
>
> bcastforwd_1.0-r0gitAUTOINC+afc68d4a00_arm926ejste.ipk
>
>
> I took a look at the package.bbclass file which appears to be the magic sauce
> for searching and replacing the "AUTOINC" string but nothing jumped out at me
> as to why this would work for PV but not PR.
>
>
> Is it possible to support AUTOREV on PR?
git0 and gitAUTOINC is the difference you are seeing however when PR is
bumped r0 would change to r0.0 or something which is preceding the
AUTOINC difference and you should be able to upgrade. Although I would
discourage you from using AUTOREVs in release environment. Use locked
SHA values, it will also help you with reproducible builds.
>
>
>
> Thanks,
> Ian Welch
> Trimble Inc.
>
>
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using ${SRCVP} in PR of BB file
Hi Ian,
On Wednesday, 29 March 2017 9:27:01 AM NZDT Ian Welch wrote:
> We are preparing to move to PRservice in Yocto to handle auto rolling
> our revisions on every build. As an interim step we are doing some
> reordering or our current PR and PV parameters in our bitbake files. Our
> current syntax is as follows and works as expected
>
> BB File
> SRC_URI =
> "git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/
> bcastforwd;protocol=ssh" SRCREV = "${AUTOREV}"
> PV = "1.1"
> PR = "r0"
> PV_append = "+git${SRCPV}"
>
> Output from build
>
> bcastforwd_1.0-r0git0+afc68d4a00_arm926ejste.ipk
>
>
>
> When we change git${SRCPV} to append to the PR we get "AUTOINC" in place of
> the revision number
>
> BB File
> "git://myrepo.git;branch=mybranch;subpath=Linux/bcastforwd;destsuffix=Linux/
> bcastforwd;protocol=ssh" SRCREV = "${AUTOREV}"
> PV = "1.1"
> PR = "r0"
> PR_append = "+git${SRCPV}"
>
> ipk Output from build
>
> bcastforwd_1.0-r0gitAUTOINC+afc68d4a00_arm926ejste.ipk
>
>
> I took a look at the package.bbclass file which appears to be the
> magic sauce for searching and replacing the "AUTOINC" string but
> nothing jumped out at me as to why this would work for PV but not PR.
It's doing the replacement on PKGV, which is the equivalent of PV at the
packaging end of things. We don't apply the replacement to PKGR, which is the
equivalent to PR.
> Is it possible to support AUTOREV on PR?
The code isn't designed to handle that - the convention is to put it into PV
and have the AUTOINC value ensure that the version increments properly. Aside
from the preceding "r", PR is typically just a number.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] NVIDIA Drivers
Hi, I have built an image based on poky core-image-x11. Everything went fine but the graphic card drivers. I want more resolution than the provided by vesa (800x600) so I really need this drivers. I tried this guacamayo recipe https://layers.openembedded.org/layerindex/recipe/3272/ but can't compile (too old, maybe unmaintained?). Also tried the recipe xf86-video-nouveau (it is blacklisted but in krogoth it compiles right) but when I boot the image, the nouveau driver is not used. My knowledges are very low to even try to cross compile the nvidia propietary drivers (and can't find any reference) so now I'm stucked. My machine is a zotac zbox, it came with angstrom but now I want to build my own image. I came from ubuntu world where the drivers are installed automatically so at this point I'm totally lost. Can you bring me some light? Thank you -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NVIDIA Drivers
On 28 March 2017 at 22:47, Alvaro Garcia wrote: > I tried this guacamayo recipe https://layers.openembedded. > org/layerindex/recipe/3272/ but can't compile (too old, maybe > unmaintained?). Also tried the recipe xf86-video-nouveau (it is blacklisted > but in krogoth it compiles right) but when I boot the image, the nouveau > driver is not used. My knowledges are very low to even try to cross compile > the nvidia propietary drivers (and can't find any reference) so now I'm > stucked. My machine is a zotac zbox, it came with angstrom but now I want > to build my own image. > When you built the nouveux driver, did you add it to the image? Bitbaking something doesn't add it to the image. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NVIDIA Drivers
I'm not sure, I started with yocto about a week ago. What I did is exactly: 1. Added to bblayers.conf the layer /home/alvaro/poky/meta-openembedded/meta-oe (previously I downloaded this meta, needed for x11vnc) 2. Added a custom layer /home/alvaro/poky/meta-unclutter (it just compile the application and copy it to /usr/bin) 3. In local.conf, added CORE_IMAGE_EXTRA_INSTALL += "xf86-video-nouveau unclutter alsa-utils x11vnc gconf" 4. Run MACHINE=genericx86-64 bitbake core-image-x11 Then I installed the image into my device. Everything worked as expected but the nouveau driver. Is this correct or I forgot some step? 2017-03-29 0:09 GMT+02:00 Burton, Ross : > > On 28 March 2017 at 22:47, Alvaro Garcia wrote: > >> I tried this guacamayo recipe https://layers.openembedded.or >> g/layerindex/recipe/3272/ but can't compile (too old, maybe >> unmaintained?). Also tried the recipe xf86-video-nouveau (it is blacklisted >> but in krogoth it compiles right) but when I boot the image, the nouveau >> driver is not used. My knowledges are very low to even try to cross compile >> the nvidia propietary drivers (and can't find any reference) so now I'm >> stucked. My machine is a zotac zbox, it came with angstrom but now I want >> to build my own image. >> > > When you built the nouveux driver, did you add it to the image? Bitbaking > something doesn't add it to the image. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NVIDIA Drivers
On 28 March 2017 at 23:41, Alvaro Garcia wrote: > Then I installed the image into my device. Everything worked as expected > but the nouveau driver. Is this correct or I forgot some step? > I'd check that the package actually exists in your rootfs - use the package manager to verify this. It should be there but I've never used nouveux. Beyond that the driver is installed so maybe you need to adjust xorg.conf. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unpack hierarchy - jethro vs. krogoth
On Tue, Mar 28, 2017 at 3:33 AM, wrote:
> Is there a change to recipe parsing and/or variables between jethro and
> krogoth?
> I'm migrating from the former to the latter and have hit a patch failure.
> Looking at the unpacked source, jethro has the relevant file at
> build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/
> whereas krogoth has it at
> build/tmp/work/XXX-poky-linux-gnueabi/linmux/3.0.2-r0/driver/driver/
>
> Indeed, all the sources have been unpacked under an additional 'driver'
> directory level .e.g.
> src/driver/* -> 3.0.2-r0/driver/driver/
> src/config/* -> 3.0.2-r0/driver/config/
> instead of
> src/driver/* -> 3.0.2-r0/driver/
> src/config/* -> 3.0.2-r0/config/
>
>
> The recipe includes
> SRC_URI = "file://driver/*.c \
>file://driver/*.h \
>file://Makefile \
>file://COPYING \
> "
> FILESEXTRAPATHS_prepend := "${BSPDIR}/../Apps/MyDriver/src:"
> S = "${WORKDIR}"
>
> As I say, it works on jethro...!
There were some changes in bitbake's handling of file:// SRC_URI entries:
http://git.openembedded.org/bitbake/commit/?id=e659a3b0c2771679057ee3e13cd42e6c62383ff2
Is the behaviour more consistent if you remove one of the
"file://driver/*.[ch]" entries from SRC_URI? Or if you replace both
with a single entry to copy entire driver directory (ie
"file://driver") and avoid using wildcards?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NVIDIA Drivers
I used rpm and deb, you mean dpkg (for deb) when you say package manager? 2017-03-29 0:43 GMT+02:00 Burton, Ross : > > On 28 March 2017 at 23:41, Alvaro Garcia wrote: > >> Then I installed the image into my device. Everything worked as expected >> but the nouveau driver. Is this correct or I forgot some step? >> > > I'd check that the package actually exists in your rootfs - use the > package manager to verify this. It should be there but I've never used > nouveux. Beyond that the driver is installed so maybe you need to adjust > xorg.conf. > > Ross > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [patchwork][PATCH] parsemail.py: Improve status-change-through-email
Patch status can be edited through email by project maintainers only
without any feedback if this is attempted by any other user,
providing a poor user experience.
This change extends the patch-status-through-email functionality
to be performed by the series submitter also, and provides a
system-generated message if an attempt was made through a message
using an email address not recognized neither as project maintainer or
series submitter in patchwork.
[YOCTO #11027]
Signed-off-by: Jose Lamego
---
patchwork/bin/parsemail.py | 73 +++---
1 file changed, 49 insertions(+), 24 deletions(-)
diff --git a/patchwork/bin/parsemail.py b/patchwork/bin/parsemail.py
index ebfa849..61c18b2 100755
--- a/patchwork/bin/parsemail.py
+++ b/patchwork/bin/parsemail.py
@@ -838,31 +838,56 @@ def parse_mail(mail):
comment.msgid = msgid
comment.save()
LOGGER.debug('Comment saved')
-
-# if comment's author has project-maintainer permissions,
-# parse comment content and process the status-change command
-# if it is found
-if author.user and project in \
-(author.user).profile.maintainer_projects.all():
-cmd = None
-comment_re = re.compile('^\[Patchwork-Status:\s*(Under Review|\
-Rejected|RFC|Not Applicable|Changes Requested|Awaiting Upstream|Superseded|\
-Deferred)\]$', re.M | re.I)
-# if multiple valid status-change commands are found, use last one
-for match in comment_re.finditer(comment.content):
-cmd = re.sub(r'(\[Patchwork-Status:\s*)(.*)(\])', r'\2',
- "{}".format(match.group(0)))
-if cmd is not None:
-new_state = State.objects.get(name=cmd.title())
-mod_patch = Patch.objects.get(pk=comment.patch.pk)
-if new_state and mod_patch.state != new_state:
-mod_patch.state = new_state
-mod_patch.save()
-cmd_message = 'This is a system generated Comment: Patch \
-%s status was updated to "%s" due to request in comment.' % (
- comment.patch.pk, cmd)
+# look for a status-change command string in the comment
+cmd = None
+comment_re = re.compile('^(?:\n|\r\n?)\[Patchwork-Status:\s*\
+(Under Review|Rejected|RFC|Not Applicable|Changes Requested|Awaiting \
+Upstream|Superseded|Deferred)\](?:\n|\r\n?)$', re.M | re.I)
+# if multiple valid status-change commands are found, use last one
+for match in comment_re.finditer(comment.content):
+cmd = re.sub(
+r'((?:\n|\r\n?)\[Patchwork-Status:\s*)(.*)(\](?:\n|\r\n?))',
+r'\2', "{}".format(match.group(0)))
+# if a status-change command string is found, see if comment's author
+# has either project-maintainer permissions or is the series submitter
+# and process the command if true.
+if cmd is not None:
+refs = build_references_list(mail)
+if not refs == []:
+if not series:
+series = SeriesRevision.objects.filter(
+series__project=project,
+root_msgid=refs[-1]).reverse()[0].series
+if (author.user and project in
+(author.user).profile.maintainer_projects.all()) or (
+author and author == series.submitter):
+new_state = State.objects.get(name=cmd.title())
+mod_patch = Patch.objects.get(pk=comment.patch.pk)
+if new_state and mod_patch.state != new_state:
+mod_patch.state = new_state
+mod_patch.save()
+cmd_message = 'This is a system generated Comment: \
+Patch %s status was updated to "%s"\ndue to request in comment body.' % (
+comment.patch.pk, cmd)
+cmd_msgid = "%s: System generated by comment %s" % (
+datetime.datetime.now().strftime("\
+%d%b%Y.%H:%M:%S.%f"), comment.pk)
+new_comment = Comment(pk=None, patch=comment.patch,
+ content=cmd_message,
+ date=datetime.datetime.now(),
+ submitter=comment.submitter,
+ msgid=cmd_msgid)
+new_comment.save()
+else:
+# notify that a patch-status change was attempted without
+# apropriate submitter/maintainer permissions
+cmd_message = 'This is a system generated Comment: \
+A command to change a patch-status through\nemail was detected in comment, \
+but the sender email does not belong either to\na project maintainer or
