Date   

Migrating yocto project from sumo to warrior - getting null registry error from npm

Christopher McClellan
 

I'm migrating a yocto project that is working on sumo to warrior, so I set my layers to be the "warrior" branches. Everything runs fine until it fails in my node project layer on "do_compile" with the error message "Cannot read property 'replace' of null." It seems to return null for npm.config.get('registry'), but it is set on the Docker image that's building this image. If I delete the npm-shrinkwrap.json, it builds, but I'd like to leave that file in for the project. I think I need to either upgrade the npm version to 6.10.3 (where this error was fixed) or set the npm registry for the build process. How would I do that?


Re: python3 path different from python2

Tim Orling
 

Does your recipe inherit pythonnative? If so, you could try switching to ‘python3native’.


On Tue, May 12, 2020 at 12:13 PM Emily <easmith5555@...> wrote:
Hi all - 

I'm working with rocko trying to build a recipe with python3 that used to be build with python2 using cmake. After changing things in the build files, when I run the devshell for the recipe, I see two different include paths for python2 and python3. I have tried switching to zeus but I had a few issues with a xilinx bsp for the machine I wanted to build with. 

For python2 (correct):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python-config --cflags
-I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/python/2.7.14-r1=/usr/src/debug/python/2.7.14-r1 -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native= -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes

For python3 (incorrect):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python3-config --cflags
-I/usr/include/python3.5m -I/usr/include/python3.5m  -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

The python3 one is obviously incorrect, is there a way to tell where this path is coming from? Even if I manually include the proper path in the CMakeLists.txt it doesn't seem to work. Does yocto overwrite this path somewhere? 

Thanks!
Emily Smith



Re: [matchbox-desktop-2][PATCH] Add SPDX-License-Identifier: GPL-2.0-or-later

Richard Purdie
 

On Mon, 2020-03-23 at 11:53 -0400, Matthew wrote:
Fixes [YOCTO #13319]

Signed-off-by: Mingde (Matthew) Zeng <matthew.zeng@windriver.com>
---
libtaku/inotify/inotify-diag.c | 2 ++
libtaku/inotify/inotify-diag.h | 2 ++
libtaku/inotify/inotify-kernel.c | 2 ++
libtaku/inotify/inotify-kernel.h | 2 ++
libtaku/inotify/inotify-missing.c | 2 ++
libtaku/inotify/inotify-missing.h | 2 ++
libtaku/inotify/inotify-path.c | 2 ++
libtaku/inotify/inotify-path.h | 2 ++
libtaku/inotify/inotify-sub.c | 2 ++
libtaku/inotify/inotify-sub.h | 2 ++
Thanks for this. I did merge it however to be clear, the above files
are under LGPL, not GPL. As such, I removed this part of the commit and
added a second one of my own which resolves this.

Cheers,

Richard


python3 path different from python2

Emily
 

Hi all - 

I'm working with rocko trying to build a recipe with python3 that used to be build with python2 using cmake. After changing things in the build files, when I run the devshell for the recipe, I see two different include paths for python2 and python3. I have tried switching to zeus but I had a few issues with a xilinx bsp for the machine I wanted to build with. 

For python2 (correct):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python-config --cflags
-I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/python/2.7.14-r1=/usr/src/debug/python/2.7.14-r1 -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native= -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes

For python3 (incorrect):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python3-config --cflags
-I/usr/include/python3.5m -I/usr/include/python3.5m  -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

The python3 one is obviously incorrect, is there a way to tell where this path is coming from? Even if I manually include the proper path in the CMakeLists.txt it doesn't seem to work. Does yocto overwrite this path somewhere? 

Thanks!
Emily Smith


M+ & H bugs with Milestone Movements WW19

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW19 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.99

3.2 M1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW18!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

mark.morton@...

3

richard.purdie@...

1

bluelightning@...

1

changqing.li@...

1

limon.anibal@...

1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW19 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 120 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

30

david.reyna@...

19

bluelightning@...

16

akuster808@...

14

bruce.ashfield@...

11

kai.kang@...

9

Qi.Chen@...

9

randy.macleod@...

8

trevor.gamblin@...

8

ross@...

7

JPEWhacker@...

7

mark.morton@...

7

timothy.t.orling@...

6

changqing.li@...

6

michael@...

5

pbarker@...

4

raj.khem@...

4

alex.kanavin@...

4

mingli.yu@...

4

rpjday@...

4

hongxu.jia@...

3

yi.zhao@...

3

chee.yang.lee@...

3

akuster@...

3

kexin.hao@...

3

jon.mason@...

3

alejandro@...

2

ycnakajsph@...

2

mark.hatle@...

2

jpuhlman@...

2

mostthingsweb@...

2

seebs@...

2

kergoth@...

2

jaewon@...

2

naveen.kumar.saini@...

1

amber.n.elliot@...

1

maxime.roussinbelanger@...

1

nicolas.dechesne@...

1

ricardo.ribalda@...

1

sakib.sajal@...

1

kai.ruhnau@...

1

zhe.he@...

1

matthew.zeng@...

1

bunk@...

1

dl9pf@...

1

mshah@...

1

denis@...

1

yang.wang@...

1

liu.ming50@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Status WW19'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M1

Next Deadline: YP 3.2 M1 build date 2020/6/16

 

Next Team Meetings:

 

Key Status/Updates:

  • Patches continue to merge into master, there have been a number of infrastructure issues and build failures which have delayed some patches until we could get clean builds
  • We’re nearly ready to merge gcc 10 to master with some mingw issues being the currently known remaining blocker.
  • A number of other slightly more invasive changes are merging such as the changing of QA warnings to become errors and changes to the way libva is built. Some further, more invasive changes are in the queue (e.g. image sstate structure) so review of the patch queue by people with interests in these things is appreciated.
  • We believe autoconf may release a new version soon (the first in a few years) so have worked with autoconf upstream to ensure it should work for us, reporting test results back.
  • YP 3.0.3 will build this week.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M1 build date 2020/6/16
  • YP 3.2 M1 Release date 2020/6/26
  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.3 build date 2020/5/4
  • YP 3.0.3 release date 2020/5/15
  • YP 2.7.4 build date 2020/5/18
  • YP 2.7.4 release date 2020/5/29
  • YP 3.1.1 build date 2020/6/29
  • YP 3.1.1 release date 2020/7/10
  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Is http://downloads.yoctoproject.org/ down?

Denys Dmytriyenko
 

On Tue, May 12, 2020 at 02:03:07PM +0100, Paul Barker wrote:
On Tue, 12 May 2020 at 13:36, Zwicker Severin
<severin.zwicker@rittmeyer.com> wrote:

I can’t reach http://downloads.yoctoproject.org/ to download http://downloads.yoctoproject.org/releases/uninative/2.7/x86_64-nativesdk-libc.tar.xz .



Did somebody know anything?
Yes, it currently appears to be down. The relevant folks will be
looking at it but it's still early in the US timezones.
Could it be Europe-specific problem?
Seems slow, but still working here in the US:

$ wget http://downloads.yoctoproject.org/releases/uninative/2.7/x86_64-nativesdk-libc.tar.xz
--2020-05-12 09:08:15-- http://downloads.yoctoproject.org/releases/uninative/2.7/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org... 198.145.29.63
Connecting to downloads.yoctoproject.org|198.145.29.63|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5450224 (5.2M) [application/octet-stream]
Saving to: ‘x86_64-nativesdk-libc.tar.xz’

x86_64-nativesdk-libc.tar.xz 100%[==========================================================================>] 5.20M 540KB/s in 59s

2020-05-12 09:09:27 (89.5 KB/s) - ‘x86_64-nativesdk-libc.tar.xz’ saved [5450224/5450224]


Re: Is http://downloads.yoctoproject.org/ down?

 

On Tue, 12 May 2020 at 13:36, Zwicker Severin
<severin.zwicker@rittmeyer.com> wrote:

I can’t reach http://downloads.yoctoproject.org/ to download http://downloads.yoctoproject.org/releases/uninative/2.7/x86_64-nativesdk-libc.tar.xz .



Did somebody know anything?
Yes, it currently appears to be down. The relevant folks will be
looking at it but it's still early in the US timezones.


Is http://downloads.yoctoproject.org/ down?

Zwicker Severin
 


Re: [oe][yocto][bitbake] Fetching source using different protocols

Dawod
 

Thank you all, your answers were so helpful,
My problem had been solved.
The reason behind my question was a temporary connections error for some machines in the lab so I needed some way to cover this problem  as fast as possible to keep my Yocto recipes away from this problem. 

Thank you very much.


On Mon, May 11, 2020 at 8:37 PM Mark Hatle <mark.hatle@...> wrote:


On 5/11/20 4:17 AM, Quentin Schulz wrote:
> Hi Mohamed,
>
> On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote:
>> Hello,
>>
>> I need to fetch a git repo using 2 different protocols ( ssh & https )
>> So that when I run bitbake, It will fetch using ssh protocol first and if
>> it fails to fetch, It will try to fetch using https protocol.
>>
>
> Why? What's the exact use case?
>
>> can I do some thing like that or I will have to change it manually every
>> time ?
>>
>
> Maybe you could play with PREMIRROS? (I've never explicitly used that
> variable though):
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREMIRRORS

This is what I would suggest.  Have the recipe itself set the fallback URI as
the main URL.


SRC_URI = "git://example.com/my/repository/uri;proto=https"

PREMIRRORS_prepend = "git://example.com/my/repository/uri;proto=https
git://example.com/my/otherrepo/uri;proto=ssh \n"

(the \n is literally '\' and 'n')

The above should, when it sees the SRC_URI, try the ssh protocol first.. if that
doesn't work it will fall back to SRC_URI.

--Mark

> I guess the asterisk parts could be removed and the path to more or less your
> source could be used (ssh first, to http path in your SRC_URI)?
>
> That's a shot in the dark for me but something to test I'd say :)
>
> Quentin
>
>
>
>


--
 
Mohamed Dawod
Computer Engineer


Re: meta-anaconda Python AttributeError: "str" object has no attribute 'decode'

Khem Raj
 

On 5/10/20 2:58 AM, Yocto wrote:
using meta-anaconda for an iso installer during the grub process python
exists with

Python AttributeError: "str" object has no attribute 'decode'
this seems to be perhaps python version mismatch between 2 and 3


Screen shots attached. seem to have an issue with unicode ....





Re: [oe][yocto][bitbake] Fetching source using different protocols

Mark Hatle
 

On 5/11/20 4:17 AM, Quentin Schulz wrote:
Hi Mohamed,

On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote:
Hello,

I need to fetch a git repo using 2 different protocols ( ssh & https )
So that when I run bitbake, It will fetch using ssh protocol first and if
it fails to fetch, It will try to fetch using https protocol.
Why? What's the exact use case?

can I do some thing like that or I will have to change it manually every
time ?
Maybe you could play with PREMIRROS? (I've never explicitly used that
variable though):
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREMIRRORS
This is what I would suggest. Have the recipe itself set the fallback URI as
the main URL.


SRC_URI = "git://example.com/my/repository/uri;proto=https"

PREMIRRORS_prepend = "git://example.com/my/repository/uri;proto=https
git://example.com/my/otherrepo/uri;proto=ssh \n"

(the \n is literally '\' and 'n')

The above should, when it sees the SRC_URI, try the ssh protocol first.. if that
doesn't work it will fall back to SRC_URI.

--Mark

I guess the asterisk parts could be removed and the path to more or less your
source could be used (ssh first, to http path in your SRC_URI)?

That's a shot in the dark for me but something to test I'd say :)

Quentin




Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 334 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [OE-core] [oe][yocto][bitbake] Fetching source using different protocols

Andre McCurdy <armccurdy@...>
 

On Mon, May 11, 2020 at 2:03 AM Dawod <mhm.dawod@gmail.com> wrote:

Hello,

I need to fetch a git repo using 2 different protocols ( ssh & https )
So that when I run bitbake, It will fetch using ssh protocol first and if it fails to fetch, It will try to fetch using https protocol.

can I do some thing like that or I will have to change it manually every time ?
You can add fallback rules to MIRRORS (either globally or per-recipe).
See the last few lines of meta/classes/mirrors.bbclass as an example.

Thank you,
--

Mohamed Dawod
Computer Engineer


Re: [oe][yocto][bitbake] Fetching source using different protocols

Quentin Schulz
 

Hi Mohamed,

On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote:
Hello,

I need to fetch a git repo using 2 different protocols ( ssh & https )
So that when I run bitbake, It will fetch using ssh protocol first and if
it fails to fetch, It will try to fetch using https protocol.
Why? What's the exact use case?

can I do some thing like that or I will have to change it manually every
time ?
Maybe you could play with PREMIRROS? (I've never explicitly used that
variable though):
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREMIRRORS

I guess the asterisk parts could be removed and the path to more or less your
source could be used (ssh first, to http path in your SRC_URI)?

That's a shot in the dark for me but something to test I'd say :)

Quentin


[oe][yocto][bitbake] Fetching source using different protocols

Dawod
 

Hello,

I need to fetch a git repo using 2 different protocols ( ssh & https )
So that when I run bitbake, It will fetch using ssh protocol first and if it fails to fetch, It will try to fetch using https protocol.

can I do some thing like that or I will have to change it manually every time ?

Thank you,
--
 
Mohamed Dawod
Computer Engineer


3.2 (Gatesgarth ) assistance

Armin Kuster
 

Hello,

The Yocto Project and OE bug triage are seeking some assistance on tasks we hope to addressed into 3.2.

The first milestone for 3.2 is targeted for 2020/6/16.   If anyone is interested in helping or seeking a new  challenge, please  take a look in the list below to see if anything interests you. Help can be in any form from research to a patch to address the issue.

Best regards,
Armin
(On behalf of the Yocto Project triage team)



https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs


5389 bitbake/lib/bb/fetch2: filename too long normal Medium+ 3.2 M1 Unassigned IN PROGRESS IMPLEMENTATION
4
7600 syslinux: port extX support patches to syslinux community enhancement Medium+ 3.2 M1 Unassigned IN PROGRESS IMPLEMENTATION
5
10731 bitbake --observe-only doesn't work with memres normal Medium+ 3.2 M1 Unassigned IN PROGRESS REVIEW
5
11351 go-native: do_compile failed when len(tmp) = 410 normal Medium+ 3.2 M1 Unassigned NEW
2
11781 bitbake --observe-only may get KeyError normal Medium+ 3.2 M1 Unassigned IN PROGRESS REVIEW
3
12347 llvm-native: do_configure failed when len(TMPDIR) == 410 normal Medium+ 3.2 M1 Unassigned NEW
2
12362 webkitgtk: do_compile failed when len(TMPDIR) == 410 normal Medium+ 3.2 M1 Unassigned NEW
3
12367 moving or removing tmp breaks persistent bitbake server normal Medium+ 3.2 M1 Unassigned NEW

12374 do_rootfs failed when len(TMPDIR) == 410 normal Medium+ 3.2 M1 Unassigned NEW
2
13004 Automate yocto-check-layer -m option enhancement Medium+ 3.2 M1 Unassigned NEW

13023 Switch to memory resident bitbake by default in 3.2 enhancement Medium+ 3.2 M1 Unassigned NEW

13039 fetch2: PREMIRROR and SRC_URI with type https and parameter downloadfilename yields invalid url normal Medium+ 3.2 M1 Unassigned NEW

13055 oe-selftest runcmd.RunCmdTests.test_stdin failure normal Medium+ 3.2 M1 Unassigned NEW

13176 yocto-check-layer can only check layers which aren't already in BBLAYERS normal Medium+ 3.2 M1 Unassigned NEW Backport 3.1 & 3.0 & 2.7
13181 persist_data sqlite database mixed with forking is irreparably broken normal Medium+ 3.2 M1 Unassigned NEW

13233 fetch2: try_premirror(): improve on updating repo from mirror enhancement Medium+ 3.2 M1 Unassigned NEW
3
13236 sstate for host native packages normal Medium+ 3.2 M1 Unassigned NEW

13279 Make sure users/groups exist for package_write_* tasks normal Medium+ 3.2 M1 Unassigned NEW

13306 bitbake starts up to n^2 processes with n cpus normal Medium+ 3.2 M1 Unassigned NEW

13353 bitbake git fetcher does not honour BB_FETCH_PREMIRRORONLY normal Medium+ 3.2 M1 Unassigned NEW

13419 recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens) normal Medium+ 3.2 M1 Unassigned NEW

13421 File race when calling devtool.setUpModule normal Medium+ 3.2 M1 Unassigned NEW

13463 test linux-yocto-rt kernels too normal Medium+ 3.2 M1 Unassigned NEW

13705 master] bitbake and hashserve.sock left behind when ^C a build normal Medium+ 3.2 M1 Unassigned NEW

13803 devtool setupClass file copying race normal Medium+ 3.2 M1 Unassigned NEW backport 3.1
13811 Memory Resident bitbake has output redirection problem normal Medium+ 3.2 M1 Unassigned NEW

13843 bitbake worker stuck using 100% cpu on aborted build normal Medium+ 3.2 M1 Unassigned NEW

13859 adwaita-icon-theme cannot find GTK+3 gtk-update-icon-cache command minor Medium+ 3.2 M1 Unassigned NEW

13868 Python cache files get lost in packages normal Medium+ 3.2 M1 Unassigned NEW

13822 Easy to have misleading warnings if env script is executed instead of sourced normal Medium+ 3.2 M2 Unassigned


meta-anaconda Python AttributeError: "str" object has no attribute 'decode'

Yocto
 

using meta-anaconda for an iso installer during the grub process python exists with

Python AttributeError: "str" object has no attribute 'decode'

Screen shots attached. seem to have an issue with unicode ....

4881 - 4900 of 54253