I think my problem is that the do_image_* are running as fakeroot/pseudo. Is there a way to run this task as a normal local user. I read that I should create the socket when not running under local

Hi, thanks for the reply - I've put it in the bblayers.conf - working. cheers, Thomas

All, The below were the owners of enhancements or bugs closed during the last

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

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

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

Yes, it's worth. Thanks

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

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

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?

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

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

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

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

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

Hi, I'm using this command from a new image type ''' gpg --homedir home --encrypt --sign --default-key "server@..." --pinentry-mode loopback --passphrase-file server.passphrase --recipient

Please unsubscribe me from the mailing list.

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,

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

i suspected it was a WR thing, thanks. rday