[yocto] Enhancements/Bugs closed WW24!

[Stephen Jolley]

All,

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


Who

Count


randy.macl...@windriver.com

7


richard.pur...@linuxfoundation.org

2


ross.bur...@arm.com

1


louis.ran...@syslinbit.com

1


bruce.ashfi...@gmail.com

1


Grand Total

12

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 (#60354): https://lists.yoctoproject.org/g/yocto/message/60354
Mute This Topic: https://lists.yoctoproject.org/mt/99635654/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 4.3

[Stephen Jolley]

All,

Below is the list as of top 31 bug owners as of the end of WW24 of who have
open medium or higher bugs and enhancements against YP 4.3. There are 90
possible work days left until the final release candidates for YP 4.3 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

32


ross.bur...@arm.com

31


richard.pur...@linuxfoundation.org

25


david.re...@windriver.com

25


bruce.ashfi...@gmail.com

24


randy.macl...@windriver.com

21


jpewhac...@gmail.com

10


pa...@zhukoff.net

7


sakib.sa...@windriver.com

6


sundeep.kokko...@windriver.com

5


pi...@pidge.org

4


yash.shi...@windriver.com

3


tim.orl...@konsulko.com

3


alexis.loth...@bootlin.com

3


p.lob...@welotec.com

2


jon.ma...@arm.com

2


yoann.con...@smile.fr

1


tvgamb...@gmail.com

1


thr...@amazon.de

1


thomas.per...@bootlin.com

1


st...@sakoman.com

1


mathew.pro...@gmail.com

1


martin.ja...@gmail.com

1


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

1


mark.asselst...@windriver.com

1


louis.ran...@syslinbit.com

1


johannes.schri...@blueye.no

1


jens.ge...@desy.de

1


geissona...@yahoo.com

1


fathi.bou...@linaro.org

1


alexandre.bell...@bootlin.com

1


Grand Total

218

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 (#60353): https://lists.yoctoproject.org/g/yocto/message/60353
Mute This Topic: https://lists.yoctoproject.org/mt/99635598/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  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 432
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,  "4.3", "4.4", "4.99" and "Future", the more pressing/urgent
issues being in "4.3" and then "4.4".

 

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 (#60352): https://lists.yoctoproject.org/g/yocto/message/60352
Mute This Topic: https://lists.yoctoproject.org/mt/99635576/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] File magic/sdk relocation

[Alexander Kanavin]

On closer look, it should even say:
export MAGIC="\$OECORE_NATIVE_SYSROOT/usr/share/misc/magic.mgc"

If you can test this and confirm that it works, a patch would be welcome.

Alex

On Mon, 19 Jun 2023 at 18:55, Alexander Kanavin via
lists.yoctoproject.org 
wrote:
>
> I think there is a mistake in the file recipe (and rpm has the problem too):
>
> cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/file.sh
> export MAGIC="$OECORE_NATIVE_SYSROOT${datadir}/misc/magic.mgc"
> EOF
>
> $OECORE_NATIVE_SYSROOT should be prefixed with a \ to prevent shell
> variable expansion at build time.
>
> Can you check that the problem is then fixed?
>
> Alex
>
> On Mon, 19 Jun 2023 at 17:50, Oleksiy Obitotskyy via
> lists.yoctoproject.org 
> wrote:
> >
> > Hi,
> >
> > I'm working on master oe core master branch and run into problem with file 
> > for nativesdk (buildtools tarball).
> > File started to use MAGIC variable initialized from 
> > .../environment-setup.d/file.sh, like
> >
> > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc
> >
> > This path relocation does not covered by relocate_sdk.sh script.
> >
> > Commit that change behavior from wrapper that use relative path to 
> > environment variable with absolute path is:
> >
> > commit 47db876d09d9a4394048579c21d0b394450ce681
> > Author: Chen Qi 
> > Date:   Tue Jan 17 12:06:30 2023 +0800
> >
> > file: export MAGIC in SDK
> >
> > Previously, a wrapper is used for file, which adds '--magic-file'
> > option to it. But other components might use libmagic and in such
> > case, if there's no MAGIC environent variable set correctly, things
> > do not work. For example, rpmbuild makes use of libmagic and it
> > requries MAGIC to be set correctly.
> >
> > Signed-off-by: Chen Qi 
> > Signed-off-by: Luca Ceresoli 
> > Signed-off-by: Richard Purdie 
> >
> >
> > I would like to ask if anybody else has such an issue. Any propositions 
> > other than reverting commit?
> >
> > Regards,
> > Oleksiy
> >
> >
> >
>
> 
>

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

Re: [yocto] File magic/sdk relocation

[Alexander Kanavin]

I think there is a mistake in the file recipe (and rpm has the problem too):

cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/file.sh
export MAGIC="$OECORE_NATIVE_SYSROOT${datadir}/misc/magic.mgc"
EOF

$OECORE_NATIVE_SYSROOT should be prefixed with a \ to prevent shell
variable expansion at build time.

Can you check that the problem is then fixed?

Alex

On Mon, 19 Jun 2023 at 17:50, Oleksiy Obitotskyy via
lists.yoctoproject.org 
wrote:
>
> Hi,
>
> I'm working on master oe core master branch and run into problem with file 
> for nativesdk (buildtools tarball).
> File started to use MAGIC variable initialized from 
> .../environment-setup.d/file.sh, like
>
> /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc
>
> This path relocation does not covered by relocate_sdk.sh script.
>
> Commit that change behavior from wrapper that use relative path to 
> environment variable with absolute path is:
>
> commit 47db876d09d9a4394048579c21d0b394450ce681
> Author: Chen Qi 
> Date:   Tue Jan 17 12:06:30 2023 +0800
>
> file: export MAGIC in SDK
>
> Previously, a wrapper is used for file, which adds '--magic-file'
> option to it. But other components might use libmagic and in such
> case, if there's no MAGIC environent variable set correctly, things
> do not work. For example, rpmbuild makes use of libmagic and it
> requries MAGIC to be set correctly.
>
> Signed-off-by: Chen Qi 
> Signed-off-by: Luca Ceresoli 
> Signed-off-by: Richard Purdie 
>
>
> I would like to ask if anybody else has such an issue. Any propositions other 
> than reverting commit?
>
> Regards,
> Oleksiy
>
> 
>

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

[yocto] meta-arm-toolchain: SUPPORTED file not found #toolchain

[Jesus.JimenezSanchez via lists.yoctoproject.org]

Hello, I'm trying to add the arm toolchain to my yocto project but I just got 
this error
```
| cp: cannot stat 
'.../tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/external-arm-toolchain/2022.02-r0/image/local/SUPPORTED':
 No such file or directory
```
It comes from the `external-arm-toolchain.bb` recipe. I've checked and the 
`SUPPORTED` file is in the right folder (the `files` folder where the 
`external-arm-toolchain.bb` file is). I haven't made any modifications to the 
meta-arm repo. I just cloned it and changed to branch `kirkstone`. After that, 
I have configured my local.conf with this:
```
TCMODE = "external-arm"

EXTERNAL_TOOLCHAIN = ".../gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf"
```

I have added this to the `bblayers.conf`:
```
BBLAYERS += "${OEROOT}/layers/meta-arm/meta-arm-toolchain"
```

And that's it, I think. Have I missed any steps?

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

[yocto] File magic/sdk relocation

[Oleksiy Obitotskyy via lists.yoctoproject.org]

Hi,

I'm working on master oe core master branch and run into problem with file for 
nativesdk (buildtools tarball).
File started to use MAGIC variable initialized from 
.../environment-setup.d/file.sh, like

/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-xesdk-linux/usr/share/misc/magic.mgc

This path relocation does not covered by relocate_sdk.sh script.

Commit that change behavior from wrapper that use relative path to environment 
variable with absolute path is:

commit 47db876d09d9a4394048579c21d0b394450ce681
Author: Chen Qi 
Date:   Tue Jan 17 12:06:30 2023 +0800

file: export MAGIC in SDK

Previously, a wrapper is used for file, which adds '--magic-file'
option to it. But other components might use libmagic and in such
case, if there's no MAGIC environent variable set correctly, things
do not work. For example, rpmbuild makes use of libmagic and it
requries MAGIC to be set correctly.

Signed-off-by: Chen Qi 
Signed-off-by: Luca Ceresoli 
Signed-off-by: Richard Purdie 


I would like to ask if anybody else has such an issue. Any propositions other 
than reverting commit?

Regards,
Oleksiy

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

[yocto] [ptest-runner2] [PATCH] utils: Ensure data is only written with a mutex held

[Richard Purdie]

Currently the code can race as there is a read/write thread handling the stdio 
but
there is no guarantee that when the process exits, the thread has handled all 
the
data. This results in output where "END:" isn't actually at the end of the logs
but somewhere in the middle of the output.

Synchronisation is hard. The easiest way I can see to fix this is to have a 
mutex
for the output and then in the main thread, after the child exits, read any 
remaining
data. This avoids concurrent writes corrupting the output and ensures END: is
actually at the end of the test data.

Signed-off-by: Richard Purdie 
---
 utils.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/utils.c b/utils.c
index ec57fa4..65b1df3 100644
--- a/utils.c
+++ b/utils.c
@@ -63,6 +63,7 @@ static struct {
int timeouted;
pid_t pid;
int padding1;
+   pthread_mutex_t fd_lock;
 } _child_reader;
 
 static inline char *
@@ -317,12 +318,13 @@ read_child(void *arg)
 
do {
r = poll(pfds, 2, _child_reader.timeout*1000);
+   pthread_mutex_lock(&_child_reader.fd_lock);
if (r > 0) {
char buf[WAIT_CHILD_BUF_MAX_SIZE];
ssize_t n;
 
if (pfds[0].revents != 0) {
-   n = read(_child_reader.fds[0], buf, 
WAIT_CHILD_BUF_MAX_SIZE);
+   n = read(_child_reader.fds[0], buf, 
WAIT_CHILD_BUF_MAX_SIZE);
if (n > 0)
fwrite(buf, (size_t)n, 1, 
_child_reader.fps[0]);
}
@@ -338,11 +340,13 @@ read_child(void *arg)
// as much data from the system as possible and kill 
the test
collect_system_state(_child_reader.fps[0]);
_child_reader.timeouted = 1;
+   pthread_mutex_unlock(&_child_reader.fd_lock);
kill(-_child_reader.pid, SIGKILL);
 }
 
fflush(_child_reader.fps[0]);
fflush(_child_reader.fps[1]);
+   pthread_mutex_unlock(&_child_reader.fd_lock);
} while (1);
 
return NULL;
@@ -444,6 +448,8 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
int slave;
int pgid = -1;
pthread_t tid;
+   ssize_t n;
+   char buf[WAIT_CHILD_BUF_MAX_SIZE];
 
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -453,10 +459,10 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 
do
{
-   if ((rc = pipe(pipefd_stdout)) == -1)
+   if ((rc = pipe2(pipefd_stdout, O_NONBLOCK)) == -1)
break;
 
-   if ((rc = pipe(pipefd_stderr)) == -1) {
+   if ((rc = pipe2(pipefd_stderr, O_NONBLOCK)) == -1) {
close(pipefd_stdout[0]);
close(pipefd_stdout[1]);
break;
@@ -466,6 +472,11 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
fprintf(fp, "ERROR: Unable to detach from controlling 
tty, %s\n", strerror(errno));
}
 
+   if (pthread_mutex_init(&_child_reader.fd_lock, NULL) != 0) {
+   printf("Failed to init mutex\n");
+   exit(EXIT_FAILURE);
+   }
+
_child_reader.fds[0] = pipefd_stdout[0];
_child_reader.fds[1] = pipefd_stderr[0];
_child_reader.fps[0] = fp;
@@ -535,8 +546,13 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
entime = time(NULL);
duration = entime - sttime;
 
-   /* Now the child has exited, ensure buffers are 
in sync before writing */
+   pthread_mutex_lock(&_child_reader.fd_lock);
+   while ((n = read(_child_reader.fds[0], buf, 
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
+   fwrite(buf, (size_t)n, 1, 
_child_reader.fps[0]);
+   while ((n = read(_child_reader.fds[1], buf, 
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
+   fwrite(buf, (size_t)n, 1, 
_child_reader.fps[1]);
fflush(NULL);
+   pthread_mutex_unlock(&_child_reader.fd_lock);
 
if (status) {
fprintf(fp, "\nERROR: Exit status is 
%d\n", status);
@@ -558,6 +574,7 @@ run_ptests(struct ptest_list *head, const struct 
ptest_options opts,
 
pthread_cancel(tid);
pthread_join(tid, NULL);
+   pthread_mutex_destroy(&_child_reader.fd_lock);
 
   

Re: [yocto] Going on supporting Ubuntu 18.04?

[Richard Purdie]

On Mon, 2023-06-19 at 09:53 +, Ross Burton wrote:
> On 19 Jun 2023, at 10:48, Alex Kiernan via lists.yoctoproject.org 
>  wrote:
> > FWIW we swapped out our x86_64 build machines for Aarch64 build
> > machines (both 20.04) in AWS with pretty much zero pain - it went way
> > better than I was expecting. That said we don't run ptests, or qemu,
> > or …
> 
> Sure, our meta-arm CI is 90% running on graviton3, this isn’t an “arm
> is inherently unstable” thing but rather that some of the current
> physical arm workers were unstable: reporting core temperatures of
> several hundred degrees celsius and shutting down, etc. Halstead
> resolved the problems in the end but it wasn’t trivial.
> 
> The worker running 1804 is the oldest and by far the slowest, but
> it’s also been - so far - the most reliable.

To be clear I'm not saying there is any problem in general with ARM
machines! We just know that particular hardware, we had a lot of issues
when we first set it up. Since we got the config right it has behaved a
lot more reliably than the others. Changing the OS introduces risk and
my question was whether we wanted to rush into that, particularly as it
risks the machine being written off if things go badly, I was already
under pressure about that as it is getting old. Things have got better
since and nobody is interested on support on that particular older
system.

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60346): https://lists.yoctoproject.org/g/yocto/message/60346
Mute This Topic: https://lists.yoctoproject.org/mt/99619554/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Going on supporting Ubuntu 18.04?

[Ross Burton]

On 19 Jun 2023, at 10:48, Alex Kiernan via lists.yoctoproject.org 
 wrote:
> FWIW we swapped out our x86_64 build machines for Aarch64 build
> machines (both 20.04) in AWS with pretty much zero pain - it went way
> better than I was expecting. That said we don't run ptests, or qemu,
> or …

Sure, our meta-arm CI is 90% running on graviton3, this isn’t an “arm is 
inherently unstable” thing but rather that some of the current physical arm 
workers were unstable: reporting core temperatures of several hundred degrees 
celsius and shutting down, etc. Halstead resolved the problems in the end but 
it wasn’t trivial.

The worker running 1804 is the oldest and by far the slowest, but it’s also 
been - so far - the most reliable.

Ross


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60345): https://lists.yoctoproject.org/g/yocto/message/60345
Mute This Topic: https://lists.yoctoproject.org/mt/99619554/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Going on supporting Ubuntu 18.04?

[Alex Kiernan]

On Mon, Jun 19, 2023 at 10:44 AM Ross Burton  wrote:
>
> On 19 Jun 2023, at 10:34, Richard Purdie via lists.yoctoproject.org 
>  wrote:
> > The ARM worker worries me a lot more. The 1804 worker is currently
> > stable but I do worry a bit what will happen when we change the OS on
> > that machine. In theory it should be fine and it could well be but that
> > hardware was very painful in the past.
>
> Each Arm worker runs a different release of Ubuntu, so I’ve no problem with 
> asking Michael to reimage the 1804 machine with something newer (maybe even 
> something not-Debian for coverage).  If it suddenly becomes less stable that 
> would be a very interesting datapoint!
>

FWIW we swapped out our x86_64 build machines for Aarch64 build
machines (both 20.04) in AWS with pretty much zero pain - it went way
better than I was expecting. That said we don't run ptests, or qemu,
or ...

-- 
Alex Kiernan

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

Re: [yocto] Going on supporting Ubuntu 18.04?

[Richard Purdie]

On Mon, 2023-06-19 at 09:44 +, Ross Burton wrote:
> On 19 Jun 2023, at 10:34, Richard Purdie via lists.yoctoproject.org 
>  wrote:
> > The ARM worker worries me a lot more. The 1804 worker is currently
> > stable but I do worry a bit what will happen when we change the OS on
> > that machine. In theory it should be fine and it could well be but that
> > hardware was very painful in the past.
> 
> Each Arm worker runs a different release of Ubuntu, so I’ve no
> problem with asking Michael to reimage the 1804 machine with
> something newer (maybe even something not-Debian for coverage).  If
> it suddenly becomes less stable that would be a very interesting
> datapoint!

Interesting, yes. If it breaks, I suspect the official advice will be
to scrap that machine rather than fix it though and we'll then be down
on build power :/.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60343): https://lists.yoctoproject.org/g/yocto/message/60343
Mute This Topic: https://lists.yoctoproject.org/mt/99619554/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Going on supporting Ubuntu 18.04?

[Ross Burton]

On 19 Jun 2023, at 10:34, Richard Purdie via lists.yoctoproject.org 
 wrote:
> The ARM worker worries me a lot more. The 1804 worker is currently
> stable but I do worry a bit what will happen when we change the OS on
> that machine. In theory it should be fine and it could well be but that
> hardware was very painful in the past.

Each Arm worker runs a different release of Ubuntu, so I’ve no problem with 
asking Michael to reimage the 1804 machine with something newer (maybe even 
something not-Debian for coverage).  If it suddenly becomes less stable that 
would be a very interesting datapoint!

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60342): https://lists.yoctoproject.org/g/yocto/message/60342
Mute This Topic: https://lists.yoctoproject.org/mt/99619554/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Going on supporting Ubuntu 18.04?

[Alexander Kanavin]

On Mon, 19 Jun 2023 at 11:34, Richard Purdie
 wrote:
> This isn't as simple as you'd think.
>
> The x86 worker will be dropped when maintenance comes around to that
> point on the autobuilder, it is in the queue.
>
> The ARM worker worries me a lot more. The 1804 worker is currently
> stable but I do worry a bit what will happen when we change the OS on
> that machine. In theory it should be fine and it could well be but that
> hardware was very painful in the past.
>
> I appreciate the idealist "lets drop it ASAP" but there are other
> things to consider. Do we want to lose Michael Halstead and myself for
> a couple of weeks trying to fix a new OS on it? Do we want to lose a
> third of our ARM build power?

But can we ask ARM folks to sort this out, and preferably well ahead
of EOL dates in the future? They had pushed heavily for ARM as the
first class build host, so both hardware and software on the AB is on
them.

Alex

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

Re: [yocto] Going on supporting Ubuntu 18.04?

[Richard Purdie]

On Mon, 2023-06-19 at 11:02 +0200, Alexander Kanavin wrote:
> Even if we would have a subscription with Canonical, it would not be
> fair to ask contributors to fix issues that occur only on distribution
> available through commercial channels. So yes, it should be dropped
> ASAP.
> 
> Alex
> 
> On Mon, 19 Jun 2023 at 10:35, Michael Opdenacker via
> lists.yoctoproject.org
>  wrote:
> > 
> > Greetings,
> > 
> > I know that we are still testing and supporting Ubuntu 18.04, but should
> > we go on doing it?
> > 
> > This version no longer has public updates, so unless we have a
> > subscription with Canonical, we are going to be out of sync with the
> > updates that Ubuntu 18.04 subscribers get.

This isn't as simple as you'd think.

The x86 worker will be dropped when maintenance comes around to that
point on the autobuilder, it is in the queue.

The ARM worker worries me a lot more. The 1804 worker is currently
stable but I do worry a bit what will happen when we change the OS on
that machine. In theory it should be fine and it could well be but that
hardware was very painful in the past.

I appreciate the idealist "lets drop it ASAP" but there are other
things to consider. Do we want to lose Michael Halstead and myself for
a couple of weeks trying to fix a new OS on it? Do we want to lose a
third of our ARM build power?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60340): https://lists.yoctoproject.org/g/yocto/message/60340
Mute This Topic: https://lists.yoctoproject.org/mt/99619554/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Going on supporting Ubuntu 18.04?

[Alexander Kanavin]

Even if we would have a subscription with Canonical, it would not be
fair to ask contributors to fix issues that occur only on distribution
available through commercial channels. So yes, it should be dropped
ASAP.

Alex

On Mon, 19 Jun 2023 at 10:35, Michael Opdenacker via
lists.yoctoproject.org
 wrote:
>
> Greetings,
>
> I know that we are still testing and supporting Ubuntu 18.04, but should
> we go on doing it?
>
> This version no longer has public updates, so unless we have a
> subscription with Canonical, we are going to be out of sync with the
> updates that Ubuntu 18.04 subscribers get.
>
> What do you think?
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
> 
>

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

[yocto] Going on supporting Ubuntu 18.04?

[Michael Opdenacker via lists.yoctoproject.org]

Greetings,

I know that we are still testing and supporting Ubuntu 18.04, but should 
we go on doing it?


This version no longer has public updates, so unless we have a 
subscription with Canonical, we are going to be out of sync with the 
updates that Ubuntu 18.04 subscribers get.


What do you think?
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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