Re: [yocto] meta-sunxi maintained?
On 31.05.2019 08:47, Belisko Marek wrote: > Hi Maciej, > > On Wed, May 29, 2019 at 1:08 PM Maciej Pijanowski > wrote: >> >> On 29.05.2019 09:39, Belisko Marek wrote: >>> Hi Dimitris, >>> >>> On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos >>> wrote: Hi Marek, that's correct. I have a branch though which I've started to experiment and add support for Mali. I didn't finished because I've tried to do this by myself from the scratch and soon I've hit a wall. Nevertheless, I've done the same for the rk3399 for nanopi-neo4 and during this process I've learned a lot on how to do it with some help from other people from the open source scene. The graphics stack was too complicated for me in the beginning. >>> You can maybe look to meta-sunxi there is sunxi-mali driver + >>> libraries which will add support for that. When I've set that package >>> to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation >>> gtk3+ and others. I've spend 2 hours looking and trying yesterday but >>> without any success. Also pls look at this communication: >>> https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we >>> can use opensource drivers + libs later). Thanks. >> What are you trying to achieve? Which kernel version are you using? >> Isn't the mali recipe in meta-sunxi quite dated already? Can it work >> with mainline kernel correctly? >> >> I would suggest to try the recent blobs as described in this post: >> https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/ >> >> As I've written previously, I have been using the Wayland / Qt with >> good performance on H3 using the mainline kernel. Is it something you >> are looking for? >> You can take a look at my dirty branch - maybe this will be any help: >> https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali > I've took some patches and now core-image-sato can be build. I have > just one question for mali kernel module. Does it need some dts > changes or it will work out of the box (I didn't see any dts changes > in your branch thus I'm asking). > Thanks. Depending on the board. I think since then, most of the baords already have mali node in the devicetree. Especially all the H3 baords should have it. >> Unfortunately, I had stopped working on that and presently do not have much >> time to clean up / get back to it. I can provide some support and / or get >> back to it if it seems valuable and there is some interest. Therefore now that I feel much more confident with it I'm going to re-try and finish with my branch. Armbian does have support, so I'll try to stick to the Armbian backend for maintenance reasons. I hope that this will be rather easy, because the dri driver should already be there, so the only thing I believe is needed is the blobs and to create symlinks for the various so libs to that blob. Anyway, I'll try to do that also. In the meantime I will also wait a bit to see if that merge between those two layers is possible and doable, which will help to short the time and effort to do that. Regards, Dimitris >>> BR, >>> >>> marek Belisko Marek schrieb am Mi., 29. Mai 2019, 08:37: > Hi Dimitris, > > On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos > wrote: >> Hi Enrico, >> >> I'm totally positive to any possibility for such integration. >> Personally, that was the first thing I've tried to do before I start >> this layer, but I've failed as it got really complex and the overhead >> was too much after some point (at least for me). If you have look it's >> actually a mix of meta-sunxi and armbian, but I had to remove or change >> many stuff to fit the armbian in the layer. >> >> If you have time to have a look to my layer and you think that such kind >> of integration is possible and can be done in a more easy way, then from >> my side I'm all in. >> I believe that re-using the armbian patches is easier as it makes >> maintenance much easier, there are more supported SBCs and also there is >> much more testing involved in armbian and frequent updates fix those >> bugs. > I did check your layer and it seems that you're not using sunxi-mali > for opengl HW acceleration only mesa so SW rendering? Thanks. >> Please consider it and I can help as much as I can and my time allows >> for that integration. >> >> Regards, >> Dimitris >> >> > Marek >> On Tue, May 28, 2019 at 12:56 PM Enrico >> wrote: >>> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos >>> wrote: > I was thinking about this also, too. The only reason is that in > meta-sunxi they do a great job and they keep their layer clean, which > is great I think. The other layers are just based on the armbian >
[yocto] Issue with INCOMPATIBLE_LICENSE
Hi all,
We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
blindly updated all upstream layers we use and we found out (during
integration phase, no need to send lawyers :) ) that even though we have
GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
conf/local.conf
INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
LICENSE = "GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 |
The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial
)"
My understanding of the above LICENSE is that even though I have GPLv3
blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
package got built. I'm not really happy with Qt doing that (no warning,
no LICENSE_FLAGS). Quick question unrelated to the actual important
question:
Would it be possible (theoritically, I know you've nothing to do with
maintenance of meta-qt5; also not tested, just "pseudo-code") to have
something like:
python() {
if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
d.setVar("LICENSE_FLAGS", "commercial")
}
so if we are blacklisting GPLv3, we have to add commercial_qtbase to
LICENSE_FLAGS_WHITELIST to be able to build it.
So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
well and qtbase is still building. How so?
For me, it results in the following:
LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 |
not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
which in the end looks like:
LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
which is basically:
LICENSE = "not-compat"
Is there an error in this simplification?
Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
Have I missed something?
Is there something actually buggy in the INCOMPATIBLE_LICENSE
implementation?
Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
I wanted to exclude license "aliases" not being supported by
INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
is said in the mega-manual).
I want to be sure to not be able to build qt >= 5.7, we're never too far
from an unfortunate upgrade or people in the company not knowing we
cannot use qt >= 5.7.
Thanks,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.sch...@streamunlimited.com, www.streamunlimited.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Debugging deployment of kernel image
Hey, I'm currently in the process of updating our yocto (sumo) with a new kernel version from a supplier (NXP) and I'm having some issues, we somehow broke deployment of the linux kernel: I get the Image & symlink in my images folder, but it does not end up in my rootfs. It SHOULD end up at /boot. My system boots u-boot and searches for the kernel (and fails ofc). If I manually place my kernel, everything is fine. I would like to find out where in my recipes this goes south: I've checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-linux-imx and the kernel and the expected kernel Image and symlink is there alongside the .dtb files. The dtb files get deployed as expected, but my kernel does not. I've also checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-rpms// , where I've got a kernel-image-image-4.14.78-+-4.14.78-r0..rpm, which contains the kernel and the symlink. Which brings me into an area of yocto I'm not used to, since usually THAT part worked for me ;-) So if a RPM is generated, but not properly installed, where do I continue my debugging efforts? I've already checked the output of bitbake -e linux-imx, but I only used -e only to debug my recipes (how stuff expands), so this was more of a "random looking at stuff" to figure things out. Any help appreciated. - Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python module not found when using autotools
On Thu, 30 May 2019 at 21:27, Serkan Türker wrote: > I understand the process of debugging build failures. I am just confused why > my approach doesn't work. > "python-soundcloud.bb" has the same format like other python module recipes > in meta-oe. > In tizonia.bb, I have added "python-soundcloud" to DEPENDS, so I assumed > bitbake would resolve the necessary path's, which are necessary for the build. > It is also not only my fault not being able to fix this, it is also largely > related to the fact, that there is not much documentation around how to start > developing with Yocto in general. *How* is it looking for the module. If as Alex said, it is running the *native* Python, then it won't be finding any *target* modules that you have DEPENDed on. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to extract files from wic.gz image?
Hi, What command and tools to extract files from Yocto / bitbake image such as dev-image-20190528085324.rootfs.wic.gz? I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz to IMX, I was advised to extract the archive and use "uuu
Re: [yocto] How to extract files from wic.gz image?
This web page can help you (my best guess): https://github.com/FrankBau/meta-marsboard-bsp/wiki/Prepare-SD-card Zoran ___ On Fri, May 31, 2019 at 2:22 PM JH wrote: > > Hi, > > What command and tools to extract files from Yocto / bitbake image > such as dev-image-20190528085324.rootfs.wic.gz? > > I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz > to IMX, I was advised to extract the archive and use "uuu
Re: [yocto] How to extract files from wic.gz image?
On Fri, May 31, 2019 at 10:21:40PM +1000, JH wrote: > Hi, > > What command and tools to extract files from Yocto / bitbake image > such as dev-image-20190528085324.rootfs.wic.gz? > > I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz > to IMX, I was advised to extract the archive and use "uuu
Re: [yocto] Difference between DEPENDS and BUILD-DEPENDS
Thank you so much,now its clear. Regards, Archana On Sat, 2019-05-25 at 14:32 +0100, Burton, Ross wrote: > On Sat, 25 May 2019 at 14:28, Archana Polampalli > wrote: > > > > i am working on one open source project,for this i have to add some > > debian packages as yocto recipies. > > i am trying to add "audit" recipe,so iam trying to understand the > > audit > > debian package ,i got struck between "depends" and "build-depends" > Debian Build-Depends == OpenEmbedded DEPENDS > Debian Depends == OpenEmbedded RDEPENDS > > Ross The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
Hi, i try to keep it maintained, but now i just have a lime2 for testing on real hardware, and i don't have the resources to do test builds for all the supported boards. Your help would be welcome, i can't check right now if i have the rights to add you as co-maintainer, anyway i will add you. Thanks for the help! Enrico On Mon, May 27, 2019 at 4:50 PM Belisko Marek wrote: > > Hello, > > I'm just curious if meta-sunxi is still maintained? I was contributed > to layer back while and when look now thud branch is un-compilable > (dri2proto not replaced) and warrior branch not created yet. There is > 14 issues + 6 pending pull requests. Added maintainers also in CC. I > think it would be good to have sunxi properly maintained as boards > with sunxi processors are popular. I can give a hand as co-maintainer > if necessary. Thanks a lot. > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos wrote: > > > > > I was thinking about this also, too. The only reason is that in meta-sunxi > > they do a great job and they keep their layer clean, which is great I > > think. The other layers are just based on the armbian distro, which is a > > lot different, but for me it was much easier to integrate their patches, > > patching scripts and bootloader scripts to a Yocto layer. That way the only > > thing I do is that from time to time I just integrate their new patches and > > that's it. There's no development in the layer is just re-use of the > > armbian work and a wrapper around it. Therefore, it's hard, even no doable > > to put those different architectures together. But definitely that decision > > also bothered me a lot before I create the layer and I also don't like time > > to be spend on the same thing from different people. Nevertheless, from my > > point of view I couldn't find a way to put those things together. I've > > tried but I couldn't do it. > > > > Therefore, it was easier for me to do it the way I've done it. And after > > all, although it doesn't seem right, at the same time this is the beauty of > > the open source. I think the layers are just incompatible in the way that > > they are do things. Also it's not bad to have alternatives. > > > > Sunxi is a great community and I believe many of the armbian patches are > > coming from there. Others not. Of course, having them all together would be > > nice. But I don't think that it's possible because of the different > > approach. It would be great to integrate all those different layers in meta-sunxi,the main problem is that usually they come with their own bootloader/kernel/etc so you have to *maintain* all these different configurations. Infact in the past i refused to do such things because i didn't have the time to maintain all those different versions, it was just easier to support what was already in mainline uboot/kernel. But of course if someone wants to do it then it's welcome, the worst thing that can happen is that once an arch gets unmaintained it will be removed. One thing that can be done anyway is to have those external layers linked in the readme, so at least people will know they exist. Enrico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto 2.7: basehash / taskhash mismatch when disabling uninative
Hi there, I'm upgrading from Yocto 2.5 to 2.7. I have a recipe that (for legacy reason-) builds a 32bit "-native" executable. I am disabling uninative by setting SSTATEPOSTUNPACKFUNCS_remove = "uninative_changeinterp" This worked well with Yocto 2.5, but with Yocto 2.7 I'm getting ERROR: When reparsing virtual:native:my-32bit-recipe_1.0.bb.do_populate_sysroot, the basehash value changed from to ERROR: When reparsing virtual:native:my-32bit-recipe_1.0.bb.do_populate_lic, the basehash value changed from to ERROR: my-32bit-recipe-native-1.0-r0 do_populate_sysroot: Taskhash mismatch versus for virtual:native:my-32bit-recipe_1.0.bb.do_populate_sysroot [... lots of these...] Any pointers would be appreciated! Thanks, Wolfgang-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-oe][PATCH] utils.c: close all file descriptors after completing a ptest
vredir ptest fails since too many file descriptors were open.
>From the failed ptest log:
run-vredir
87,88c87,88
< ./vredir6.sub: line 10: /dev/null: Too many open files
< ./vredir6.sub: line 13: /dev/null: Too many open files
FAIL: run-vredir
Added function to close file descriptors before starting a new process.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy Macleod
---
utils.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/utils.c b/utils.c
index 504df0b..05c2bfe 100644
--- a/utils.c
+++ b/utils.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -240,6 +241,23 @@ filter_ptests(struct ptest_list *head, char **ptests, int
ptest_num)
return head_new;
}
+/* Close all fds from 3 up to 'ulimit -n'
+ * i.e. do not close STDIN, STDOUT, STDERR.
+ * Typically called in in a child process after forking
+ * but before exec as a good policy especially for security.
+ */
+static void
+close_fds(void)
+{
+ struct rlimit curr_lim;
+ getrlimit(RLIMIT_NOFILE, &curr_lim);
+
+ int fd;
+ for (fd=3; fd < curr_lim.rlim_cur; fd++) {
+ (void) close(fd);
+ }
+}
+
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
@@ -252,6 +270,7 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
+ close_fds();
execv(run_ptest, argv);
exit(1);
--
2.20.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-oe][PATCH] utils.c: close all file descriptors after completing a ptest
Thanks Sakib.
Next time please use --prefix to add the ptest-runner tag:
so you'll have a subject line like:
[meta-oe][ptest-runner] utils.c: close all file descriptors after
completing a ptest
The subject line is wrongg since we are closing the fds
*before* the tests. Resend with something like:
utils.c: close all fds in child for each ptest
Wait to see if Anibal has any comment then send a v2
with a 'v2' prefix in the subject like:
[yocto] [ptest-runner][PATCHv2 1/3] Makefile: libcheck now requires
to link subunit
Thanks,
../Randy
On 5/31/19 1:44 PM, Sakib Sajal wrote:
vredir ptest fails since too many file descriptors were open.
From the failed ptest log:
run-vredir
87,88c87,88
< ./vredir6.sub: line 10: /dev/null: Too many open files
< ./vredir6.sub: line 13: /dev/null: Too many open files
FAIL: run-vredir
Added function to close file descriptors before starting a new process.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy Macleod
---
utils.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/utils.c b/utils.c
index 504df0b..05c2bfe 100644
--- a/utils.c
+++ b/utils.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -240,6 +241,23 @@ filter_ptests(struct ptest_list *head, char **ptests, int
ptest_num)
return head_new;
}
+/* Close all fds from 3 up to 'ulimit -n'
+ * i.e. do not close STDIN, STDOUT, STDERR.
+ * Typically called in in a child process after forking
+ * but before exec as a good policy especially for security.
+ */
+static void
+close_fds(void)
+{
+ struct rlimit curr_lim;
+ getrlimit(RLIMIT_NOFILE, &curr_lim);
+
+ int fd;
+ for (fd=3; fd < curr_lim.rlim_cur; fd++) {
+ (void) close(fd);
+ }
+}
+
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
@@ -252,6 +270,7 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
+ close_fds();
execv(run_ptest, argv);
exit(1);
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] npm package issue with do_package split_and_strip_files
Hi, I'm adding recipe for nodejs package and all steps works fine just when packaging is done I get strange error like: ['arm-poky-linux-gnueabi-strip', '--remove-section=.comment', '--remove-section=.note', '/home/marek/projects/tst/.build-opi/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ifu/4.5.2-r0/sysroot-destdir/usr/lib/node/camera/node_modules/usage/compiled/sunos/ia32/0.10/sysinfo.node']' Looks like it want strip build executable not for arm arch (I'm building for arm). In recipe I just fetch sources and include npm class. Thanks. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-oe][PATCH] utils.c: close all file descriptors after completing a ptest
LGTM, pushed.
http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/commit/?id=fb93c99e1e771a8ada0476b76da6f2ba665e03ba
Thanks!,
Anibal
On Fri, 31 May 2019 at 12:53, Randy MacLeod
wrote:
> Thanks Sakib.
>
> Next time please use --prefix to add the ptest-runner tag:
> so you'll have a subject line like:
>
> [meta-oe][ptest-runner] utils.c: close all file descriptors after
> completing a ptest
>
> The subject line is wrongg since we are closing the fds
> *before* the tests. Resend with something like:
> utils.c: close all fds in child for each ptest
>
>
> Wait to see if Anibal has any comment then send a v2
> with a 'v2' prefix in the subject like:
> [yocto] [ptest-runner][PATCHv2 1/3] Makefile: libcheck now requires
> to link subunit
>
> Thanks,
> ../Randy
>
> On 5/31/19 1:44 PM, Sakib Sajal wrote:
> > vredir ptest fails since too many file descriptors were open.
> >
> > From the failed ptest log:
> > run-vredir
> > 87,88c87,88
> > < ./vredir6.sub: line 10: /dev/null: Too many open files
> > < ./vredir6.sub: line 13: /dev/null: Too many open files
> > FAIL: run-vredir
> >
> > Added function to close file descriptors before starting a new process.
> >
> > Signed-off-by: Sakib Sajal
> > Signed-off-by: Randy Macleod
> > ---
> > utils.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/utils.c b/utils.c
> > index 504df0b..05c2bfe 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -240,6 +241,23 @@ filter_ptests(struct ptest_list *head, char
> **ptests, int ptest_num)
> > return head_new;
> > }
> >
> > +/* Close all fds from 3 up to 'ulimit -n'
> > + * i.e. do not close STDIN, STDOUT, STDERR.
> > + * Typically called in in a child process after forking
> > + * but before exec as a good policy especially for security.
> > + */
> > +static void
> > +close_fds(void)
> > +{
> > + struct rlimit curr_lim;
> > + getrlimit(RLIMIT_NOFILE, &curr_lim);
> > +
> > + int fd;
> > + for (fd=3; fd < curr_lim.rlim_cur; fd++) {
> > + (void) close(fd);
> > + }
> > +}
> > +
> > static inline void
> > run_child(char *run_ptest, int fd_stdout, int fd_stderr)
> > {
> > @@ -252,6 +270,7 @@ run_child(char *run_ptest, int fd_stdout, int
> fd_stderr)
> > dup2(fd_stdout, STDOUT_FILENO);
> > // XXX: Redirect stderr to stdout to avoid buffer ordering
> problems.
> > dup2(fd_stdout, STDERR_FILENO);
> > + close_fds();
> > execv(run_ptest, argv);
> >
> > exit(1);
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
