[linux-yocto] [linux-yocto rt v5.2] mm: slub: Always flush the delayed empty slubs in flush_all()

[Kevin Hao]

commit 23a2c31b19e99beaf5107071b0f32a596202cdae from
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git

After commit f0b231101c94 ("mm/SLUB: delay giving back empty slubs to
IRQ enabled regions"), when the free_slab() is invoked with the IRQ
disabled, the empty slubs are moved to a per-CPU list and will be
freed after IRQ enabled later. But in the current codes, there is
a check to see if there really has the cpu slub on a specific cpu
before flushing the delayed empty slubs, this may cause a reference
of already released kmem_cache in a scenario like below:
cpu 0   cpu 1
  kmem_cache_destroy()
flush_all()
 --->IPI   flush_cpu_slab()
 flush_slab()
   deactivate_slab()
 discard_slab()
   free_slab()
 c->page = NULL;
  for_each_online_cpu(cpu)
if (!has_cpu_slab(1, s))
  continue
this skip to flush the delayed
empty slub released by cpu1
kmem_cache_free(kmem_cache, s)

   kmalloc()
 __slab_alloc()
free_delayed()
__free_slab()
reference to released kmem_cache

Fixes: f0b231101c94 ("mm/SLUB: delay giving back empty slubs to IRQ enabled 
regions")
Signed-off-by: Kevin Hao 
Signed-off-by: Sebastian Andrzej Siewior 
Cc: stable...@vger.kernel.org
---
Hi Bruce,

Please help me merge this into the following two branches:
  v5.2/standard/preempt-rt/base
  v5.4/standard/preempt-rt/base

 mm/slub.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 05f176aa7f70..5c10491cd93a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2382,9 +2382,6 @@ static void flush_all(struct kmem_cache *s)
for_each_online_cpu(cpu) {
struct slub_free_list *f;
 
-   if (!has_cpu_slab(cpu, s))
-   continue;
-
f = _cpu(slub_free_list, cpu);
raw_spin_lock_irq(>lock);
list_splice_init(>list, );
-- 
2.26.2

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

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

[yocto] Enhancements/Bugs closed WW21!

[Stephen Jolley]

All,

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


Who

Count


jean-marie.lemeta...@savoirfairelinux.com

10


akuster...@gmail.com

3


randy.macl...@windriver.com

2


ota...@ossystems.com.br

1


r...@burtonini.com

1


ricardo.riba...@gmail.com

1


st...@sakoman.com

1


nicolas.deche...@linaro.org

1


alex.kana...@gmail.com

1


Grand Total

21

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

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

[yocto] 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 344
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...@gmail.com
 ) 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...@gmail.com
 

 

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

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

[yocto] 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 WW21 of who have
open medium or higher bugs and enhancements against YP 3.2.   There are 110
possible work days left until the final release candidates for YP 3.2 needs
to be released.


Who

Count


richard.pur...@linuxfoundation.org

30


david.re...@windriver.com

19


bluelightn...@bluelightning.org

17


akuster...@gmail.com

12


bruce.ashfi...@gmail.com

12


kai.k...@windriver.com

10


r...@burtonini.com

9


qi.c...@windriver.com

9


trevor.gamb...@windriver.com

8


mark.mor...@windriver.com

8


randy.macl...@windriver.com

7


jpewhac...@gmail.com

7


changqing...@windriver.com

6


timothy.t.orl...@intel.com

6


mich...@yoctoproject.org

5


rpj...@crashcourse.ca

4


pbar...@konsulko.com

4


anuj.mit...@intel.com

4


mingli...@windriver.com

4


yi.z...@windriver.com

3


raj.k...@gmail.com

3


jon.ma...@arm.com

3


kexin@windriver.com

3


alex.kana...@gmail.com

3


hongxu@windriver.com

3


mostthings...@gmail.com

2


mark.ha...@kernel.crashing.org

2


dl...@gmx.de

2


se...@seebs.net

2


ycnakaj...@gmail.com

2


kerg...@gmail.com

2


alejan...@enedino.org

2


chee.yang@intel.com

2


jae...@xilinx.com

2


akus...@mvista.com

2


jpuhl...@mvista.com

2


joe.sla...@windriver.com

1


nicolas.deche...@linaro.org

1


ydir...@free.fr

1


st...@sakoman.com

1


ricardo.riba...@gmail.com

1


naveen.kumar.sa...@intel.com

1


de...@denix.org

1


kai.ruh...@live.com

1


jason.wes...@windriver.com

1


sakib.sa...@windriver.com

1


matthew.z...@windriver.com

1


martin.ja...@gmail.com

1


liu.min...@gmail.com

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

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

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

Re: [linux-yocto] v5.2.x - stable updates comprising v5.2.41

[Bruce Ashfield]

On Fri, May 22, 2020 at 9:16 AM Paul Gortmaker
 wrote:
>
> Bruce, Yocto kernel folks:
>
> Here is the next 5.2.x stable update "extension" primarily created for
> the Yocto project, as the next v5.2.x post-EOL release.
>
> The content is from an audit of what went into the v5.4.25 to v5.4.29
> releases - plus any upstream commits listed as Fixes: for backports in
> the above v5.4.x content, and a few upstream commits for recent CVE.
>
> There are just under 500 commits deployed here that were applicable for
> this v5.2.41 release.
>
> RCU got a change post-v5.2 (28875945ba98) that allowed an optional 4th
> argument to some list-rcu functions for educating lockdep against false
> positives.  Since we were up to at least four "Fixes:" commits relying
> on this, I decided it would be worthwhile to put in, hence the RCU
> commits early in the series, in case anyone was wondering.  Actual RCU
> functionality itself should remain unchanged.
>
> I've put this 5.2.41 queue through my normal testing, with build tests
> on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and
> finally some sanity runtime tests on x86-64 (raw + qemu/KVM).
>

Thanks Paul, this is now merged and pushed to the repo.

Bruce

> Please find tag v5.2.41 (beb207285e791a8712f10b0d2f8fa880f9d1e10e) as
> the current head of linux-5.2.y branch in the repo in the kernel.org
> directory here:
>
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git/?h=linux-5.2.y
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git
>
> for merge to standard/base in linux-yocto-5.2 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-5.2.git/
>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 5.2.x release.
>
> Paul.



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

On Mon, 25 May 2020, Martin Jansa wrote:

> Yes, it's worth. Thanks

  done, and submitted. it was just my horrific luck that i was testing
that feature, and randomly grabbed two recipes that used standard
assignment. le *sigh* ...

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

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Martin Jansa]

Yes, it's worth. Thanks

On Mon, May 25, 2020 at 7:40 PM Robert P. J. Day 
wrote:

> On Mon, 25 May 2020, Robert P. J. Day wrote:
>
> > On Mon, 25 May 2020, Martin Jansa wrote:
> >
> > > Yes, in local.conf or distro config, both work fine. Maybe your
> > > PNBLACKLIST you're trying to unblacklist is using normal assignment
> > > instead of weak one? See
> >
> >   i just now determined that that is exactly what is happening --
> > tried it with nanopb recipe from meta-oe, which contains:
> >
> >   PNBLACKLIST[nanopb] = "Needs forward porting to use python3"
> >
> > switched that to weak assignment, all good. does that imply that,
> > other than in perhaps exceptional circumstances, *all* blacklisting
> > should use weak assignment?
>
>   never mind, just took a look at the commit which does exactly this.
> is it worth submitting a patch to tweak the few hard assignments?
>
> rday
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

On Mon, 25 May 2020, Robert P. J. Day wrote:

> On Mon, 25 May 2020, Martin Jansa wrote:
>
> > Yes, in local.conf or distro config, both work fine. Maybe your
> > PNBLACKLIST you're trying to unblacklist is using normal assignment
> > instead of weak one? See
>
>   i just now determined that that is exactly what is happening --
> tried it with nanopb recipe from meta-oe, which contains:
>
>   PNBLACKLIST[nanopb] = "Needs forward porting to use python3"
>
> switched that to weak assignment, all good. does that imply that,
> other than in perhaps exceptional circumstances, *all* blacklisting
> should use weak assignment?

  never mind, just took a look at the commit which does exactly this.
is it worth submitting a patch to tweak the few hard assignments?

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

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

On Mon, 25 May 2020, Martin Jansa wrote:

> Yes, in local.conf or distro config, both work fine. Maybe your
> PNBLACKLIST you're trying to unblacklist is using normal assignment
> instead of weak one? See

  i just now determined that that is exactly what is happening --
tried it with nanopb recipe from meta-oe, which contains:

  PNBLACKLIST[nanopb] = "Needs forward porting to use python3"

switched that to weak assignment, all good. does that imply that,
other than in perhaps exceptional circumstances, *all* blacklisting
should use weak assignment?

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

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Martin Jansa]

Yes, in local.conf or distro config, both work fine.

Maybe your PNBLACKLIST you're trying to unblacklist is using normal
assignment instead of weak one? See
http://git.openembedded.org/meta-openembedded/commit/?id=96a92761c0a1bb2317fa4ea422c32e4473405103

On Mon, May 25, 2020 at 7:22 PM Robert P. J. Day 
wrote:

> On Mon, 25 May 2020, Martin Jansa wrote:
>
> > I don't use WR, but setting it to empty works fine for me.
>
>   *where* did you set it to empty? in your local.conf?
>
> > Why do you think it shouldn't work? See
> >
> https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

On Mon, 25 May 2020, Martin Jansa wrote:

> I don't use WR, but setting it to empty works fine for me.

  *where* did you set it to empty? in your local.conf?

> Why do you think it shouldn't work? See
> https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

On Mon, 25 May 2020, Martin Jansa wrote:

> I don't use WR, but setting it to empty works fine for me.
> Why do you think it shouldn't work? See
> https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18

  i tested it ... at least i *thought* i tested it on a blacklisted
recipe. i'll try it again, i guess i just misspelled something.

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

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

Re: [yocto] how to un-blacklist a blacklisted recipe?

[Martin Jansa]

I don't use WR, but setting it to empty works fine for me.

Why do you think it shouldn't work? See
https://git.openembedded.org/openembedded-core/tree/meta/classes/blacklist.bbclass#n18

On Mon, May 25, 2020 at 6:38 PM Robert P. J. Day 
wrote:

>
>   asking what is almost certainly a silly question, but as i'm poring
> over the wind river LTS 19 (aka "zeus") developer's guide, i know that
> WR adds a feature for un-blacklisting blacklisted recipes via the
> PNWHITELIST variable, but the guide says something quite different in
> that it suggests that one can clear a blacklist from a recipe by
> setting the blacklist message to the empty string, as in:
>
>   PNBLACKLIST[recipe] = ""
>
>
> https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_LTS_19_tki1589820771450/page/inj1480988608162.html
>
>   um, wut?
>
>   oddly, there is no mention of WR's PNWHITELIST feature on that page,
> so i assumed that 1) someone forgot to update the guide to mention it,
> and 2) setting the message to the empty string might be the standard
> YP way to do it, but i'm pretty sure that won't work.
>
>   is there a way to un-blacklist a blacklisted recipe using standard
> YP? the reference manual entry for PNBLACKLIST doesn't suggest so:
>
>
> https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PNBLACKLIST
>
>   thoughts?
>
> rday
>
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[yocto] how to un-blacklist a blacklisted recipe?

[Robert P. J. Day]

  asking what is almost certainly a silly question, but as i'm poring
over the wind river LTS 19 (aka "zeus") developer's guide, i know that
WR adds a feature for un-blacklisting blacklisted recipes via the
PNWHITELIST variable, but the guide says something quite different in
that it suggests that one can clear a blacklist from a recipe by
setting the blacklist message to the empty string, as in:

  PNBLACKLIST[recipe] = ""

https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_LTS_19_tki1589820771450/page/inj1480988608162.html

  um, wut?

  oddly, there is no mention of WR's PNWHITELIST feature on that page,
so i assumed that 1) someone forgot to update the guide to mention it,
and 2) setting the message to the empty string might be the standard
YP way to do it, but i'm pretty sure that won't work.

  is there a way to un-blacklist a blacklisted recipe using standard
YP? the reference manual entry for PNBLACKLIST doesn't suggest so:

https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PNBLACKLIST

  thoughts?

rday



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

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

Re: [yocto] overwrite LAYERSERIES_COMPAT_ for different layer

[Quentin Schulz]

On Mon, May 25, 2020 at 03:10:39PM +0200, Martin Jansa wrote:
> You can add a layer which will set LAYERSERIES_COMPAT for another layer,
> but it needs to be parsed before the layer you want to change, e.g.:
> https://github.com/webosose/meta-webosose/blob/thud/meta-qt5-compat/conf/layer.conf
> it's useful to use this layer also to implement whatever modifications are
> needed to make the layer to be actually compatible with the release you're
> using, like:
> https://github.com/webOS-ports/meta-webos-ports/tree/zeus/meta-qt5-compat
> 

FWIW, you could make the parsing order not matter (at least in thud,
from a quick look, master as well). LAYERSERIES_COMPAT is resolved after
all layer.conf have been parsed[1]. I do not know if it's on purpose or
not, meaning it could well disappear in the near future.

So you could override it from anywhere by using __append but it has to
be done before or during the conf/layer.conf parsing. This also makes it
future proof wrt layer priorities and how LAYERSERIES_COMPAT is set (+=,
=, ?= ?).

I personally have it in conf/bblayers.conf (for some reason we "ship"
this one, though it's not best practice IIRC).

[1] 
https://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/cookerdata.py?h=thud#n399

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

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

[yocto] gpg: can't connect to the agent: File name too long

[Damien LEFEVRE]

Hi,

I'm using this command from a new image type
'''
gpg --homedir home --encrypt --sign --default-key "ser...@test.ltd"
--pinentry-mode loopback --passphrase-file server.passphrase  --recipient
"dev...@test.ltd" --output ${IMAGE_LINK_NAME}.fw
${IMGDEPLOYDIR}/${IMAGE_NAME}.img
'''

>From yocto build I get this error

'''
| gpg: can't connect to the agent: File name too long
| gpg: Warning: not using 'ser...@test.ltd' as default key: No secret key
| gpg: all values passed to '--default-key' ignored
'''

I added this img_ota.bbclass

'''
inherit image_types image_types_tegra pythonnative

create_img_ota_pkg() {
rm -rf "${WORKDIR}/my_img"
mkdir -p "${WORKDIR}/my_img"
oldwd=`pwd`
cd "${WORKDIR}/my_img"
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/" home
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/update.passphrase"
update.passphrase
ln -sf "${STAGING_DATADIR_NATIVE}/gpg-keys/encrypt.py" encrypt.py
ln -sf "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.img" "${IMAGE_LINK_NAME}.img"
#gpg --homedir home --encrypt --sign --default-key "ser...@test.ltd"
--pinentry-mode loopback --passphrase-file server.passphrase  --recipient
"dev...@test.ltd" --output ${IMAGE_LINK_NAME}.fw
${IMGDEPLOYDIR}/${IMAGE_NAME}.img
echo $(which python3)
python3 encrypt.py blabla.fw ${IMAGE_LINK_NAME}.img
cd oldwd
}

create_my_pkg[vardepsexclude] += "DATETIME"

IMAGE_CMD_img_ota = "create_img_ota_pkg"
do_image_img_ota[depends] += " \
gpg-keys-native:do_populate_sysroot \
"

IMAGE_TYPEDEP_img_ota += "tegraflash"
IMAGE_TYPES += "img_ota"
'''

I have a native recipe creating the gpg db and install the keys.

I did check the gpg and gpg-agent binaries used come from
/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin

I tried to wrap the command in a python script but it had no effect.

If I open a terminal, add
/test-warrior/build-jetson-xavier/tmp/work/jetson_xavier-poky-linux/test-image/1.0-r0/recipe-sysroot-native/usr/bin
to PATH and run the commands, they go through successfully and I don't
manage to reproduce the error.

What is different with bitbake which could make this fail?

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

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

[yocto] Please unsubscribe me from the mailing list.

[Jean François DAROCHA via lists . yoctoproject . org]

Please unsubscribe me from the mailing list.

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

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

Re: [yocto] overwrite LAYERSERIES_COMPAT_ for different layer

[Martin Jansa]

You can add a layer which will set LAYERSERIES_COMPAT for another layer,
but it needs to be parsed before the layer you want to change, e.g.:
https://github.com/webosose/meta-webosose/blob/thud/meta-qt5-compat/conf/layer.conf
it's useful to use this layer also to implement whatever modifications are
needed to make the layer to be actually compatible with the release you're
using, like:
https://github.com/webOS-ports/meta-webos-ports/tree/zeus/meta-qt5-compat

On Mon, May 25, 2020 at 1:17 PM TRO  wrote:

> Hi,
> have an issue with a layer which doesn't have the current dunfell release
> in it's LAYERSERIES_COMPAT_
> -> can I overwrite it somehow in a different layer or local.conf?
> -> can I configure the error "...is not compatible with the core layer..."
> to a warning?
> cheers, Thomas 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[yocto] overwrite LAYERSERIES_COMPAT_ for different layer

[TRO]

Hi,
have an issue with a layer which doesn't have the current dunfell release in 
it's LAYERSERIES_COMPAT_
-> can I overwrite it somehow in a different layer or local.conf?
-> can I configure the error "...is not compatible with the core layer..." to a 
warning?
cheers, Thomas
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] can i run an arbitrary x86_64-based image under QEMU?

[Robert P. J. Day]

On Sun, 24 May 2020, Alexander Kanavin wrote:

> To me this seems like Wind River's special sauce.
>
> The CHANGELOG in meta-intel says this:
>
> Added QEMU support.
> ---
> We now build several virtio drivers into the kernel by default, and
> have qemuboot.conf files for intel-corei7-64 and intel-core2-32
> targets. This allows one to do basic testing on meta-intel images
> without having to use hardware. The virtio drivers are added via
> KERNEL_FEATURES_INTEL_COMMON. This prevents them from being added to
> custom kernels by default. They can be removed by adding the
> following to a conf or kernel bbappend file:
>   KERNEL_FEATURES_INTEL_COMMON_remove = “cfg/virtio.scc” OVMF
> firmware is also built and can be used in order to emulate a UEFI
> environment. A full runqemu command line for intel-corei7-64 could
> look like this:
>   runqemu core-image-minimal intel-corei7-64 wic ovmf
> ==
>
> It's probably not too difficult to make this work in YP upstream
> (given that qemu is able to run desktop Linux distribution images
> aimed at real HW), but currently this isn't documented or (most
> importantly) tested on the AB.

  i suspected it was a WR thing, thanks.

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

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