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-prototypesFor 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-prototypesThe 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
Fixes [YOCTO #13319]Thanks for this. I did merge it however to be clear, the above files
Signed-off-by: Mingde (Matthew) Zeng <matthew.zeng@...>
---
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 ++
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
-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
-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
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+ | 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@...
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@...
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@...
Current Dev Position: YP 3.2 M1
Next Deadline: YP 3.2 M1 build date 2020/6/16
Next Team Meetings:
- Bug Triage meeting Thursday May 14th at 7:30am PDT (https://zoom.us/j/454367603)
- Monthly Project Meeting Tuesday june 2nd at 8am PDT (https://zoom.us/j/990892712)
- Weekly Engineering Sync Tuesday May 12th at 8am PDT (https://zoom.us/j/990892712)
- Twitch - See http://www.twitch.tv/letoatreidesthe2nd
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:
- WDD 2577 (last week 2577) (https://wiki.yoctoproject.org/charts/combo.html)
- Poky Patch Metrics
- Total patches found: 1345 (last week 1353)
- Patches in the Pending State: 536 (40%) [last week 536 (40%)]
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@...
On Tue, 12 May 2020 at 13:36, Zwicker SeverinCould it be Europe-specific problem?
<severin.zwicker@...> wrote:Yes, it currently appears to be down. The relevant folks will be
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?
looking at it but it's still early in the US timezones.
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]
<severin.zwicker@...> wrote:
Yes, it currently appears to be down. The relevant folks will be
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?
looking at it but it's still early in the US timezones.
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?
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
using meta-anaconda for an iso installer during the grub process pythonthis seems to be perhaps python version mismatch between 2 and 3
exists with
Python AttributeError: "str" object has no attribute 'decode'
Screen shots attached. seem to have an issue with unicode ....
Hi Mohamed,This is what I would suggest. Have the recipe itself set the fallback URI as
On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote:Hello,Why? What's the exact use case?
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 everyMaybe you could play with PREMIRROS? (I've never explicitly used that
time ?
variable though):
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PREMIRRORS
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
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@...
You can add fallback rules to MIRRORS (either globally or per-recipe).
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 ?
See the last few lines of meta/classes/mirrors.bbclass as an example.
Thank you,
--
Mohamed Dawod
Computer Engineer
On Mon, May 11, 2020 at 11:03:26AM +0200, Dawod wrote:
Hello,Why? What's the exact use case?
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 everyMaybe you could play with PREMIRROS? (I've never explicitly used that
time ?
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
Mohamed Dawod
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 |