Re: [yocto] python3 pygame under Pyro
On Wed, Oct 2, 2019 at 3:32 PM Mauro Ziliani wrote: > > Adding libsdl2 to DEPENDS i get sdl2-config under the folder > > tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/python3-pygame/1.9.6-r0/recipe-sysroot/usr/bin/crossscripts/sdl2-config > yes and you should be able to use it. > Il 03/10/19 00:01, Khem Raj ha scritto: > > On Wed, Oct 2, 2019 at 2:46 PM Mauro Ziliani wrote: > >> Hi all. > >> > >> I'm trying to build python3-pygame for and imx6dl board in Pyro. > >> > >> Pygame needs SDL, but I don't know how to tell to bitbake for compile > >> sdl before pygame. > >> > >> > >> I put libsdl-native into DEPENDS but doesn't work. > >> > >> > >> bitbake try to run sdl-config but it cannot find the file. > >> > >> > >> Any idea? > >> > > Does, DEPENDS += "libsdl2" help ? > >> Best regards, > >> > >> MZ > >> > >> > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] 3.0 release notes / migration guide
On Thursday, 3 October 2019 11:44:53 AM NZDT akuster808 wrote: > On 10/2/19 3:20 PM, Paul Eggleton wrote: > > So it's that time again - we need to start building up the raw material for > > the release notes and migration guide for the upcoming 3.0 release, and I'd > > like to request some help with some parts of it - read on for details. > > > > For the migration guide we have a wiki page serving as a staging area: > > > > https://wiki.yoctoproject.org/wiki/FutureMigrationGuide > > Thanks for putting this together. No problem! > > Things that should go in the migration guide: *anything* in the release > > that > > would require someone who is upgrading to take some form of action (i.e. > > change their configuration / recipes / etc.) Help with this from people who > > implemented the changes or have already thought about / dealt with their > > impact would be much appreciated. > > > > There is a process where I look through all the commits since the last > > release > > and pull out the ones that need to be mentioned in some form - other than > > the > > migration guide items, the following needs to be gathered for the release > > notes: > > > > 1) Features - new functionality. We need to capture what the feature is and > > hopefully express the impact to the user succinctly. > > We remove LSB support. Thanks - I've just added that to the migration guide and will note it in the release notes. > > 2) Recipe upgrades - straightforward > > > > 3) CVE fixes - fairly straightforward, I just look for commits that > > explicitly > > mention "CVE". If I can easily do so I'll also note where a recipe upgrade > > fixes a CVE, but that isn't often readily available information. > > So how can the community help in this case? Better commit messages? That would be great - but it does require the person doing the upgrade to look upstream, and of course every upstream is different. Unfortunately with some upstreams finding fixed CVE information is quite difficult indeed. > Well, aren't open defects not fixed by the time we release time but we > intend on fixing after release a form of known issues ? Yes, that's true - I will say we haven't been particularly systematic about the known issues in past releases so perhaps we should drive the list from bugzilla. I would want the list to be kept as short as possible though and each item should succinctly describe the issue. Cheers Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] 3.0 release notes / migration guide
Paul, On 10/2/19 3:20 PM, Paul Eggleton wrote: > Hi folks > > So it's that time again - we need to start building up the raw material for > the release notes and migration guide for the upcoming 3.0 release, and I'd > like to request some help with some parts of it - read on for details. > > For the migration guide we have a wiki page serving as a staging area: > > https://wiki.yoctoproject.org/wiki/FutureMigrationGuide Thanks for putting this together. > > Things that should go in the migration guide: *anything* in the release that > would require someone who is upgrading to take some form of action (i.e. > change their configuration / recipes / etc.) Help with this from people who > implemented the changes or have already thought about / dealt with their > impact would be much appreciated. > > There is a process where I look through all the commits since the last > release > and pull out the ones that need to be mentioned in some form - other than the > migration guide items, the following needs to be gathered for the release > notes: > > 1) Features - new functionality. We need to capture what the feature is and > hopefully express the impact to the user succinctly. We remove LSB support. > 2) Recipe upgrades - straightforward > > 3) CVE fixes - fairly straightforward, I just look for commits that > explicitly > mention "CVE". If I can easily do so I'll also note where a recipe upgrade > fixes a CVE, but that isn't often readily available information. So how can the community help in this case? Better commit messages? > > 4) Known issues - generally this is difficult to get from the commits since > we > either find out about them after the commit that introduced the issue, or we > don't know that they aren't addressed until right at the end of the release. > We don't want to note *all* open bugs, but if there's something that the user > is likely to hit that wasn't an issue in the previous release then we should > note it. Well, aren't open defects not fixed by the time we release time but we intend on fixing after release a form of known issues ? - armin > For the release notes I need help with #4 and #1 in particular, so if you > know > about anything in this release that falls into these categories then let me > know - just a pointer to the commit and any extra comments that you would > want > to make would be helpful. In the mean time I will start the process of > looking > through the commits and will add things to the migration guide page, but bear > in mind I don't always have all of the context for every change. > > Thanks! > Paul > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] python3 pygame under Pyro
Adding libsdl2 to DEPENDS i get sdl2-config under the folder tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/python3-pygame/1.9.6-r0/recipe-sysroot/usr/bin/crossscripts/sdl2-config Il 03/10/19 00:01, Khem Raj ha scritto: On Wed, Oct 2, 2019 at 2:46 PM Mauro Ziliani wrote: Hi all. I'm trying to build python3-pygame for and imx6dl board in Pyro. Pygame needs SDL, but I don't know how to tell to bitbake for compile sdl before pygame. I put libsdl-native into DEPENDS but doesn't work. bitbake try to run sdl-config but it cannot find the file. Any idea? Does, DEPENDS += "libsdl2" help ? Best regards, MZ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 3.0 release notes / migration guide
Hi folks So it's that time again - we need to start building up the raw material for the release notes and migration guide for the upcoming 3.0 release, and I'd like to request some help with some parts of it - read on for details. For the migration guide we have a wiki page serving as a staging area: https://wiki.yoctoproject.org/wiki/FutureMigrationGuide Things that should go in the migration guide: *anything* in the release that would require someone who is upgrading to take some form of action (i.e. change their configuration / recipes / etc.) Help with this from people who implemented the changes or have already thought about / dealt with their impact would be much appreciated. There is a process where I look through all the commits since the last release and pull out the ones that need to be mentioned in some form - other than the migration guide items, the following needs to be gathered for the release notes: 1) Features - new functionality. We need to capture what the feature is and hopefully express the impact to the user succinctly. 2) Recipe upgrades - straightforward 3) CVE fixes - fairly straightforward, I just look for commits that explicitly mention "CVE". If I can easily do so I'll also note where a recipe upgrade fixes a CVE, but that isn't often readily available information. 4) Known issues - generally this is difficult to get from the commits since we either find out about them after the commit that introduced the issue, or we don't know that they aren't addressed until right at the end of the release. We don't want to note *all* open bugs, but if there's something that the user is likely to hit that wasn't an issue in the previous release then we should note it. For the release notes I need help with #4 and #1 in particular, so if you know about anything in this release that falls into these categories then let me know - just a pointer to the commit and any extra comments that you would want to make would be helpful. In the mean time I will start the process of looking through the commits and will add things to the migration guide page, but bear in mind I don't always have all of the context for every change. Thanks! Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] python3 pygame under Pyro
On Wed, Oct 2, 2019 at 2:46 PM Mauro Ziliani wrote: > > Hi all. > > I'm trying to build python3-pygame for and imx6dl board in Pyro. > > Pygame needs SDL, but I don't know how to tell to bitbake for compile > sdl before pygame. > > > I put libsdl-native into DEPENDS but doesn't work. > > > bitbake try to run sdl-config but it cannot find the file. > > > Any idea? > Does, DEPENDS += "libsdl2" help ? > > Best regards, > >MZ > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] python3 pygame under Pyro
Hi all. I'm trying to build python3-pygame for and imx6dl board in Pyro. Pygame needs SDL, but I don't know how to tell to bitbake for compile sdl before pygame. I put libsdl-native into DEPENDS but doesn't work. bitbake try to run sdl-config but it cannot find the file. Any idea? Best regards, MZ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH][v5.2/standard/preempt-rt/base] printk: devkmsg: read: Return EPIPE when the first message user-space wants has gone
I didn't merge this directly, but instead updated the -rt branches to
-rt9 .. so I got your change that way.
Cheers,
Bruce
On Sun, Sep 29, 2019 at 5:36 AM wrote:
>
> From: He Zhe
>
> This fixes ltp failure,
> kmsg01.c:444: FAIL: read returned: 56: SUCCESS
>
> When user-space wants to read the first message, that is when user->seq
> is 0, and that message has gone, it currently automatically resets
> user->seq to current first seq. This mis-aligns with mainline kernel.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/dev-kmsg#n39
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n899
>
> We should inform user-space that what it wants has gone by returning EPIPE
> in such scenario.
>
> Link: https://lore.kernel.org/linux-rt-users/8736gls1aj@linutronix.de/T/#t
>
> Signed-off-by: He Zhe
> ---
> kernel/printk/printk.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e3fa33f..58c545a 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -703,14 +703,10 @@ static ssize_t devkmsg_read(struct file *file, char
> __user *buf,
> goto out;
> }
>
> - if (user->seq == 0) {
> - user->seq = seq;
> - } else {
> - user->seq++;
> - if (user->seq < seq) {
> - ret = -EPIPE;
> - goto restore_out;
> - }
> + user->seq++;
> + if (user->seq < seq) {
> + ret = -EPIPE;
> + goto restore_out;
> }
>
> msg = (struct printk_log *)>msgbuf[0];
> --
> 2.7.4
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] git fetcher - AUTOREV and best practices
On Wed, Oct 2, 2019 at 10:41 AM Joshua Watt wrote:
>
> On Wed, Jun 5, 2019 at 8:00 AM Maciej Pijanowski
> wrote:
> >
> > Hello,
> >
> > As explained in the mega manual [1], when using the git:// fetcher,
> > setting the
> > SRCREV to ${AUTOREV} will result in building the latest commit from
> > given git
> > branch (master, if not specified otherwise).
> >
> > Using AUTOREV feature in recipe has following implications as far as I
> > can see:
> >
> > - the same recipe might get built using different git commit, depending
> > on when
> > the build was run, which breaks the reproducibility,
> > - it imposes some potential security risk - by specifying the exact
> > commit in
> > the recipe, we can at least say that this revision of this package is fine
> > and we want to build it; with AUTOREV we might not be aware of the
> > code we're
> > fetching
> >
> > I'm wondering whether there are any best practices or strict rules
> > written down
> > for recipes getting upstream to follow in this area. When inspecting some of
> > the layers from the git.yoctoprojects.org, it appears that the AUTOREV
> > feature
> > is almost not used, besides a few exceptions.
> >
> > I'm wondering whether it would make sense to raise a warning when git
> > fetcher
> > with AUTOREV is used, so it would be easier to build on top OE / Yocto with
> > reproducibility / security in mind.
> >
> > I understand that this feature is mostly meant for development purposes. I'm
> > just looking for a tools how one could easily make sure that each
> > fetched source code
> > is verified prior compilation.
>
> Yes, I think warning about using AUTOREV makes a lot of sense for all
> the reasons you have raised. I'm not sure that putting that in the git
> fetcher is necessarily the best place for that. OE has an extensive
> set of QA checks that run when recipes are built, and I think that
> this might be a better/easier place to put this check. IMHO, recipes
> that force you to use AUTOREV in the base recipe are broken and should
> be fixed, in which case a QA check should be sufficient. The harder
> part is making sure that it doesn't trigger when someone is using
> AUTOREV legitimately for development purposes. OE already has a class
> that encapsulates the logic for reproducible builds
> (reproducible_build.bbclass); one approach might be to add the QA
> check, and then add it to the list of QA checks that fail the build
> (ERROR_QA from insane.bbclass) in reproducible_build.bbclass.
>
> As a bonus, the 3.0 zeus release adds a QA check for reproducible
> builds, so such a QA check would get detected on the autobuilder if
> someone changed a oe-core recipe to use AUTOREV by default. I suspect
> that doesn't help your immeidate use case, since I *really* hope none
> of the oe-core recipes actually do this, but the QA test can be
> extended in your layers to test your own images if you want.
FYI: I raised a bugzilla to track this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13567
>
> >
> > I've already looked at the https:// fetcher (which is mostly used for
> > fetching tarballs).
> > It requires the recipe to contain valid md5 and sha256 sums. Even if we
> > suppress the
> > error in case checksum mismatch in the recipe by setting the
> > BB_STRICT_CHECKSUM
> > to 0, we are still getting the warning, which is the desired behavior I
> > believe.
> >
> >
> > [1]:
> > https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
> > [2]:
> > https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM
> >
> > --
> > Maciej Pijanowski
> > Embedded Systems Engineer
> > https://3mdeb.com | @3mdeb_com
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] git fetcher - AUTOREV and best practices
On Wed, Jun 5, 2019 at 8:00 AM Maciej Pijanowski
wrote:
>
> Hello,
>
> As explained in the mega manual [1], when using the git:// fetcher,
> setting the
> SRCREV to ${AUTOREV} will result in building the latest commit from
> given git
> branch (master, if not specified otherwise).
>
> Using AUTOREV feature in recipe has following implications as far as I
> can see:
>
> - the same recipe might get built using different git commit, depending
> on when
> the build was run, which breaks the reproducibility,
> - it imposes some potential security risk - by specifying the exact
> commit in
> the recipe, we can at least say that this revision of this package is fine
> and we want to build it; with AUTOREV we might not be aware of the
> code we're
> fetching
>
> I'm wondering whether there are any best practices or strict rules
> written down
> for recipes getting upstream to follow in this area. When inspecting some of
> the layers from the git.yoctoprojects.org, it appears that the AUTOREV
> feature
> is almost not used, besides a few exceptions.
>
> I'm wondering whether it would make sense to raise a warning when git
> fetcher
> with AUTOREV is used, so it would be easier to build on top OE / Yocto with
> reproducibility / security in mind.
>
> I understand that this feature is mostly meant for development purposes. I'm
> just looking for a tools how one could easily make sure that each
> fetched source code
> is verified prior compilation.
Yes, I think warning about using AUTOREV makes a lot of sense for all
the reasons you have raised. I'm not sure that putting that in the git
fetcher is necessarily the best place for that. OE has an extensive
set of QA checks that run when recipes are built, and I think that
this might be a better/easier place to put this check. IMHO, recipes
that force you to use AUTOREV in the base recipe are broken and should
be fixed, in which case a QA check should be sufficient. The harder
part is making sure that it doesn't trigger when someone is using
AUTOREV legitimately for development purposes. OE already has a class
that encapsulates the logic for reproducible builds
(reproducible_build.bbclass); one approach might be to add the QA
check, and then add it to the list of QA checks that fail the build
(ERROR_QA from insane.bbclass) in reproducible_build.bbclass.
As a bonus, the 3.0 zeus release adds a QA check for reproducible
builds, so such a QA check would get detected on the autobuilder if
someone changed a oe-core recipe to use AUTOREV by default. I suspect
that doesn't help your immeidate use case, since I *really* hope none
of the oe-core recipes actually do this, but the QA test can be
extended in your layers to test your own images if you want.
>
> I've already looked at the https:// fetcher (which is mostly used for
> fetching tarballs).
> It requires the recipe to contain valid md5 and sha256 sums. Even if we
> suppress the
> error in case checksum mismatch in the recipe by setting the
> BB_STRICT_CHECKSUM
> to 0, we are still getting the warning, which is the desired behavior I
> believe.
>
>
> [1]:
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
> [2]:
> https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM
>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> https://3mdeb.com | @3mdeb_com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
