Re: [Openembedded-architecture] [OE-core] Where are we at?

[Ross Burton]

> On 9 May 2024, at 10:37, Richard Purdie via lists.openembedded.org 
>  wrote:
> Intermittent do_compile failure in libportal:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4760/steps/12/logs/stdio

Root caused this, fix incoming.

> debuginfod keeps breaking:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/3299/steps/14/logs/stdio
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14937

I realised that I didn’t do what I thought I had previously so understand this 
now, hopefully fixable tomorrow.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2005): 
https://lists.openembedded.org/g/openembedded-architecture/message/2005
Mute This Topic: https://lists.openembedded.org/mt/106007445/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Openembedded-architecture] New mailing list for layer patches

[Ross Burton]

Hi,

At the moment if a layer doesn’t have enough volume to justify a dedicated 
mailing list for patches (see, for example, meta-...@lists.yoctoproject.org 
) then the convention is that the 
patches can be sent to yo...@lists.yoctoproject.org 
.

However, that’s also the list that we encourage users of Yocto to use for help, 
so the list has a mix of patches for various layers and people asking for help, 
which isn’t ideal: users who want help don’t want to be flooded with patches 
for layers they’re not using, layer maintainers may not want to see the 
requests for help, and people who want the status reports have to receive 
patches and support.

The Yocto TSC has been discussing this, and as a solution to this we’ve just 
created a new mailing list: yocto-patc...@lists.yoctoproject.org 
.  This list is specifically for 
Yocto-related projects which don’t have their own mailing list or other patch 
submission process.   We ask that all layers currently using yocto@ for patches 
move to yocto-patches@, so that yocto@ can be used purely for discussion and 
other non-patch related subjects.

Many thanks,
Ross
Yocto TSC member
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1982): 
https://lists.openembedded.org/g/openembedded-architecture/message/1982
Mute This Topic: https://lists.openembedded.org/mt/105197686/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig

[Ross Burton]

From: Ross Burton 

This is a new 64-bit "generic" Arm machine, that expects the hardware to
be SystemReady IR compatible. This is slightly forward-leaning as there's
not a _lot_ of SystemReady hardware in the wild, but most modern boards
are and the number will only grow.  Also, this is the only way to have a
'generic' machine as without standardised bootloaders and firmware it
would be impossible.

The base machine configuration isn't that exciting: it's a fully featured
machine that supports most things, booting via UEFI and an initramfs.

However, the kernel is more interesting.  This RFC uses the upstream defconfig
because unlike some other platforms, the arm64 defconfig is actively
maintained with the goal of being a 'boots on most hardware' configuration.
My argument is: why would we duplicate that effort?

The "linux-yocto way" is configuration fragments and after a week of
hair-pulling I do actually have fragments that boot on a BeaglePlay, but
to say this was a tiresome and frustrating exercise would be understating it.

So, a request for comments: is it acceptable to use the upstream defconfig in
a reference BSP?  Personally I'm torn: the Yocto way is fragments not monolithic
configs, but repeating the effort to fragmentise the configuration and then
also have it sufficiently modular that it can be used in pieces - instead of
just being a large file split up into smaller files - is a lot of effort for
what might end up being minimal gain.  My fear is we end up with a fragmented
configuration that can't be easily modified without breaking some platforms,
and badly copies what the defconfig already does.

Ross
---
 meta-yocto-bsp/README.hardware.md |  7 +
 meta-yocto-bsp/conf/machine/genericarm64.conf | 26 +++
 .../linux/linux-yocto_6.6.bbappend|  9 +++
 meta-yocto-bsp/wic/genericarm64.wks.in| 11 
 4 files changed, 53 insertions(+)
 create mode 100644 meta-yocto-bsp/conf/machine/genericarm64.conf
 create mode 100644 meta-yocto-bsp/wic/genericarm64.wks.in

diff --git a/meta-yocto-bsp/README.hardware.md 
b/meta-yocto-bsp/README.hardware.md
index a8f38cb21a6..58ebc328b56 100644
--- a/meta-yocto-bsp/README.hardware.md
+++ b/meta-yocto-bsp/README.hardware.md
@@ -29,6 +29,7 @@ The following boards are supported by the meta-yocto-bsp 
layer:
 
   * Texas Instruments Beaglebone (beaglebone-yocto)
   * General IA platforms (genericx86 and genericx86-64)
+  * General 64-bit Arm SystemReady platforms (genericarm64)
 
 For more information see the board's section below. The appropriate MACHINE
 variable value corresponding to the board is given in brackets.
@@ -126,6 +127,12 @@ USB Device:
dd command to write the image to a USB stick.
 
 
+SystemReady Arm Platforms
+=
+
+TODO
+
+
 Texas Instruments Beaglebone (beaglebone-yocto)
 ===
 
diff --git a/meta-yocto-bsp/conf/machine/genericarm64.conf 
b/meta-yocto-bsp/conf/machine/genericarm64.conf
new file mode 100644
index 000..2ea270d8b06
--- /dev/null
+++ b/meta-yocto-bsp/conf/machine/genericarm64.conf
@@ -0,0 +1,26 @@
+#@TYPE: Machine
+#@NAME: genericarm64
+#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
+#have working firmware and boot via EFI.
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Arm Base System Architecture says v8.0+ is allowed, but FEAT_CRC32 is 
required
+DEFAULTTUNE = "armv8a-crc"
+
+MACHINE_FEATURES = "acpi alsa bluetooth efi keyboard pci qemu-usermode rtc 
screen usbhost vfat wifi"
+
+# Install all the kernel modules and all the firmware
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
+
+KERNEL_IMAGETYPE = "Image"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+INITRAMFS_IMAGE ?= "core-image-initramfs-boot"
+
+IMAGE_FSTYPES ?= "wic"
+WKS_FILE ?= "genericarm64.wks.in"
+
+EFI_PROVIDER ?= "${@bb.utils.contains("DISTRO_FEATURES", "systemd", 
"systemd-boot", "grub-efi", d)}"
+
+# Try to bring up one physical serial console, or a virtualized serial console
+SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
index 8e465c241e8..18f95de348f 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.6.bbappend
@@ -1,19 +1,28 @@
 KBRANCH:genericx86  = "v6.6/standard/base"
+KBRANCH:genericarm64  = "v6.6/standard/base"
 KBRANCH:genericx86-64  = "v6.6/standard/base"
 KBRANCH:beaglebone-yocto = "v6.6/standard/beaglebone"
 
+KMACHINE:genericarm64 ?= "genericarm64"
 KMACHINE:genericx86 ?= "common-pc"
 KMACHINE:gen

Re: [Openembedded-architecture] Removal/disable of testimage dumper code in LTS branches?

[Ross Burton]

On 21 Dec 2023, at 15:06, Richard Purdie via lists.openembedded.org 
 wrote:
> Whilst I'm fully aware of our stable branch policies, there is probably
> a case for making a more invasive change than usual in this area due
> top the scope of the issues.

Fundamentally broken code that causes stalls, performance issues, and build 
failures?

This email makes a wonderful case for the exception and I have no problem with 
removing the code.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1896): 
https://lists.openembedded.org/g/openembedded-architecture/message/1896
Mute This Topic: https://lists.openembedded.org/mt/103301450/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] Weak PACKAGECONFIG removal

[Ross Burton]

> On 21 Dec 2023, at 22:55, Peter Kjellerstedt via lists.openembedded.org 
>  wrote:
> For what it's worth, my vote would be on 4), and using = as the new standard. 
> That is what we do in all our own recipes.
> 
> It is a simple change (simple to understand, that is), which does not 
> introduce any new special syntax or new variables. I do not think it would 
> actually break many (any?) existing layers, at least no worse than many other 
> changes that have been introduced over the years. And the reason for that is 
> that any layer that is manipulating a recipe's PACKAGECONFIG today would 
> either have to do that through an override in a .conf file, and that would 
> continue to work, or through a bbappend, and that too would continue to 
> work since the only options today are either full a replacement using 
> PACKAGECONFIG = "..." or :append/:remove, both of which would also continue 
> to work.

Agreed, and I’ve thought this for several years too.

The only fallout I can see right now would be a recipe that has:

PACKAGECONFIG ??= “foo”

And then a bbappend that does:

PACKAGECONFIG += “bar”

The end result now with be “bar”, but this change would mean that becomes “foo 
bar”.  Which, arguably, is the _intention_ of using +=, as if the bbappend 
wanted to overwrite entirely then it would have.  This behavioural change is 
easily release noted.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1895): 
https://lists.openembedded.org/g/openembedded-architecture/message/1895
Mute This Topic: https://lists.openembedded.org/mt/103269425/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] Weak PACKAGECONFIG removal

[Ross Burton]

On 22 Dec 2023, at 04:59, Chen Qi via lists.openembedded.org 
 wrote:
>> One of the major things that comes up frequently is that the
>> PACKAGECONFIG for a recipe needs to be modified to remove some
>> incompatible flag from the default options. This particular option is
>> not very simple though, because most recipes set PACKAGECONFIG using
>> the "deferred weak" assignment, as in `PACKAGECONFIG ??= "foo bar"`.
>> Because of this, any operation that attempts to modify this variable
>> will overwrite the default; commonly one might like to do something
>> like `PACKAGECONFIG:remove = "foo"`, but since this happens before
>> weak assignment, the result is an empty string instead of just the
>> value "bar".
> 
> Checking the master branch, and I get a different result.

Indeed. With this in local.conf, or split across a recipe/bbappend:

FOOBAR ??= "foo bar"
FOOBAR:remove = “foo"

$ bitbake-getvar  FOOBAR
#
# $FOOBAR [2 operations]
#   set /yocto/ross/build/conf/local.conf:495
# [_defaultval] "foo bar"
#   :remove /yocto/ross/build/conf/local.conf:496
# "foo"
# pre-expansion value:
#   "foo bar"
FOOBAR=" bar”

$ bitbake-getvar  FOOBAR -r psplash
#
# $FOOBAR [2 operations]
#   set /home/ross/Yocto/poky/meta/recipes-core/psplash/psplash_git.bb:133
# [_defaultval] "foo bar"
#   :remove 
/home/ross/Yocto/poky/meta-poky/recipes-core/psplash/psplash_git.bbappend:3
# "foo"
# pre-expansion value:
#   "foo bar"
FOOBAR=" bar”

Josh: can you provide a minimal reproducer, or did this quietly change 
behaviour at some point?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1894): 
https://lists.openembedded.org/g/openembedded-architecture/message/1894
Mute This Topic: https://lists.openembedded.org/mt/103269425/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Openembedded-architecture] Removing moving "early boot" binaries to /bin

[Ross Burton]

For many years we’ve been carrying patches to recipes to move some libraries or 
binaries into /bin and /lib, on the argument that people might have /usr on 
another mount.

I don’t believe this has been the case for a long time.

Modern systems either have more than enough space that / and /usr don’t need to 
be on separate devices, or alternatively you can have an initramfs which is 
actually constructed explicitly to be small and contains what is needed, 
without the /bin vs /usr/bin argument.

I propose removing all of the patches to recipes that cater for this (eg, tar 
manually moves the binary to /bin), but I thought it best to shout here in case 
anyone is aware of anyone who still needs this functionality _and_ will be 
moving to Yocto 5.0.  That second clause is important: I don’t care about 
people who won’t be using Yocto 5 as this won’t be backported.

Cheers,
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1877): 
https://lists.openembedded.org/g/openembedded-architecture/message/1877
Mute This Topic: https://lists.openembedded.org/mt/103033053/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] [RFC] Support for alternative init systems

[Ross Burton]

On 7 Nov 2023, at 09:30, ANQUETIN Mathieu via lists.openembedded.org 
 wrote:
> This forces layers, like meta-openrc for example, to remove files generated 
> by other layers before providing their own. This increases the maintenance 
> burden for layer maintainers of these alternative init systems while making 
> them always feel like second-class citizens.

No, it doesn’t.

Remove sysvinit and systemd from DISTRO_FEATURES and the relevant classes will 
delete the initscripts/systemd units from the packages.

I wasn’t aware of meta-openrc, but it should just have an openrc init feature 
and behave the same as the existing init classes.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1839): 
https://lists.openembedded.org/g/openembedded-architecture/message/1839
Mute This Topic: https://lists.openembedded.org/mt/102439769/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] [yocto-security] Question: supported layers for security processes

[Ross Burton]

On 20 Oct 2023, at 09:56, Marta Rybczynska via lists.yoctoproject.org 
 wrote:
> 
> Hello,
> While working on multiple aspects of security processes, one question
> comes back frequently: which are the layers we support with those
> processes? This has impact on the number of SECURITY.md I will be
> submitting, of configuring any CVE synchronization work etc.
> 
> The YP download page offers a download of poky. The release
> documentation 
> https://docs.yoctoproject.org/migration-guides/index.html#release-information
> nor the Release page (https://wiki.yoctoproject.org/wiki/Releases)
> does not exactly list layers covered.
> 
> Is it poky only? Poky + meta-openemedded? With some BSP layers?

I’d say that _to start_ we limit the scope to openembedded-core as it’s the 
foundational layer.  Other layers can join in the future, personally I’d like 
to see meta-arm adopt the process formally.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1801): 
https://lists.openembedded.org/g/openembedded-architecture/message/1801
Mute This Topic: https://lists.openembedded.org/mt/102085361/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] [yocto-security] Question: supported layers for security processes

[Ross Burton]

On 20 Oct 2023, at 16:25, Armin Kuster via lists.yoctoproject.org 
 wrote:
>> We should probably mention this issue to the other layer maintainers,
>> maybe on the architecture list and perhaps also open a bug to make
>> SECURITY.md a requirement for Yocto Project Compatible status?
> Why? My layers only have upstream components. I would just tell an individual 
> to go to the upstream source and deal with those maintainers. I bring no 
> value being in the middle.

That’s not quite true.  You could have patched a security-critical library with 
what you thought was an innocent patch and inadvertently created a massive 
security flaw.  This is nothing to do with upstream and entirely the layer’s 
responsibility.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1800): 
https://lists.openembedded.org/g/openembedded-architecture/message/1800
Mute This Topic: https://lists.openembedded.org/mt/102083332/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] YP Security team document

[Ross Burton]

On 17 Oct 2023, at 11:24, Richard Purdie via lists.openembedded.org 
 wrote:
> 
> On Tue, 2023-10-17 at 12:09 +0200, Marta Rybczynska wrote:
>> Hello all,
>> This has been a moment working on the YP security team and I think
>> that the current version of the document contains everything that it
>> should have to get it a go. Please have a look and let me know if you
>> have any last comments:
>> https://wiki.yoctoproject.org/wiki/Security_private_reporting
>> 
>> I will then start transcription to the docs.
> 
> I made a few small wording tweaks and added a guide of what we'd like
> to cover with security team membership. Hope that is all ok!
> 
> Otherwise looks good to me.

Agreed, looks good.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1792): 
https://lists.openembedded.org/g/openembedded-architecture/message/1792
Mute This Topic: https://lists.openembedded.org/mt/102014565/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Openembedded-architecture] Proposal: Patch review meetings

[Ross Burton]

Hi all,

I propose that we add a new meeting to 
https://www.yoctoproject.org/public-virtual-meetings/, similar to the Bug 
Triage meeting but to review incoming patches. The patch queue is long and 
whilst we talk about how patches-on-list means anyone can perform drive-by 
review, there’s no way to know if someone has actually reviewed a patch and 
mentally said “this looks good”, or if several people have seen a patch and 
been sceptical but not actually posted their thoughts. This proposal aims to 
counter that problem.

We have a patchwork instance at patchwork.yoctoproject.org which has the 
ability to track patches, their state, and assign them to a specific person. 
This is the bare minimum of a patch triage process, we just need to use it.  I 
admit that what I’m proposing here is inspired by the glibc project process 
(sourceware.org/glibc/wiki/PatchworkReviewMeetings), because I learnt about 
their process whilst attending the GNU Cauldron conference.

As we have a fairly constant stream of patches, I expect these triage meetings 
should be done twice weekly, to allow for rapid feedback and review cycles. 
Each meeting would be an hour long: the first half spent quickly reviewing as 
much of the patch queue as possible with any discussion postponed until the 
second half. This means the attendees can hopefully work through a large number 
of patches quickly before circling back on the more interesting patches.  Any 
patches which result in a bigger discussion or have open questions should 
likely be discusseed in the Engineering Sync, where the attendence will be 
larger.  As patchwork is primarily a read-only system (apart from status and 
delegation), a wiki page will be needed to keep minutes and notes.
I propose the process to be as follows:

1. Obtain last patch ID reviewed from the meeting minutes

2. Iterate through the patches since the last patch reviewed, oldest first, and 
review. Quickly review as a group and assign a delegate and provisional status:
– Looks Good: move to Under Review status. Will be incorporated into a staging 
branch by the delegate so that if it fails testing the status can be changed.
– Looks Bad: move to Rejected status. Note the feedback in the minutes, the 
delegate is responsible for responding on the list with this feedback.
– Needs Work (quick): move to Action Required. Note the feedback in the 
minutes, the delegate is responsible for responding on the list with this 
feedback.
– Needs Further Review. Move to Action Required. Note this choice in the 
minutes, and either discuss later in the call or in the Engineering Sync. It is 
the responsiblity of the delegate to have this discussion.

3. Discuss any patches marked a Needs Further Review, and any other patches 
that the group wish to discuss.

4. Review the state of all patches that have been delegated but not yet 
resolved.

5. Note down in the minutes the last patch ID reviewed, for the next meeting.

As a straw-man proposal, I suggest Monday and Thursday for the calls. The hour 
slot immedatiately after bug triage?

Looking forward to your thoughts,
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1789): 
https://lists.openembedded.org/g/openembedded-architecture/message/1789
Mute This Topic: https://lists.openembedded.org/mt/101862943/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] [Openembedded-architecture] Y2038 proposal

[Ross Burton]

On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org 
 wrote:
>>> * Could we optionally disable some of the glibc 32 bit function calls
>>> to ensure they're not being used? 
>> 
>> Could you be more specific here? Would you like to disable some
>> syscalls?
> 
> I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as 
Debian has a nice sanity check where it warns if non-LFS glibc functions are 
used.  I imagine the same logic could be used to check for 32-bit time_t use.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1677): 
https://lists.openembedded.org/g/openembedded-architecture/message/1677
Mute This Topic: https://lists.openembedded.org/mt/95361985/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] [Automated-testing] RFC Linter in meta-openembedded

[Ross Burton]

On 5 Sep 2022, at 12:25, Marius Kriegerowski via lists.openembedded.org 
 wrote:
> 
> So, I looked into patchtest a few months ago and found a couple of issues 
> where I considered a rewrite. So, I gave it a shot last weekend but instead 
> of python I used rust. You can find the demo here: 
> https://github.com/HerrMuellerluedenscheid/patchtest-rs

There’s definitely still interest in patchtest, but my personal opinion is that 
considering 99% of our code is Python keeping patchtest in python means that 
there are more people who can work on it.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1630): 
https://lists.openembedded.org/g/openembedded-architecture/message/1630
Mute This Topic: https://lists.openembedded.org/mt/88763351/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?

[Ross Burton]

Hi Alex,

On 25 Jul 2022, at 19:13, Alexander Kanavin via lists.openembedded.org 
 wrote:
> an idea just popped into my head that I don't remember having been discussed:
> 
> Should stable-branch oe-core issue a warning via bitbake when it is
> close to EOL and perhaps a stronger warning when it has crossed it?
> 
> I feel that this page:
> https://wiki.yoctoproject.org/wiki/Releases
> is not enough to ensure the message (of not using EOL yocto) reaches
> the users, and we need something better and directly seen by anyone
> invoking bitbake.
> 
> Is it a terrible idea? Awesome idea? Ok-ish idea?

We discussed this in the Yocto TSC last week and this has lots of non-trivial 
complications.

Would this be something done in oe-core, or something that distros (such as 
Poky) can opt in to?  We don’t want to start warning when oe-core is EOL if the 
user is using a commercial Yocto release which still has support for many years.

Would this be done with a variable (be it a EOL date, or a marker) in the git 
repository itself, or something that if fetched periodically?  A variable in 
the git repository would need to be kept up to date, and there’s potentially a 
significant delay between a change landing in oe-core and reaching a user 
(oe-core release -> OSV release -> BSP release) which could result in 
inappropriate warnings.   The same information being online and fetched on 
builds would solve that problem but instead add phone-home issues and the usual 
network complications (caching, no-network use cases, etc).

Whilst we can see that there are definite value propositions in alerting users 
that a release is approaching EOL, there are considerable complications to be 
thought though.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1607): 
https://lists.openembedded.org/g/openembedded-architecture/message/1607
Mute This Topic: https://lists.openembedded.org/mt/92611044/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] Let's drop x86-x32 (was Re: [OE-core] [PATCH 05/51] rpm: update 4.17.0 -> 4.17.1)

[Ross Burton]

On 20 Jul 2022, at 10:28, Alexander Kanavin via lists.openembedded.org 
 wrote:
> 
> On Wed, 20 Jul 2022 at 11:23, Richard Purdie
>  wrote:
>> That amounts to dropping x32 support because as soon as we remove these
>> tests, it will bitrot.
>> 
>> There is still some value in the project being able to support
>> different architectures and different type sizes so I do still lean
>> towards keeping this alive at a minimal level.
> 
> But then why not replace x32 with riscv32, which as well has 32 bit
> pointers but 64 bit integers and thus trips over the same type size
> issues?

Does the RISC-V ecosystem care about riscv32?

The problem with Intel x32 is that very few people care, so we end up fixing 
upstream software.  If RISC-V cares then we won’t be alone.

Also, Intel should get to have an opinion on this.  If they actually care about 
x32 then they can help fix the issues, if they don’t then we can easily switch 
to a platform that has support.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1587): 
https://lists.openembedded.org/g/openembedded-architecture/message/1587
Mute This Topic: https://lists.openembedded.org/mt/92500615/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] Layer setup survey results

[Ross Burton]

> I haven't checked out all the tools listed in the survey, but does any of 
> them handle managing local patches being applied to the meta layers/git repos 
> ? Because that is the single reason I'm still using a custom 
> Makefile+scripts. I do *not* want to manage my own forked git repos for all 
> layers that contain my customizations. And before you ask why I need 
> customizations in layers, welcome to the real world.

Kas certainly does.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1583): 
https://lists.openembedded.org/g/openembedded-architecture/message/1583
Mute This Topic: https://lists.openembedded.org/mt/92338685/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] meta-gplv2 - plan to drop support in master

[Ross Burton]

> It’s actively accumulating security fixes 

Obviously I meant "passively accumulating security issues”.

Clearly, time to have a sit down away from the keyboard.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1568): 
https://lists.openembedded.org/g/openembedded-architecture/message/1568
Mute This Topic: https://lists.openembedded.org/mt/92209067/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] meta-gplv2 - plan to drop support in master

[Ross Burton]

On 6 Jul 2022, at 16:34, Richard Purdie via lists.openembedded.org 
 wrote:
> 
> meta-gplv2 makes the TSCs very nervous (certainly YP and I believe OE
> TSC people too although it hasn't had an official discussion there). It
> has a load of old "pre GPLv3 license" versions of software that haven't
> seen security fixes for years. We've limped it along to our last LTS.
> It has no active maintainer.

I for one agree with this proposal.  For several years we’ve said that this 
layer is basically on life support, someone who uses it should step up and 
maintain it, and yet at no point does this happen.  It’s actively accumulating 
security fixes so can’t seriously be used in any real deployments as-is, so it 
must be redundant.  There’s no point in redundant code taking up the 
not-maintainers time, so we can remove it.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1567): 
https://lists.openembedded.org/g/openembedded-architecture/message/1567
Mute This Topic: https://lists.openembedded.org/mt/92209067/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] ARM32 Millenium Bug

[Ross Burton]

How are you setting -D_TIME_BITS?  You want them to be specific to
target builds, I'm guessing those errors are what happens when you
pass those flags directly to the native build steps.

Ross

On Tue, 22 Feb 2022 at 13:58, Martin Leduc  wrote:
>
> Well well well,
>
>
>
> I definitely don't understand why bitbake try to compile x86-64 when I've 
> defined ARM32 architecture.  Probably the cross compiler ☹.
>
>
>
> --dynamic-linker=/home/ltg/honister/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>  -lsqlite3 -lpthread -ldl -lpthread
>
> | {standard input}: Assembler messages:
>
> | {standard input}:20333: Error: symbol `open64' is already defined
>
> | {standard input}:21238: Error: symbol `openat64' is already defined
>
> | {standard input}:24673: Error: symbol `stat64' is already defined
>
> | {standard input}:25158: Error: symbol `lstat64' is already defined
>
> | {standard input}:25643: Error: symbol `fstat64' is already defined
>
> | {standard input}:27003: Error: symbol `fstatat64' is already defined
>
> | {standard input}:31543: Error: symbol `__fxstat64' is already defined
>
> | {standard input}:32524: Error: symbol `__fxstatat64' is already defined
>
> | {standard input}:33546: Error: symbol `__lxstat64' is already defined
>
> | {standard input}:34498: Error: symbol `__openat64_2' is already defined
>
> | {standard input}:36430: Error: symbol `__xstat64' is already defined
>
> | {standard input}:43039: Error: symbol `creat64' is already defined
>
> | {standard input}:50405: Error: symbol `fcntl64' is already defined
>
> | {standard input}:52666: Error: symbol `fopen64' is already defined
>
> | {standard input}:53998: Error: symbol `freopen64' is already defined
>
> | {standard input}:56267: Error: symbol `ftw64' is already defined
>
> | {standard input}:62238: Error: symbol `glob64' is already defined
>
> | {standard input}:70550: Error: symbol `mkostemp64' is already defined
>
> | {standard input}:71817: Error: symbol `mkstemp64' is already defined
>
> | {standard input}:73999: Error: symbol `nftw64' is already defined
>
> | {standard input}:78633: Error: symbol `scandir64' is already defined
>
> | {standard input}:96084: Error: symbol `truncate64' is already defined
>
> | ERROR: oe_runmake failed
>
>
>
> Any idea?
>
>
>
>
>
> Martin Leduc
>
> T : (418) 856-6896
>
> martin.le...@luminator.com
>
>
>
>
>
> -Message d'origine-
> De : Phil Blundell 
> Envoyé : 22 février 2022 08:10
> À : Martin Leduc 
> Cc : openembedded-architecture@lists.openembedded.org
> Objet : [EXTERNAL] Re: [Openembedded-architecture] ARM32 Millenium Bug
>
>
>
> CAUTION: This email originated from outside of Luminator Technology Group. Do 
> not click links or open attachments unless you recognize the sender and know 
> the content is safe.
>
>
>
> On Tue, Feb 22, 2022 at 05:01:55AM -0800, Martin Leduc wrote:
>
> > I'm wondering how we can manage the Millenium bug (2038-01-19 03:15 AM) on 
> > the ARM32 Platform.  As far as I know, the Kernel 5.14 and GLibc 2.34 are 
> > require and Honister comply to theses requirements but the bug isn't 
> > handled.
>
> >
>
> > Have you any idea on how to "enable" the differents workaround?
>
>
>
> At the moment I think you need to build with -D_TIME_BITS=64 
> -D_FILE_OFFSET_BITS=64.  This is not the default (in glibc) on aarch32 for 
> ABI compatibility reasons, but you could add it to your global CFLAGS in your 
> distro configuration if you wanted.
>
>
>
> p.
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1485): 
https://lists.openembedded.org/g/openembedded-architecture/message/1485
Mute This Topic: https://lists.openembedded.org/mt/89315888/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] proposal: allow Upstream-Status: Inactive-Upstream in patches

[Ross Burton]

On Tue, 14 Dec 2021 at 18:09, Konrad Weihmann  wrote:

> to quote the docu:
>
> Backport
> - Backported from new upstream version, because we are at a fixed version,
>  include upstream version info
>
> which implies that there is an upstream *version* available containing
> that fix.
>
> But in the end your are totally right, if it has been merged it's a
> backport, so we should also adjust the documentation of Backport to not
> mention a version as a prerequisite

Yes, there being a release is irrelevant.  The point is that it's upstream.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1404): 
https://lists.openembedded.org/g/openembedded-architecture/message/1404
Mute This Topic: https://lists.openembedded.org/mt/87612566/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] proposal: allow Upstream-Status: Inactive-Upstream in patches

[Ross Burton]

On Tue, 14 Dec 2021 at 17:46, Konrad Weihmann  wrote:
> > If we're adding a new one, can I suggest we remove Accepted?
> >
> > A patch is either submitted to upstream but hasn't been merged
> > (Submitted), or the patch is taken from upstream (Backport).  Accepted
>
> No I think Accepted has its place - this is for the limbo state when
> upstream merged the patch but no release has been made so far.
>
> So I would keep it

If it's merged the patch is a backport.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1398): 
https://lists.openembedded.org/g/openembedded-architecture/message/1398
Mute This Topic: https://lists.openembedded.org/mt/87612566/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] proposal: allow Upstream-Status: Inactive-Upstream in patches

[Ross Burton]

On Mon, 13 Dec 2021 at 17:38, Alexander Kanavin  wrote:
> I added the following to the wiki:
>
>'''Inactive-Upstream [lastcommit: when (and/or) lastrelease: when]'''
>- The upstream is no longer available. This typically means a defunct 
> project
>  where no activity has happened for a long time - measured in years. To 
> make
>  that judgement, it is recommended to look at not only when the last 
> release
>  happened, but also when the last commit happened, and whether newly made 
> bug
>  reports and merge requests since that time receive no reaction. It is 
> also
>  recommended to add any relevant links to the commit message where the 
> inactivity
>  can be clearly seen.
>
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status

If we're adding a new one, can I suggest we remove Accepted?

A patch is either submitted to upstream but hasn't been merged
(Submitted), or the patch is taken from upstream (Backport).  Accepted
makes no sense.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1396): 
https://lists.openembedded.org/g/openembedded-architecture/message/1396
Mute This Topic: https://lists.openembedded.org/mt/87612566/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [docs] [Openembedded-architecture] proposal: allow Upstream-Status: Inactive-Upstream in patches

[Ross Burton]

On Tue, 14 Dec 2021 at 10:38, Alexander Kanavin  wrote:
>
> On Tue, 14 Dec 2021 at 11:30, Michael Opdenacker 
>  wrote:
>>
>> Are you suggesting to expand the official Yocto Project docs on this topic?
>> Actually, I only see
>> https://docs.yoctoproject.org/dev-manual/common-tasks.html#patching-code
>> which explains the use of patches. There is much more content indeed in
>> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
>
> I would suggest you link to the wiki, but please do not copy any content, as 
> it will certainly become mismatched.

I'd actually suggest the proper documentation is improved, and the
wiki page retired.  Wikis are great for getting something written
down, but if the proper documentation can have a chapter, then that's
even better.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1394): 
https://lists.openembedded.org/g/openembedded-architecture/message/1394
Mute This Topic: https://lists.openembedded.org/mt/87718475/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] [RFC] hard DEPENDS assignment

[Ross Burton]

On Tue, 7 Dec 2021 at 17:15, Konrad Weihmann  wrote:
> TBF
>
> the correct fix would be
>
> magic.bbclass
> ---
> DEPENDS:append = " magic-dependency"
> ---
>
> but unfortunately sometimes this is out of our control (as we don't want
> to have bbclassappends for totally valid reasons)
>
> Thoughts?

Personally, I'd say that's the correct fix, and any class that
DEPENDS= is just broken. Recipes should be able to do DEPENDS= because
that's convenient, and classes should use DEPENDS:append.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1375): 
https://lists.openembedded.org/g/openembedded-architecture/message/1375
Mute This Topic: https://lists.openembedded.org/mt/87569589/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] meta-gplv2 support from YP testing in master

[Ross Burton]

On 22/01/2020 13:27, Alexander Kanavin wrote:

Note that there is already a test for gpl3-free images in
meta/lib/oeqa/selftest/cases/incompatible_lic.py

Currently minimal and full-cmdline images are tested (the latter with 
PACKAGECONFIG_remove tweaks to drop gpl3 stuff that is directly pulled 
in), so a similar test configuration could be added for sato.


Right, Sato is very close too and could be added. Bash is the only 
tricky point once a few more low hanging fruit is kicked out.


Ross
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] meta-gplv2 support from YP testing in master

[Ross Burton]

On 22/01/2020 12:02, Ross Burton wrote:

How much actually breaks without meta-gpl2 now?


Some quick poking doing a core-image-sato for qemux86-64:

- dosfstools is GPLv3 and pulled into qemu images now via the vfat 
machine feature.  Easy enough to make that dependency conditional on 
license blacklist.


- Lots of ptests depend on GNU Make. Turn off ptests.

- Some recipes depend on Bash such as opkg-utils, pulseaudio, systemd, 
python3.  Should review these but for now I added that back.


- Bluez and Python by default need readline but there's a packageconfig 
for those.


- Python and Perl want gdbm, there's a PACKAGECONFIG for those.

- matchbox-terminal needs vte.  Pretty terminal (sorry) but easily 
swapped for xterm or rxvt.


- libpam depends on coreutils.  PAM is a DISTRO_FEATURE, or the 
packaging can be changed to respect the license blacklist.


- connman hard-depends on readline right now.  Easy to add a 
PACKAGECONFIG to disable the cli tool


- shared-mime-info depends on itstool.  I thought this would actually be 
itstool-native, will investigate.


But with those changes, I've a core-image-sato building.

Ross
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] meta-gplv2 support from YP testing in master

[Ross Burton]

On 18/01/2020 11:19, Richard Purdie wrote:

I believe the concept of meta-gplv2 is broken. We don't want to
maintain old versions of the software in a clean room style environment
as the upstreams all move forward with new development, features and
incompatibilities. It was created as a bandaid, its probably time to
move on?

We'd be better off looking at replacing these components with others
with acceptable licensing, as Alex recently demonstrated in OE-Core.


I agree.  The bulk of the software in there is *old*.  I hope that the 
intesection of "I'm releasing a commercial product, GPLv3 is forbidden" 
and "I'm releasing a commercial product but don't care the software I'm 
shipping is a decade old" is pretty small.


How much actually breaks without meta-gpl2 now?

Ross
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] OE-Core python minimum version requirement

[Ross Burton]

On 04/12/2019 17:45, Richard Purdie wrote:

I just enabled hashequiv's server in local mode by default in poky.

This causes an unintended side effect of requiring python 3.5 as the
minimum version.

We had thought that the servers would be 'rare' and a 3.5 version
requirement for that was fine. It turns out a local server is also
extremely useful.

The code needed the python 3.5 async support and trying to write it any
other way is a nightmare, we need that performance for the server.

At this point I think we just give in and require python 3.5 as a
minimum. Any objections?


None here.

For reference, 3.5.0 was released in September 2015 and is in 
security-fixes only mode.


Ross
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture