subject:"\[yocto\] #yocto #zeus"

Re: [yocto] Yocto Zeus -docker/PREEMPT_RT

2022-02-16 Thread Leon Woestenberg

Hello Steven,

> Last entry, from July 2021, in this blog says not supported;
>> Docker for RTOS? - General Discussions / Feature Requests - Docker Community 
>> Forums

No, that remark is completely wrong and is mixing up things.
"RTLinux" has nothing to do with the mainstream Linux kernel (except
that RTLinux can run the Linux kernel underneath)
Forget about those remarks.

Mainstream Linux is now almost fully-featured with the PREEMPT_RT work
merged, and the Linux kernel can be configured as an RTOS capable
kernel.
There is more to hard real-time than just the kernel, but that is the
kernel part.

I would see *no reason* why Docker should not run on Linux, even when
preemptive realtime is enabled.
In contrast when searching for the PREEMPT_RT / Docker combination I
see successful results.

What is probably the cause for Docker not working, is that the kernel
configuration for the PREEMPT_RT a.k.a. "-rt" kernel in Yocto does not
enable all name space support and other capabilities that Docker
depends on.

I would start comparing .config files at this point, together with the
debug/log output of Docker.
Especially first learn which CONFIG_ options Docker depends on.

Regards,

--
Leon Woestenberg
l...@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

On Wed, Feb 16, 2022 at 1:15 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
>
> I have 2 platforms one with a standard kernel the other using PREEMPT_RT 
> kernel… both work as expected.
>
>
>
> All things being equal, when I add docker container support to both 
> platforms, the standard kernel works just fine, but on the
>
> PREEMPT_RT kernel docker does not appear to initialize/work correctly…
>
>
>
> I have also tested using both ARM & Intel based HW, and appear tosee the same 
> behavior on both.
>
>
>
> Checking online it appears there is chatter about whether docker will run 
> correctly under a PREEMPT_RT kernel.
>
> Example:
>
>
>

>>
>
> Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this 
> combination supported ?
>
>  >
> I am currently running zeus based platforms, docker is at version 19.03.2-ce.
>
>
>
> Is there a patch to correct for the compatibility issues being seen ?, or
>
> Is there a yocto version I might move to which supports both correctly ?
>
>
>
> Any input on this would be greatly appreciated.
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56208): https://lists.yoctoproject.org/g/yocto/message/56208
Mute This Topic: https://lists.yoctoproject.org/mt/89183692/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Zeus -docker/PREEMPT_RT

2022-02-16 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I have 2 platforms one with a standard kernel the other using PREEMPT_RT 
kernel... both work as expected.

All things being equal, when I add docker container support to both platforms, 
the standard kernel works just fine, but on the
PREEMPT_RT kernel docker does not appear to initialize/work correctly...

I have also tested using both ARM & Intel based HW, and appear tosee the same 
behavior on both.

Checking online it appears there is chatter about whether docker will run 
correctly under a PREEMPT_RT kernel.
Example:

Last entry, from July 2021, in this blog says not supported;
Docker for RTOS? - General Discussions / Feature Requests - Docker Community 
Forums

Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this 
combination supported ?

I am currently running zeus based platforms, docker is at version 19.03.2-ce.

Is there a patch to correct for the compatibility issues being seen ?, or
Is there a yocto version I might move to which supports both correctly ?

Any input on this would be greatly appreciated.

Thanks,
Steve



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56207): https://lists.yoctoproject.org/g/yocto/message/56207
Mute This Topic: https://lists.yoctoproject.org/mt/89183692/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

2022-02-10 Thread Zoran

Dule, Dule, Dudule!

Slusaj i prati sta ti YOCTO velicine pricaju! I pokusaj sam da se
snadjes, jer te dobro navode! ;-)

Zee
___

On Fri, Feb 11, 2022 at 8:38 AM Dusan Radic  wrote:
>
> Here is the error:
>
> | .../kernel-source/include/linux/log2.h:22:1: warning: ignoring
> attribute 'noreturn' because it conflicts with attribute 'const'
> [-Wattributes]
> |22 | int ilog2_NaN(void);
> |   | ^~~
> | /tmp/ccA2wTxM.s: Assembler messages:
> | /tmp/ccA2wTxM.s:3486: Error: .err encountered
> | /tmp/ccA2wTxM.s:3546: Error: .err encountered
> | .../kernel-source/scripts/Makefile.build:258: recipe for target
> 'fs/fat/dir.o' failed
> | make[4]: *** [fs/fat/dir.o] Error 1
> | make[4]: *** Waiting for unfinished jobs
> |   CC  fs/cifs/smb2maperror.o
> | In file included from .../kernel-source/include/linux/kernel.h:11,
>
> However, now that I have switched to linux-imx-4.14.98 I made
> significant progress.
> It looks like it's going to work, I'll keep you posted.
>
> Best regards,
> Dule
>
> On Thu, Feb 10, 2022 at 6:20 PM Khem Raj  wrote:
> >
> >
> >
> > On 2/10/22 8:56 AM, Dusan Radic wrote:
> > > Hello,
> > >
> > > I am trying to upgrade my distro from rocko to zeus.
> > > After I fixed all the initial parsing and build problems I have
> > > reached a point where the linux-imx doesn't build. Maybe I am
> > > underestimating the task in front of me, but I have already seen it
> > > done.
> > >
> > > The error looks like this:
> > >
> > > | .../kernel-source/Makefile:947: recipe for target 'fs' failed
> > > | make[2]: *** [fs] Error 2
> > > | Makefile:146: recipe for target 'sub-make' failed
> > > | make[1]: *** [sub-make] Error 2
> > > | Makefile:24: recipe for target '__sub-make' failed
> > > | make: *** [__sub-make] Error 2
> > > | WARNING: exit code 1 from a shell command.
> > > |
> > > ERROR: Task 
> > > (.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
> > > failed with exit code '1'
> > >
> > > Is it possible that I am using the wrong linux-imx version? I have
> > > tried a few but to no avail.
> > >
> >
> > perhaps there is more specific compiler error in logs above that ?
> >
> > > Thanks in advance.
> > >
> > > Best regards,
> > > Dule
> > >
> > >
> > >
> > >
> > >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56155): https://lists.yoctoproject.org/g/yocto/message/56155
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

2022-02-10 Thread Dusan Radic

Here is the error:

| .../kernel-source/include/linux/log2.h:22:1: warning: ignoring
attribute 'noreturn' because it conflicts with attribute 'const'
[-Wattributes]
|22 | int ilog2_NaN(void);
|   | ^~~
| /tmp/ccA2wTxM.s: Assembler messages:
| /tmp/ccA2wTxM.s:3486: Error: .err encountered
| /tmp/ccA2wTxM.s:3546: Error: .err encountered
| .../kernel-source/scripts/Makefile.build:258: recipe for target
'fs/fat/dir.o' failed
| make[4]: *** [fs/fat/dir.o] Error 1
| make[4]: *** Waiting for unfinished jobs
|   CC  fs/cifs/smb2maperror.o
| In file included from .../kernel-source/include/linux/kernel.h:11,

However, now that I have switched to linux-imx-4.14.98 I made
significant progress.
It looks like it's going to work, I'll keep you posted.

Best regards,
Dule

On Thu, Feb 10, 2022 at 6:20 PM Khem Raj  wrote:
>
>
>
> On 2/10/22 8:56 AM, Dusan Radic wrote:
> > Hello,
> >
> > I am trying to upgrade my distro from rocko to zeus.
> > After I fixed all the initial parsing and build problems I have
> > reached a point where the linux-imx doesn't build. Maybe I am
> > underestimating the task in front of me, but I have already seen it
> > done.
> >
> > The error looks like this:
> >
> > | .../kernel-source/Makefile:947: recipe for target 'fs' failed
> > | make[2]: *** [fs] Error 2
> > | Makefile:146: recipe for target 'sub-make' failed
> > | make[1]: *** [sub-make] Error 2
> > | Makefile:24: recipe for target '__sub-make' failed
> > | make: *** [__sub-make] Error 2
> > | WARNING: exit code 1 from a shell command.
> > |
> > ERROR: Task 
> > (.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
> > failed with exit code '1'
> >
> > Is it possible that I am using the wrong linux-imx version? I have
> > tried a few but to no avail.
> >
>
> perhaps there is more specific compiler error in logs above that ?
>
> > Thanks in advance.
> >
> > Best regards,
> > Dule
> >
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56154): https://lists.yoctoproject.org/g/yocto/message/56154
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

2022-02-10 Thread Scott Murray

On Thu, 10 Feb 2022, Dusan Radic wrote:

> Hello,
>
> I am trying to upgrade my distro from rocko to zeus.
> After I fixed all the initial parsing and build problems I have
> reached a point where the linux-imx doesn't build. Maybe I am
> underestimating the task in front of me, but I have already seen it
> done.
>
> The error looks like this:
>
> | .../kernel-source/Makefile:947: recipe for target 'fs' failed
> | make[2]: *** [fs] Error 2
> | Makefile:146: recipe for target 'sub-make' failed
> | make[1]: *** [sub-make] Error 2
> | Makefile:24: recipe for target '__sub-make' failed
> | make: *** [__sub-make] Error 2
> | WARNING: exit code 1 from a shell command.
> |
> ERROR: Task 
> (.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
> failed with exit code '1'
>
> Is it possible that I am using the wrong linux-imx version? I have
> tried a few but to no avail.

AFAICS 4.1.15 doesn't match any kernel recipes in the zeus branches of
either meta-freescale or meta-imx, it might go easier if you based off of
the 5.4.x kernel recipes one of those use...

Scott


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56152): https://lists.yoctoproject.org/g/yocto/message/56152
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

2022-02-10 Thread Khem Raj




On 2/10/22 8:56 AM, Dusan Radic wrote:

Hello,

I am trying to upgrade my distro from rocko to zeus.
After I fixed all the initial parsing and build problems I have
reached a point where the linux-imx doesn't build. Maybe I am
underestimating the task in front of me, but I have already seen it
done.

The error looks like this:

| .../kernel-source/Makefile:947: recipe for target 'fs' failed
| make[2]: *** [fs] Error 2
| Makefile:146: recipe for target 'sub-make' failed
| make[1]: *** [sub-make] Error 2
| Makefile:24: recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task 
(.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
failed with exit code '1'

Is it possible that I am using the wrong linux-imx version? I have
tried a few but to no avail.



perhaps there is more specific compiler error in logs above that ?


Thanks in advance.

Best regards,
Dule






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56151): https://lists.yoctoproject.org/g/yocto/message/56151
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus Problem with moving from rocko to zeus

2022-02-10 Thread Dusan Radic

Hello,

I am trying to upgrade my distro from rocko to zeus.
After I fixed all the initial parsing and build problems I have
reached a point where the linux-imx doesn't build. Maybe I am
underestimating the task in front of me, but I have already seen it
done.

The error looks like this:

| .../kernel-source/Makefile:947: recipe for target 'fs' failed
| make[2]: *** [fs] Error 2
| Makefile:146: recipe for target 'sub-make' failed
| make[1]: *** [sub-make] Error 2
| Makefile:24: recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task 
(.../meta-mylayer/recipes-kernel/linux/linux-imx_4.1.15.bb:do_compile)
failed with exit code '1'

Is it possible that I am using the wrong linux-imx version? I have
tried a few but to no avail.

Thanks in advance.

Best regards,
Dule

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56149): https://lists.yoctoproject.org/g/yocto/message/56149
Mute This Topic: https://lists.yoctoproject.org/mt/89050046/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus Best practices for packaging third party recipe tool output in another recipe on the building host

2022-02-09 Thread VINCI Maxime

Hi, I am quite new to Yocto/BitBake and I have a bit of a headache trying to 
figure out the best way to make use of a native tool in the following context:

I have one recipe that fetch and build third party libs and binaries, let's 
call it X.
I have another recipe that also fetch and build third party libs and binaries, 
those depending on X's libs, let's call it Y.
Y needs to run post installation scripts to generate some config files.
Those scripts are calling some of X's binaries to generate those files, 
therefore I added a dependency on X-native to be able to run those scripts on 
the building machine.
At the moment, I include those scripts in do_install[postfuncs] of Y-native 
recipe while adding it as dependency in Y recipe, as I wish those to files to 
be part of Y package.

Assuming what I am doing until there is alright (correct me if not), here comes 
my issue:
The way X is configured/compiled involves specifying the path where it will 
write any file it generates/manage (currently based on the 'datadir' prefix).
This implies that building X-native will also prefix this path with 
STAGING_DIR_NATIVE in X recipe context.
So, after using X-native binaries from within Y-native recipe I end up 
generating files in the wrong STAGING_DIR_NATIVE (ie. X recipe context), being 
unable to easily retrieve those as it's outside of Y recipe context.

Am I missing something here ?
I read about pkg_postinst and deferring them after sysroot creation, but this 
is not what I need if I wish to package to config files, right ?
If there are no other solution, I may resort not to package them and use this 
to generate them at image/sdk creation, but this does not seems clean to me.

Also, I wish not to patch X sources to enable some sort of runtime output path 
configuration.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56115): https://lists.yoctoproject.org/g/yocto/message/56115
Mute This Topic: https://lists.yoctoproject.org/mt/89019240/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] YOCTO Zeus: Qt remote objects compiler repc missing from sdk toolchain #toolchain #sdk #qtremoteobjects #repc

2021-08-19 Thread anthony . marchand

Hello,

I permit myself to contact you because I got a weird issue in my sdk toolchain.

So, as I need " qtremoteobjects" in my embedded linux image, I add it like this:


QT = " \
qtbase \
qtbase-dev \
qtbase-plugins \
qtbase-mkspecs \
qtbase-tools \
cinematicexperience \
qtgraphicaleffects \
qtquickcontrols \
qtquickcontrols2 \
qtquickcontrols-qmlplugins \
qtsvg \
qtserialport \
qtserialbus \
qtremoteobjects \
qtremoteobjects-dev \
qtmultimedia \
qtwebsockets \
"
PACKAGECONFIG_pn-qtvirtualkeyboard = "lang-fr_FR"
PACKAGECONFIG_DEFAULT_pn-qtbase = "widgets libs freetype tslib gles2 eglfs"

TOUCHSCREEN = " \
tslib tslib-conf tslib-tests tslib-calibrate \
"

IMAGE_INSTALL += " \
bash \
sudo \
environment \
opkg \
os-release \
${QT} \
"

#IMAGE_INSTALL_append_mx6 = " ${MX6TOOL}"

IMAGE_FEATURES += " \
ssh-server-openssh \
"

export IMAGE_BASENAME = "myimage"


So it's work fine when I flash it in my card, but after building SDK, "repc" is 
missing in /sysroots/cortexa9t2hf-neon-poky-linux-gnueabi /usr/bin .  More 
precisly, it is present, but located in:

/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/ usr/bin/.debug/repc

And when I compile my app, I got the following error:

Pre build error --> make[2]: 
/opt/poky/MY_SDK/sysroots/x86_64-pokysdk-linux/usr/bin/repc: Command not found

because "make" seems to try to find repc in "/usr/bin/repc" rather than " / 
usr/bin/.debug/repc" . But when I link or move repc from " / 
usr/bin/.debug/repc" to "/usr/bin/repc", it gives me a "segment fault error" 
when I try to make my app.
I saw a similar issue on the web but it does not resolve my problem: 
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/902941/processor-sdk-am437x-qt-remote-objects-compiler-repc-missing-from-sdk-toolchain

Does anyone already encontered this problem with qtremote control? Do you have 
got any idea about what is going wrong?

By advance, thanks for all, best reguards.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54510): https://lists.yoctoproject.org/g/yocto/message/54510
Mute This Topic: https://lists.yoctoproject.org/mt/84993425/21656
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Mute 
#qtremoteobjects:https://lists.yoctoproject.org/g/yocto/mutehashtag/qtremoteobjects
Mute #repc:https://lists.yoctoproject.org/g/yocto/mutehashtag/repc
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus

2021-06-30 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I am running with zeus 3.0.4 and appear to have an issue with the mount command 
supporting NFS... ?

Can someone explain the following and how I can get "mount" to support NFS ?

Trying to mount the UDM from the AIO
mount.nfs: Operation not permitted
Failed to mount the UDM from the AIO!
Trying tNFS: bad mount option value specified: minorversion=1

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54021): https://lists.yoctoproject.org/g/yocto/message/54021
Mute This Topic: https://lists.yoctoproject.org/mt/83893426/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

2021-05-13 Thread Zoran

Hello Rohit,

It is a good find. I also googled for the error, and found this as an
explanation:
https://www.yoctoproject.org/pipermail/yocto/2019-February/044153.html

I included Alex (Kanavin), who created the above mail.

Maybe Alex can give more light on the problem?

In the meantime, you should explore (by similarities) this pointer in
very details:
https://github.com/Xilinx/meta-virtualization/issues/4#issuecomment-590532621

Zoran
___

On Thu, May 13, 2021 at 8:25 AM rohit jadhav  wrote:
>
> Hi Zoran,
>log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls 
> command, So both files are identical.
>
> While surfing I found similar thread but its for different package  its as 
> follows :
> https://github.com/Xilinx/meta-virtualization/issues/4
>
> Can you please help out with this for our Package Hostapd ?
>
> Thanks and Regards
> Rohit
>
> On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic 
>  wrote:
>>
>> From the log log.do_rootfs.31340 file, there are the following:
>>
>> [1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.
>>
>> HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much 
>> from:
>> https://en.wikipedia.org/wiki/Hostapd
>>
>> It is kind of a hot spot, as my best understanding is.
>>
>> [2] Details of the failure are in
>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>
>> So, my best guess, looking into log.do_rootfs will tell us much more.
>>
>> Please, attach this one for our review as well.
>>
>> Thank you,
>> Zoran
>> ___
>>
>> On Wed, May 12, 2021 at 5:29 PM rohit jadhav  wrote:
>> >
>> > Hi Zoran ,
>> > I have attached the log file for your reference.
>> > Thank You
>> > Regards
>> > Rohit
>> >
>> > On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic 
>> >  wrote:
>> >>
>> >> > Log file in:
>> >> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> >> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> >> log.do_rootfs.31340
>> >>
>> >> Could you, please, attach a log file?
>> >>
>> >> Thank you,
>> >> Zoran
>> >> ___
>> >>
>> >>
>> >> On Wed, May 12, 2021 at 2:01 PM rohit jadhav  
>> >> wrote:
>> >>>
>> >>> Facing following issue :
>> >>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
>> >>> ['hostapd'] have failed. If the intention is to defer them to first boot,
>> >>> then please place them into pkg_postinst_ontarget_${PN} ().
>> >>> Deferring to first boot via 'exit 1' is no longer supported.
>> >>> Details of the failure are in 
>> >>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>> >>> ERROR: Logfile of failure stored in: 
>> >>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>> >>> ERROR: Task 
>> >>> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
>> >>>  failed with exit code '1'
>> >>>
>> >>> Please guide me if anyone have any idea to resolve.
>> >>>
>> >>> Thanks in advance.
>> >>> 
>> >>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53502): https://lists.yoctoproject.org/g/yocto/message/53502
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

2021-05-13 Thread rohit jadhav

Hi Zoran,
   log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls
command, So both files are identical.

While surfing I found similar thread but its for different package  its as
follows :
https://github.com/Xilinx/meta-virtualization/issues/4

Can you please help out with this for our Package Hostapd ?

Thanks and Regards
Rohit

On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> From the log log.do_rootfs.31340 file, there are the following:
>
> [1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.
>
> HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much
> from:
> https://en.wikipedia.org/wiki/Hostapd
>
> It is kind of a hot spot, as my best understanding is.
>
> [2] Details of the failure are in
>
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>
> So, my best guess, looking into log.do_rootfs will tell us much more.
>
> Please, attach this one for our review as well.
>
> Thank you,
> Zoran
> ___
>
> On Wed, May 12, 2021 at 5:29 PM rohit jadhav 
> wrote:
> >
> > Hi Zoran ,
> > I have attached the log file for your reference.
> > Thank You
> > Regards
> > Rohit
> >
> > On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
> >>
> >> > Log file in:
> >> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
> >> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
> >> log.do_rootfs.31340
> >>
> >> Could you, please, attach a log file?
> >>
> >> Thank you,
> >> Zoran
> >> ___
> >>
> >>
> >> On Wed, May 12, 2021 at 2:01 PM rohit jadhav 
> wrote:
> >>>
> >>> Facing following issue :
> >>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['hostapd'] have failed. If the intention is to defer them to first boot,
> >>> then please place them into pkg_postinst_ontarget_${PN} ().
> >>> Deferring to first boot via 'exit 1' is no longer supported.
> >>> Details of the failure are in
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
> >>> ERROR: Logfile of failure stored in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
> >>> ERROR: Task
> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
> failed with exit code '1'
> >>>
> >>> Please guide me if anyone have any idea to resolve.
> >>>
> >>> Thanks in advance.
> >>> 
> >>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53501): https://lists.yoctoproject.org/g/yocto/message/53501
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

2021-05-12 Thread Zoran

>From the log log.do_rootfs.31340 file, there are the following:

[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed.

HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from:
https://en.wikipedia.org/wiki/Hostapd

It is kind of a hot spot, as my best understanding is.

[2] Details of the failure are in
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.

So, my best guess, looking into log.do_rootfs will tell us much more.

Please, attach this one for our review as well.

Thank you,
Zoran
___

On Wed, May 12, 2021 at 5:29 PM rohit jadhav  wrote:
>
> Hi Zoran ,
> I have attached the log file for your reference.
> Thank You
> Regards
> Rohit
>
> On Wed, May 12, 2021 at 7:50 PM Zoran Stojsavljevic 
>  wrote:
>>
>> > Log file in:
>> > /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
>> > imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
>> log.do_rootfs.31340
>>
>> Could you, please, attach a log file?
>>
>> Thank you,
>> Zoran
>> ___
>>
>>
>> On Wed, May 12, 2021 at 2:01 PM rohit jadhav  wrote:
>>>
>>> Facing following issue :
>>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
>>> ['hostapd'] have failed. If the intention is to defer them to first boot,
>>> then please place them into pkg_postinst_ontarget_${PN} ().
>>> Deferring to first boot via 'exit 1' is no longer supported.
>>> Details of the failure are in 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
>>> ERROR: Logfile of failure stored in: 
>>> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
>>> ERROR: Task 
>>> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
>>>  failed with exit code '1'
>>>
>>> Please guide me if anyone have any idea to resolve.
>>>
>>> Thanks in advance.
>>> 
>>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53499): https://lists.yoctoproject.org/g/yocto/message/53499
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

2021-05-12 Thread Zoran

> Log file in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/
> imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/
*log.do_rootfs.31340*

Could you, please, attach a log file?

Thank you,
Zoran
___


On Wed, May 12, 2021 at 2:01 PM rohit jadhav 
wrote:

> Facing following issue :
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['hostapd'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
> ERROR: Logfile of failure stored in:
> /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
> ERROR: Task
> (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
> failed with exit code '1'
>
> Please guide me if anyone have any idea to resolve.
>
> Thanks in advance.
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53481): https://lists.yoctoproject.org/g/yocto/message/53481
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Zeus : facing error regarding hostapd #zeus

2021-05-12 Thread rohit jadhav

Facing following issue :
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of 
['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in 
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in: 
/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
ERROR: Task 
(/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
 failed with exit code '1'

Please guide me if anyone have any idea to resolve.

Thanks in advance.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53473): https://lists.yoctoproject.org/g/yocto/message/53473
Mute This Topic: https://lists.yoctoproject.org/mt/82769987/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

2021-02-08 Thread Khem Raj

That means it’s having issues with checksums is there any AUTOREV being
used ?

I would suggest to build without your changes and see if you can get an
eSDK

On Mon, Feb 8, 2021 at 9:09 AM Monsees, Steven C (US) via
lists.yoctoproject.org 
wrote:

>
> I configured SDK for:
>
> SDK_EXT_TYPE = "minimal"
> SDK_INCLUDE_TOOLCHAIN = "1"
> SDK_INCLUDE_PKGDATA = "0"
>
> And I still see "Error:  Failed to generate filtered task list for
> extensible SDK..."
>
> In my latest log I also see:
>
> "Error: Task quilt-native.do_fetch attempted to execute unexpectedly...
>  ...
>  This is usually due to missing ser=tscene tasks...
> ..."
>
> Why might the filtered task list fail to generate correctly ?
>
> This appears to be the real issue, and then it dies a slow death...
>
> Thanks,
> Steve
>
>
> -Original Message-
> From: Khem Raj 
> Sent: Tuesday, February 2, 2021 10:37 PM
> To: Monsees, Steven C (US) 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
> it seems bitbake does not execute when its trying to configure eSDK for
> install. Perhaps you can try to see some logs inside the esdk build area to
> check if there is further info.
> secondly, try to build an esdk for core-image-minimal and see if that
> works.
>
> On Fri, Jan 29, 2021 at 3:04 PM Monsees, Steven C (US) via
> lists.yoctoproject.org  baesystems@lists.yoctoproject.org> wrote:
> >
> >
> >
> > I need some help in understanding why the SDK EXT is failing to build
> > under zeus…
> >
> >
> >
> > Can someone explain why the extended sdk build fails and how I might
> resolve ?
> >
> >
> >
> > sbcb-defaultfs kernel builds and boots correctly…
> >
> >
> >
> > SDK builds under zeus for sbcb-defaultfs :
> >
> >
> >
> > bitbake sbcb-defaultfs-full -c populate_sdk-WORKING CORRECTLY
> >
> >
> >
> > bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the
> following Errors:
> >
> >
> >
> > 17:13 smonsees@yix490016
> > /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/s
> > bcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext
> >
> > Loading cache: 100%
> > |###| Time:
> > 0:00:00
> >
> > Loaded 3645 entries from dependency cache.
> >
> > NOTE: Resolving any missing task queue dependencies
> >
> >
> >
> > Build Configuration:
> >
> > BB_VERSION   = "1.44.0"
> >
> > BUILD_SYS= "x86_64-linux"
> >
> > NATIVELSBSTRING  = "rhel-7.9"
> >
> > TARGET_SYS   = "x86_64-poky-linux"
> >
> > MACHINE  = "sbcb-default"
> >
> > DISTRO   = "limws"
> >
> > DISTRO_VERSION   = "3.0.4"
> >
> > TUNE_FEATURES= "m64 corei7"
> >
> > TARGET_FPU   = ""
> >
> > meta
> >
> > meta-poky=
> "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
> >
> > meta-perl
> >
> > meta-python
> >
> > meta-filesystems
> >
> > meta-networking
> >
> > meta-initramfs
> >
> > meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
> >
> > meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
> >
> > meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
> >
> > meta-intel
> >
> > workspace=
> "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"
> >
> >
> >
> > Initialising tasks: 100%
> > |##| Time: 0:00:04
> >
> > Checking sstate mirror object availability: 100%
> > |##| Time: 0:00:00
> >
> > Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59%
> > match, 91% complete)
> >
> > NOTE: Executing Tasks
> >
> > NOTE: Setscene tasks completed
> >
> > WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch:
> > Failed to fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting
> > MIRRORS if available
> >
> > WARNING: nativesdk-libnss-nis-3.1

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

2021-02-08 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I configured SDK for:

SDK_EXT_TYPE = "minimal"
SDK_INCLUDE_TOOLCHAIN = "1"
SDK_INCLUDE_PKGDATA = "0"

And I still see "Error:  Failed to generate filtered task list for extensible 
SDK..."

In my latest log I also see:

"Error: Task quilt-native.do_fetch attempted to execute unexpectedly...
 ...
 This is usually due to missing ser=tscene tasks...
..."

Why might the filtered task list fail to generate correctly ?

This appears to be the real issue, and then it dies a slow death...

Thanks,
Steve


-Original Message-
From: Khem Raj  
Sent: Tuesday, February 2, 2021 10:37 PM
To: Monsees, Steven C (US) 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


it seems bitbake does not execute when its trying to configure eSDK for 
install. Perhaps you can try to see some logs inside the esdk build area to 
check if there is further info.
secondly, try to build an esdk for core-image-minimal and see if that works.

On Fri, Jan 29, 2021 at 3:04 PM Monsees, Steven C (US) via 
lists.yoctoproject.org  
wrote:
>
>
>
> I need some help in understanding why the SDK EXT is failing to build 
> under zeus…
>
>
>
> Can someone explain why the extended sdk build fails and how I might resolve ?
>
>
>
> sbcb-defaultfs kernel builds and boots correctly…
>
>
>
> SDK builds under zeus for sbcb-defaultfs :
>
>
>
> bitbake sbcb-defaultfs-full -c populate_sdk-WORKING CORRECTLY
>
>
>
> bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the 
> following Errors:
>
>
>
> 17:13 smonsees@yix490016 
> /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/s
> bcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext
>
> Loading cache: 100% 
> |###| Time: 
> 0:00:00
>
> Loaded 3645 entries from dependency cache.
>
> NOTE: Resolving any missing task queue dependencies
>
>
>
> Build Configuration:
>
> BB_VERSION   = "1.44.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "rhel-7.9"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> MACHINE  = "sbcb-default"
>
> DISTRO   = "limws"
>
> DISTRO_VERSION   = "3.0.4"
>
> TUNE_FEATURES= "m64 corei7"
>
> TARGET_FPU   = ""
>
> meta
>
> meta-poky= 
> "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
>
> meta-perl
>
> meta-python
>
> meta-filesystems
>
> meta-networking
>
> meta-initramfs
>
> meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
>
> meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
>
> meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
>
> meta-intel
>
> workspace= "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"
>
>
>
> Initialising tasks: 100% 
> |##| Time: 0:00:04
>
> Checking sstate mirror object availability: 100% 
> |##| Time: 0:00:00
>
> Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% 
> match, 91% complete)
>
> NOTE: Executing Tasks
>
> NOTE: Setscene tasks completed
>
> WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: 
> Failed to fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting 
> MIRRORS if available
>
> WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: 
> Failed to fetch URL git://github.com/thkukuk/libnss_nis, attempting 
> MIRRORS if available
>
> NOTE: Excluding local workspace layer 
> /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/s
> bcb-default/workspace from extensible SDK
>
> ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate 
> filtered task list for extensible SDK:
>
> /bin/bash: line 0: .: .: is a directory
>
> ERROR: bitbake failed:
>
> /bin/sh: bitbake: command not found
>
> ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a 
> python function in exec_python_func() autogenerated:
>
>
>
> The stack trace of python calls that resulted in this exception/failure was:
>
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
> 
>
>  0001:
>
> *** 0002:copy_buildsystem(d)
>
>  0003:
>
> File: 
> '/disk0/scratch/smonsees/yocto/w

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

2021-02-02 Thread Khem Raj

it seems bitbake does not execute when its trying to configure eSDK
for install. Perhaps you can try to see some logs inside the esdk
build area to check if there is further info.
secondly, try to build an esdk for core-image-minimal and see if that works.

On Fri, Jan 29, 2021 at 3:04 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
>
> I need some help in understanding why the SDK EXT is failing to build under 
> zeus…
>
>
>
> Can someone explain why the extended sdk build fails and how I might resolve ?
>
>
>
> sbcb-defaultfs kernel builds and boots correctly…
>
>
>
> SDK builds under zeus for sbcb-defaultfs :
>
>
>
> bitbake sbcb-defaultfs-full -c populate_sdk-WORKING CORRECTLY
>
>
>
> bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the 
> following Errors:
>
>
>
> 17:13 smonsees@yix490016 
> /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>
>  bitbake sbcb-defaultfs-full -c populate_sdk_ext
>
> Loading cache: 100% 
> |###| Time: 0:00:00
>
> Loaded 3645 entries from dependency cache.
>
> NOTE: Resolving any missing task queue dependencies
>
>
>
> Build Configuration:
>
> BB_VERSION   = "1.44.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "rhel-7.9"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> MACHINE  = "sbcb-default"
>
> DISTRO   = "limws"
>
> DISTRO_VERSION   = "3.0.4"
>
> TUNE_FEATURES= "m64 corei7"
>
> TARGET_FPU   = ""
>
> meta
>
> meta-poky= 
> "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
>
> meta-perl
>
> meta-python
>
> meta-filesystems
>
> meta-networking
>
> meta-initramfs
>
> meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
>
> meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
>
> meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
>
> meta-intel
>
> workspace= "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"
>
>
>
> Initialising tasks: 100% 
> |##| Time: 0:00:04
>
> Checking sstate mirror object availability: 100% 
> |##| Time: 0:00:00
>
> Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% match, 91% 
> complete)
>
> NOTE: Executing Tasks
>
> NOTE: Setscene tasks completed
>
> WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: Failed to 
> fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting MIRRORS if 
> available
>
> WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: Failed 
> to fetch URL git://github.com/thkukuk/libnss_nis, attempting MIRRORS if 
> available
>
> NOTE: Excluding local workspace layer 
> /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/workspace
>  from extensible SDK
>
> ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate 
> filtered task list for extensible SDK:
>
> /bin/bash: line 0: .: .: is a directory
>
> ERROR: bitbake failed:
>
> /bin/sh: bitbake: command not found
>
> ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a 
> python function in exec_python_func() autogenerated:
>
>
>
> The stack trace of python calls that resulted in this exception/failure was:
>
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>
>  0001:
>
> *** 0002:copy_buildsystem(d)
>
>  0003:
>
> File: 
> '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
>  lineno: 444, function: copy_buildsystem
>
>  0440:sdk_ext_type = d.getVar('SDK_EXT_TYPE')
>
>  0441:if (sdk_ext_type != 'minimal' or sdk_include_toolchain or 
> derivative) and not sdk_include_nativesdk:
>
>  0442:# Create the filtered task list used to generate the sstate 
> cache shipped with the SDK
>
>  0443:tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
>
> *** 0444:create_filtered_tasklist(d, baseoutpath, tasklistfn, 
> conf_initpath)
>
>  0445:else:
>
>  0446:tasklistfn = None
>
>  0447:
>
>  0448:if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
>
> File: 
> '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
>  lineno: 180, function: create_filtered_tasklist
>
>  0176:# Clean out residue of running bitbake, which 
> check_sstate_task_list()
>
>  0177:# will effectively do
>
>  0178:clean_esdk_builddir(d, sdkbasepath)
>
>  0179:finally:
>
> *** 0180:os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath 
> + '/conf/local.conf')
>
>  0181:
>
>  0182:python copy_buildsystem () {
>
>  0183:import re
>
>  0184:import shutil
>
> Exception: FileNotFoundError: [Errno 2] No such file or directory: 
>

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

2021-02-01 Thread Monsees, Steven C (US) via lists.yoctoproject.org


Any ideas on how to resolve this extended SDK build issue ?

From: yocto@lists.yoctoproject.org  On Behalf Of 
Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Friday, January 29, 2021 6:04 PM
To: yocto@lists.yoctoproject.org
Subject: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


I need some help in understanding why the SDK EXT is failing to build under 
zeus...

Can someone explain why the extended sdk build fails and how I might resolve ?

sbcb-defaultfs kernel builds and boots correctly...

SDK builds under zeus for sbcb-defaultfs :

bitbake sbcb-defaultfs-full -c populate_sdk-WORKING CORRECTLY

bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the 
following Errors:

17:13 smonsees@yix490016 
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>
 bitbake sbcb-defaultfs-full -c populate_sdk_ext
Loading cache: 100% 
|###| Time: 0:00:00
Loaded 3645 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel
workspace= "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

Initialising tasks: 100% 
|##| Time: 0:00:04
Checking sstate mirror object availability: 100% 
|##| Time: 0:00:00
Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% match, 91% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: Failed to 
fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting MIRRORS if available
WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: Failed to 
fetch URL git://github.com/thkukuk/libnss_nis, attempting MIRRORS if available
NOTE: Excluding local workspace layer 
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/workspace
 from extensible SDK
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate 
filtered task list for extensible SDK:
/bin/bash: line 0: .: .: is a directory
ERROR: bitbake failed:
/bin/sh: bitbake: command not found
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
*** 0002:copy_buildsystem(d)
 0003:
File: 
'/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
 lineno: 444, function: copy_buildsystem
 0440:sdk_ext_type = d.getVar('SDK_EXT_TYPE')
 0441:if (sdk_ext_type != 'minimal' or sdk_include_toolchain or 
derivative) and not sdk_include_nativesdk:
 0442:# Create the filtered task list used to generate the sstate 
cache shipped with the SDK
 0443:tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
*** 0444:create_filtered_tasklist(d, baseoutpath, tasklistfn, 
conf_initpath)
 0445:else:
 0446:tasklistfn = None
 0447:
 0448:if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
File: 
'/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
 lineno: 180, function: create_filtered_tasklist
 0176:# Clean out residue of running bitbake, which 
check_sstate_task_list()
 0177:# will effectively do
 0178:clean_esdk_builddir(d, sdkbasepath)
 0179:finally:
*** 0180:os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + 
'/conf/local.conf')
 0181:
 0182:python copy_buildsystem () {
 0183:import re
 0184:import shutil
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf.bak'
 -> 
'/disk0/scratch/smonsees/yocto/w

[yocto] #yocto #zeus #sdk populate_sdk_ext build failing

2021-01-29 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I need some help in understanding why the SDK EXT is failing to build under 
zeus...

Can someone explain why the extended sdk build fails and how I might resolve ?

sbcb-defaultfs kernel builds and boots correctly...

SDK builds under zeus for sbcb-defaultfs :

bitbake sbcb-defaultfs-full -c populate_sdk-WORKING CORRECTLY

bitbake sbcb-defaultfs-full -c populate_sdk_ext  -Fails build with the 
following Errors:

17:13 smonsees@yix490016 
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>
 bitbake sbcb-defaultfs-full -c populate_sdk_ext
Loading cache: 100% 
|###| Time: 0:00:00
Loaded 3645 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.44.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "rhel-7.9"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "sbcb-default"
DISTRO   = "limws"
DISTRO_VERSION   = "3.0.4"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe  = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel   = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel
workspace= "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

Initialising tasks: 100% 
|##| Time: 0:00:04
Checking sstate mirror object availability: 100% 
|##| Time: 0:00:00
Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% match, 91% 
complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: Failed to 
fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting MIRRORS if available
WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: Failed to 
fetch URL git://github.com/thkukuk/libnss_nis, attempting MIRRORS if available
NOTE: Excluding local workspace layer 
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/workspace
 from extensible SDK
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate 
filtered task list for extensible SDK:
/bin/bash: line 0: .: .: is a directory
ERROR: bitbake failed:
/bin/sh: bitbake: command not found
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
*** 0002:copy_buildsystem(d)
 0003:
File: 
'/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
 lineno: 444, function: copy_buildsystem
 0440:sdk_ext_type = d.getVar('SDK_EXT_TYPE')
 0441:if (sdk_ext_type != 'minimal' or sdk_include_toolchain or 
derivative) and not sdk_include_nativesdk:
 0442:# Create the filtered task list used to generate the sstate 
cache shipped with the SDK
 0443:tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
*** 0444:create_filtered_tasklist(d, baseoutpath, tasklistfn, 
conf_initpath)
 0445:else:
 0446:tasklistfn = None
 0447:
 0448:if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
File: 
'/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass',
 lineno: 180, function: create_filtered_tasklist
 0176:# Clean out residue of running bitbake, which 
check_sstate_task_list()
 0177:# will effectively do
 0178:clean_esdk_builddir(d, sdkbasepath)
 0179:finally:
*** 0180:os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + 
'/conf/local.conf')
 0181:
 0182:python copy_buildsystem () {
 0183:import re
 0184:import shutil
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf.bak'
 -> 
'/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf'

ERROR: Logfile of failure stored in: 
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/temp/log.do_populate_sdk_ext.14130
ERROR: Task 
(/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_populate_sdk_ext)

[yocto] Yocto zeus, npm fetcher, bug

2021-01-07 Thread Zimmermann, Anthony

Hello,

I use yocto version 3.0.3 (zeus) and tried to install some node packages as 
described in the yocto manual [1].
I experienced that manipulating a sha512 checksum in a package-lock.json file 
does not affect the installation even though the purpose (or at least one of 
the purposes) of the lockdown file is to enable the validation of the checksums 
if I understand correctly.


This can be reproduced by installing node-red 1.0.2 using the recipe, 
shrinkwrap.json and package-lock.json files provided in the zeus branch of 
meta-iot-cloud [2], which is listed on openembedded.org [3]. Just replace some 
characters in any of the sha256 sums inside the package-lock.json and see that 
it does not affect the bitbake process.

I think the error is somewhere in the script poky/bitbake/lib/bb/fetch2/npm.py.
The function ‘download’ loads the lockdown file using json.load. The resulting 
dictionary is passed into the function ‘_getshrinkeddependencies’ and that 
function is supposed to check the checksum. The first thing that I arises my 
attention is that the source code in ‘_getshrinkeddependencies’ seems to only 
be able to calculate sha1 sums, but I find also sha512 in e.g. the 
package-lock.json mentioned above. The second thing that I think is very 
interesting, is that the condition ‘pkg in lockdown’ always returns False, no 
matter if the package seems to be present in the lockdown file or not.

[1] yocto manual: 
https:/www.yoctoproject.org/docs/3.0.3/mega-manual/mega-manual.html#creating-node-package-manager-npm-packages
[2] node red recipe: 
https://github.com/intel-iot-devkit/meta-iot-cloud/tree/zeus/recipes-node-red/node-red
[3] openembbed.org (noe-red recipe): 
https://layers.openembedded.org/layerindex/recipe/67980/

I think this is a bug. If it is not, I would really appreciate if someone could 
help me understand the npm fetcher.

Regards,
Anthony Zimmermann

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51920): https://lists.yoctoproject.org/g/yocto/message/51920
Mute This Topic: https://lists.yoctoproject.org/mt/79501649/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus #kernel -broken atomic modsset

2020-12-15 Thread Monsees, Steven C (US) via lists.yoctoproject.org


Ok, so I am trying to understand the impact of the following issue seen under 
our "zeus" based Intel platform build:

https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vet...@ffwll.ch/

The patch is currently preventing my image from going down the 
DRM_CLIENT_CAP_ATOMIC path...

I currently have algorithms centered around the GPU dependent on X and this 
path, and would like to be able to work around this, if possible.

My goal was to get our Yocto based platform in line with the current Yocto 
release, all our original code was done using the "rocko" release. I have now 
ported our Intel based build to "zeus" with this being our final issue...

Questions:


(1) If I wanted to rebuild the "zeus" 3.0.4 kernel to add debug code around 
this issue how would I go about doing this ?

(2)  Under my downloads directory I see linux-5.2.tar.xz is downloaded, tar 
ball is without the patch, so I am assuming the patch being applied after, 
correct ?

(3)  I do not see this built under the build tree after I build my Yocto image, 
Are some components under the builds tree removed after successfully being 
built ?, and how might I stop them from being deleted for inspection, etc. ?

(4)  When I perform "bitbake -e linux | grep ^T=" I see the following"

ERROR: Nothing PROVIDES 'linux'. Close matches:

  syslinux

  linuxptp

  linux-atm

Was the linux-5.2 package renamed on built or am I looking at the wrong package 
as my stating point ?

(5)  It appears the patch was added to the kernel 
(https://github.com/torvalds/linux/tree/master) about a year ago, has the patch 
been applied to any earlier pre-zeus releases ?

(6)  Will this X11 issue be addressed in future releases, i.e. "gatesgarth". 
"hardnott" ?

(7)  It is unclear but would you know about what release they might have broken 
this path ?

Thanks,
Steve



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51757): https://lists.yoctoproject.org/g/yocto/message/51757
Mute This Topic: https://lists.yoctoproject.org/mt/78974789/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus -broken atomic modsset

2020-12-09 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I do not see this issue under "rock", is it "zeus"/X11 specific or can it exist 
across the board depending on what is running in the backgroud ?

-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Khem Raj
Sent: Wednesday, December 9, 2020 2:06 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 11:05 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
> 
> So, this is expected ?, no current work around ?
> 

seems that way, I guess you can fix it on X11 side of things
> 
> -Original Message-
> From: yocto@lists.yoctoproject.org  On 
> Behalf Of Khem Raj
> Sent: Wednesday, December 9, 2020 2:00 PM
> To: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #zeus -broken atomic modsset
> 
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
> 
> 
> 
> On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
> wrote:
>> I'm building/running zeus 3.0.4 on intel platform...
>>
>> Can someone tell me why I might be seeing the following error and how 
>> to resolve it ?
> 
> https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.62
> 34-1-daniel.vet...@ffwll.ch/
> 
> might give some context
> 
>>
>> X.Org X Server 1.20.5
>>
>> X Protocol Version 11, Revision 0
>>
>> Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64
>>
>> Current Operating System: Linux sbcb-default 
>> 4.19.135-intel-pk-standard
>> #1 SMP *PREE broken atomic modeset userspace detected, disabling
>> atomic*
>>
>> MPT Mon Nov 2 15:55:20 UTC 2020 x86_64
>>
>> Thanks,
>>
>> Steve
>>
>>
>>
>>
>>
>>
>>
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51703): https://lists.yoctoproject.org/g/yocto/message/51703
Mute This Topic: https://lists.yoctoproject.org/mt/78835705/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus -broken atomic modsset

2020-12-09 Thread Khem Raj




On 12/9/20 11:05 AM, Monsees, Steven C (US) via lists.yoctoproject.org 
wrote:


So, this is expected ?, no current work around ?



seems that way, I guess you can fix it on X11 side of things


-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Khem Raj
Sent: Wednesday, December 9, 2020 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:

I'm building/running zeus 3.0.4 on intel platform...

Can someone tell me why I might be seeing the following error and how
to resolve it ?


https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vet...@ffwll.ch/

might give some context



X.Org X Server 1.20.5

X Protocol Version 11, Revision 0

Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64

Current Operating System: Linux sbcb-default
4.19.135-intel-pk-standard
#1 SMP *PREE broken atomic modeset userspace detected, disabling
atomic*

MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,

Steve










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51702): https://lists.yoctoproject.org/g/yocto/message/51702
Mute This Topic: https://lists.yoctoproject.org/mt/78835705/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus -broken atomic modsset

2020-12-09 Thread Monsees, Steven C (US) via lists.yoctoproject.org


So, this is expected ?, no current work around ?


-Original Message-
From: yocto@lists.yoctoproject.org  On Behalf Of 
Khem Raj
Sent: Wednesday, December 9, 2020 2:00 PM
To: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #zeus -broken atomic modsset

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
> I'm building/running zeus 3.0.4 on intel platform...
> 
> Can someone tell me why I might be seeing the following error and how 
> to resolve it ?

https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vet...@ffwll.ch/

might give some context

> 
> X.Org X Server 1.20.5
> 
> X Protocol Version 11, Revision 0
> 
> Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64
> 
> Current Operating System: Linux sbcb-default 
> 4.19.135-intel-pk-standard
> #1 SMP *PREE broken atomic modeset userspace detected, disabling 
> atomic*
> 
> MPT Mon Nov 2 15:55:20 UTC 2020 x86_64
> 
> Thanks,
> 
> Steve
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51701): https://lists.yoctoproject.org/g/yocto/message/51701
Mute This Topic: https://lists.yoctoproject.org/mt/78835705/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #zeus -broken atomic modsset

2020-12-09 Thread Khem Raj




On 12/9/20 10:12 AM, Monsees, Steven C (US) via lists.yoctoproject.org 
wrote:

I’m building/running zeus 3.0.4 on intel platform…

Can someone tell me why I might be seeing the following error and how to 
resolve it ?


https://patchwork.kernel.org/project/dri-devel/patch/20190905181834.6234-1-daniel.vet...@ffwll.ch/

might give some context



X.Org X Server 1.20.5

X Protocol Version 11, Revision 0

Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64

Current Operating System: Linux sbcb-default 4.19.135-intel-pk-standard 
#1 SMP *PREE broken atomic modeset userspace detected, disabling atomic*


MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,

Steve






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51700): https://lists.yoctoproject.org/g/yocto/message/51700
Mute This Topic: https://lists.yoctoproject.org/mt/78835705/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus -broken atomic modsset

2020-12-09 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I'm building/running zeus 3.0.4 on intel platform...

Can someone tell me why I might be seeing the following error and how to 
resolve it ?

X.Org X Server 1.20.5
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.10.0-1127.13.1.el7.x86_64 x86_64
Current Operating System: Linux sbcb-default 4.19.135-intel-pk-standard #1 SMP 
PREE broken atomic modeset userspace detected, disabling atomic
MPT Mon Nov 2 15:55:20 UTC 2020 x86_64

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51698): https://lists.yoctoproject.org/g/yocto/message/51698
Mute This Topic: https://lists.yoctoproject.org/mt/78835705/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto zeus X11 keyboard

2020-12-02 Thread Monsees, Steven C (US) via lists.yoctoproject.org

Does anyone know how to work through this issue, so as to resolve the conflict 
generated ?

Can I modify recipe or replace with a functionally equivalent package ?

Running on Intel 64 based platform...

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51621): https://lists.yoctoproject.org/g/yocto/message/51621
Mute This Topic: https://lists.yoctoproject.org/mt/78184269/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto zeus X11 keyboard

2020-11-17 Thread Monsees, Steven C (US) via lists.yoctoproject.org

Is there a way around this ?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51409): https://lists.yoctoproject.org/g/yocto/message/51409
Mute This Topic: https://lists.yoctoproject.org/mt/78184269/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto "zeus"

2020-11-12 Thread Khem Raj

are you using nfsvers= in /etc/fstab

On Thu, Nov 12, 2020 at 10:44 AM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
> All things being equal, would you know why I might see
>
> "NFS: bad mount option value specified: minorversion=1"
>
> when running app under "zeus" but not under "rocko" ?
>
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Thursday, November 12, 2020 1:40 PM
> To: Monsees, Steven C (US) ; 
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto "zeus"
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
>
> On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org
> wrote:
> > This is probably a simple question, but since I am new to yocto there
> > is a lot to learn...
> >
> > How do I establish kernel access permissions for the "zeus" kernel so
> > that when my application is up and running, (or an application startup
> > script), can create read/write files for access/updating in the "/etc"
> > and "/dev" directories ?
> >
> > In the few cases I do this I am seeing unable to open errors...
> >
> > Note the same code appears to work correctly under "rocko"...
>
> you have to provide more context to help you more, but usually /dev is 
> populated with devtmpfs during kernel boot. and similarly /etc is mounted 
> early on. So access permissions could be mounting issues perhaps.
>
> >
> > Thanks,
> >
> > Steve
> >
> >
> >
> >
> >
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51370): https://lists.yoctoproject.org/g/yocto/message/51370
Mute This Topic: https://lists.yoctoproject.org/mt/78204763/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto "zeus"

2020-11-12 Thread Monsees, Steven C (US) via lists.yoctoproject.org


All things being equal, would you know why I might see

"NFS: bad mount option value specified: minorversion=1"

when running app under "zeus" but not under "rocko" ?

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Thursday, November 12, 2020 1:40 PM
To: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto "zeus"

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
> This is probably a simple question, but since I am new to yocto there 
> is a lot to learn...
> 
> How do I establish kernel access permissions for the "zeus" kernel so 
> that when my application is up and running, (or an application startup 
> script), can create read/write files for access/updating in the "/etc"
> and "/dev" directories ?
> 
> In the few cases I do this I am seeing unable to open errors...
> 
> Note the same code appears to work correctly under "rocko"...

you have to provide more context to help you more, but usually /dev is 
populated with devtmpfs during kernel boot. and similarly /etc is mounted early 
on. So access permissions could be mounting issues perhaps.

> 
> Thanks,
> 
> Steve
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51369): https://lists.yoctoproject.org/g/yocto/message/51369
Mute This Topic: https://lists.yoctoproject.org/mt/78204763/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto "zeus"

2020-11-12 Thread Khem Raj




On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org 
wrote:
This is probably a simple question, but since I am new to yocto there is 
a lot to learn…


How do I establish kernel access permissions for the “zeus” kernel so 
that when my application is up and running, (or an application startup 
script), can create read/write files for access/updating in the ”/etc” 
and “/dev” directories ?


In the few cases I do this I am seeing unable to open errors…

Note the same code appears to work correctly under “rocko”…


you have to provide more context to help you more, but usually /dev is 
populated with devtmpfs during kernel boot. and similarly /etc is 
mounted early on. So access permissions could be mounting issues perhaps.




Thanks,

Steve






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51368): https://lists.yoctoproject.org/g/yocto/message/51368
Mute This Topic: https://lists.yoctoproject.org/mt/78204763/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto "zeus"

2020-11-12 Thread Monsees, Steven C (US) via lists.yoctoproject.org


This is probably a simple question, but since I am new to yocto there is a lot 
to learn...

How do I establish kernel access permissions for the "zeus" kernel so that when 
my application is up and running, (or an application startup script), can 
create read/write files for access/updating in the "/etc" and "/dev" 
directories ?

In the few cases I do this I am seeing unable to open errors...
Note the same code appears to work correctly under "rocko"...

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51365): https://lists.yoctoproject.org/g/yocto/message/51365
Mute This Topic: https://lists.yoctoproject.org/mt/78204763/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto zeus X11 keyboard

2020-11-11 Thread Monsees, Steven C (US) via lists.yoctoproject.org


I am running zeus based image (that runs without the following error under  my 
rocko build), under zeus build I am now seeing the following :

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:  Unsupported high keycode 372 for name  ignored
>   X11 cannot support keycodes above 255.
>   This warning only shows for the first high keycode.
Errors from xkbcomp are not fatal to the X server

Under: .../share/X11/xkb/keycodes/evfev I372 is defined as:
// Extended keys that may be generated on "Internet" keyboards.
// evdev has standardize names for these.

 = 372;   // #define KEY_FAVORITES   364

Is there a build option for this component I can tweak to correct for this ?

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51362): https://lists.yoctoproject.org/g/yocto/message/51362
Mute This Topic: https://lists.yoctoproject.org/mt/78184269/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Zeus stable branch

2020-09-08 Thread akuster

Hello,

The Zeus branch was defined as a transitional branch with a 9 month
stable cycle since LTS was created. The 3.0.4 was the last Zeus dot
release. We have since added several Build stabilization changes and
last minute backports . We intend on doing on last formal build cycle
but no QA so no formal dot release. After this action is complete,  
this branch will most like transition to Community Support and we will
see where it goes from there.

regards,
Armin
( On behalf of the Yocto Project® TSC)

Yocto Project® are registered trademark of the Linux Foundation.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50523): https://lists.yoctoproject.org/g/yocto/message/50523
Mute This Topic: https://lists.yoctoproject.org/mt/76726719/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus -docker/PREEMPT_RT

[yocto] Yocto Zeus -docker/PREEMPT_RT

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

Re: [yocto] #yocto #zeus Problem with moving from rocko to zeus

[yocto] #yocto #zeus Problem with moving from rocko to zeus

[yocto] #yocto #zeus Best practices for packaging third party recipe tool output in another recipe on the building host

[yocto] YOCTO Zeus: Qt remote objects compiler repc missing from sdk toolchain #toolchain #sdk #qtremoteobjects #repc

[yocto] #yocto #zeus

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

Re: [yocto] Yocto Zeus : facing error regarding hostapd #zeus

[yocto] Yocto Zeus : facing error regarding hostapd #zeus

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

Re: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

[yocto] #yocto #zeus #sdk populate_sdk_ext build failing

[yocto] Yocto zeus, npm fetcher, bug

[yocto] #yocto #zeus #kernel -broken atomic modsset

Re: [yocto] #yocto #zeus -broken atomic modsset

Re: [yocto] #yocto #zeus -broken atomic modsset

Re: [yocto] #yocto #zeus -broken atomic modsset

Re: [yocto] #yocto #zeus -broken atomic modsset

[yocto] #yocto #zeus -broken atomic modsset

Re: [yocto] #yocto zeus X11 keyboard

Re: [yocto] #yocto zeus X11 keyboard

Re: [yocto] #yocto "zeus"

Re: [yocto] #yocto "zeus"

Re: [yocto] #yocto "zeus"

[yocto] #yocto "zeus"

[yocto] #yocto zeus X11 keyboard

[yocto] Yocto Zeus stable branch

35 matches

Site Navigation

Mail list logo

Footer information