Enhancements/Bugs closed WW49!
Stephen Jolley
All,
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.5
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi 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 395 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.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.
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: Setting BUILDNAME to a string broke in 3.1.12
Daniel Gomez
Hi,
On Mon, 6 Dec 2021 at 17:40, Henrik Riomar <henrik.riomar@...> wrote: We use build image-buildinfo class: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-image-buildinfo Just add INHERIT += "image-buildinfo" to your local.conf to get the build info. Daniel
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Setting BUILDNAME to a string broke in 3.1.12
Henrik Riomar
Hi,
We set the BUILDNAME (via local.conf) variable to the output of "git describe --long --always" so this info ends up in /etc/version instead of a date. (i.e to know the exact source version of the code deployed on a target) This has worked fine for us up until 3.1.12, but now we just get a date (201803...) in /etc/version. Note that since switching to Dunfell we were forced to set BUILD_REPRODUCIBLE_BINARIES to 0, so the build system would not "mess up" /etc/version, but not even that helps now. What's the official way to get something more useful than a date (in the long past) in /etc/version? Thanks, Henrik |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.1.rc1)
Teoh, Jay Shen
Hello everyone,
toggle quoted message
Show quoted text
This is the full report for yocto-3.4.1.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high milestone defects. new issue found Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure ======= Bugs ======== https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622 Thanks, Jay -----Original Message----- |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
meta-intel with a Celeron 6305E
Ori Pessach
Hello, I'm trying to run an existing image (based on Gatesgarth) on a Celeron 6305E NUC. The application running on this image is a media player which uses Gstreamer for decoding and displaying video. Performance on this CPU is inadequate (probably due to lack of acceleration support for decoding and display), and I've been trying to figure out how to fix that. I tried pulling different tags of the meta-intel BSP layer, with no success. So I guess my question is this - Is this processor fully supported by meta-intel, and if so, when was support added for this generation of CPU/GPU and how can I get that to work with my image? Thanks, Ori Pessach |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues
merged.
toggle quoted message
Show quoted text
thanks armin On 12/2/21 6:02 PM, Kai wrote:
On 11/27/21 2:41 AM, akuster808 wrote:merged.Hi Armin, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
USB display
simon
Hello, I'm having some issue moving from an HDMI display to a USB display.
I figure out that I needed to enable these parameter in the kernel to use the USB monitor CONFIG_DRM_UDL=y CONFIG_FB_UDL=y With those I'm able to see the terminal and login However I'm still struggling and confused on how to get my GUI to show up with startx. I don't know if I still need to install the displaylink driver since I've enabled UDL or if I need to set something with xorg to let him know to use the USB display. I've tried to install the displaylink driver manually but I'm missing the DKMS component, not entirely sure what that is and how I would install this (or if I should). I tried to follow some guide about displaylink with xorg and replacing it with udl and udlfb without success. Thanks for your help Simon |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: native tool from target recipe
Ross Burton <ross@...>
On Fri, 3 Dec 2021 at 16:16, <kkubkowski@...> wrote:
Hi all,The usual solution is for the recipe to allow building native and you install the tools from that recipe for the target recipe to use. The better solution is that the source knows how to build host tools for the host and target binaries for the target. barebox does, so just set HOSTCC=${BUILD_CC} when you call make. Ross |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
native tool from target recipe
Kacper Kubkowski
Hi all,
I have what I believe is a basic question yet I cannot find any definitive answer: is it possible for a target recipe (e.g. u-boot or barebox) to provide a native tool (i.e. mkimage) for the build system without the need to rebuild the providing recipe as a native one? To be more specific: I am using barebox as a bootloader and it always builds mkimage for host. I would like to use it later during the build process in another recipe (e.g. after the kernel is built) but I don't want to rebuild the bootloader as a native package. Given how flexible the build system is I suppose it is doable, but what is "the proper" way? Kind regards, Kacper |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch
Quentin Schulz
On Fri, Dec 03, 2021 at 11:48:29AM +0100, Nicolas Dechesne wrote:
On Fri, Dec 3, 2021 at 11:03 AM Quentin Schulz <Agreed, I poorly reviewed it. Thanks for stoping us before the disaster :) perhaps we should maintain the overall documentation (for all versions) inI think all our issues always come down to this weird and inefficient organization we have for docs and common files between doc releases. We'll need to settle on something one day because I don't think what we're doing today is working :/ Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch
Quentin Schulz
Hi Nicolas,
On Fri, Dec 03, 2021 at 10:49:40AM +0100, Nicolas Dechesne wrote: On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <Indeed. But this should be fixed, because we should handle this the same way documentation/releases.html is, with a common one across all releases. With the current implementation, only master has a list of all outdated releases. e.g. https://docs.yoctoproject.org/3.3/releases.html#outdated-release-manuals does not exist, but https://docs.yoctoproject.org/releases.html#outdated-release-manuals does (and weirdly enough 3.4 too). I assume we want this in all branches. Therefore I think we should move documentation/transition from that branch to master and copy the whole directory for each non-master branch (with the git checkout master trick from an earlier patch from Michael). I think this makes more sense than keeping a transition branch? Especially since I assume we want to move every 6 months one release from "Supported release manuals" to "Outdated releae manuals" ? Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch
Quentin Schulz
On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote:
No longer necessary now that the transition from DocBook to Sphinx is overReviewed-by: Quentin Schulz <foss+yocto@...> Thanks, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: make all versions list releases known to master
Quentin Schulz
Hi Michael,
On Wed, Dec 01, 2021 at 02:49:31PM +0100, Michael Opdenacker wrote: This allows all versions of Bitbake and Yocto Project manualsWhy don't we migrate this different method (find) to the one you implement in this commit too? I could see a variable storing all "force-latest" files or someting like that to make it obvious why they have a specific handling. Signed-off-by: Michael Opdenacker <michael.opdenacker@...>That's one way to do it, not sure this is really what we want but at least it lowers the maintenance burden so it's a good improvement. Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Zynq Board unreachable
m.kleber@...
Hi,
I created a build for a digilent zybo zynq7. And I create a small server code I need to run on the board. When I connect the board with ethernet cable to my laptop and try to ping the board I will get the following answer: $ ping fe80::3478:6c8d:ad4e:43f8%eth0 PING fe80::3478:6c8d:ad4e:43f8%eth0(fe80::3478:6c8d:ad4e:43f8%eth0) 56 data bytes From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=1 Destination unreachable: Address unreachable From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=2 Destination unreachable: Address unreachable From fe80::6504:a10e:942f:7cfd%eth0: icmp_seq=3 Destination unreachable: Address unreachable I've configured the eth0 in /etc/network/interfaces. The laptop get the connection to the board but can' t reach it or the gateway. There is no firewall or iptables rules. Anyone an idea how to deal with it? B/R Mike |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: remove gatesgarth
Quentin Schulz
Hi Michael, Richard,
On Wed, Nov 24, 2021 at 06:10:56PM +0000, Richard Purdie wrote: On Wed, 2021-11-24 at 18:16 +0100, Michael Opdenacker wrote:I think we want to make sure we have all docs up-to-date, even for theTogether with the corresponding Bitbake version, which are noI'm a bit torn on this. They are no longer officially supported releases now but branches that aren't maintained anymore. Especially since it's not taking a lot of CPU time to build them, it's fine IMO. We could always make minor changes to old docs. E.g. the releases.rst might get updates until we figure something out. Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch
Nicolas Dechesne <nicolas.dechesne@...>
On Fri, Dec 3, 2021 at 11:03 AM Quentin Schulz <quentin.schulz@...> wrote: Hi Nicolas, Yes, this part is indeed poorly implemented. But I don't think we can remove the transition branch until we fix it, so I don't think we can take this patch now. perhaps we should maintain the overall documentation (for all versions) in the same branch.. all these branches are making everything much complicated.. Or perhaps we should split the documentation 'content' and the documentation config and scripts. I am wondering how other projects are doing it to support such complex doc setup (multiple versions to support and to publish)!
I think we had the 'transition' pages in master initially, and we moved that to its own branch. I believe it's something we discussed with Richard.. but i forgot the details.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch
Nicolas Dechesne <nicolas.dechesne@...>
On Fri, Dec 3, 2021 at 10:34 AM Quentin Schulz <quentin.schulz@...> wrote: On Wed, Dec 01, 2021 at 02:59:49PM +0100, Michael Opdenacker wrote: I don't understand. With this change, we no longer build the pages we reference here: Or am I missing here?
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Re: [meta-security][hardknott][PATCH v2] sssd: re-package to fix QA issues
Kai Kang
On 11/27/21 2:41 AM, akuster808 wrote:
merged.Hi Armin, Would you like to double check the commit, please? I don't see it in branch hardknott. Regards, Kai
-- Kai Kang Wind River Linux |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|